On Thu, 20 Jul 2017, Bearcat Şándor wrote:
Huh. What i'm looking at purchasing are a bunch ofthese
https://www.genelec.com/studio-monitors/sam-studio-monitors/8430a-ip-sam-s
tudio-monitor for an ambisonic setup. They have a Ravenna input and they can
be
run in mono or stereo. Looking at the manual
... url omitted
it states "There are some requirements
for the AE67 network. The network must run a clock source supporting the
Precision Time Protocol according to the format defined in IEEE 1588-2008.
Several audio sources and media IP switch devices can act as PTP clock sources
for the network. It is also useful to make sure that the IP switches delivering
the audio streams have been configured to prioritize the PTP clock messages and
the RTP audio streams over other traffic."
The big thing here is prioritize. The switch has to have more than one
transmit/receive queue to be able to do this.
From what you're saying i'd need to output the software stream from my computer
using a secondary ethernet port into a ptp router then into my speakers.
You may be able to do that with your main NIC, but the advantage of using
a second $50 i210 is that it has a hw PTP clock built in.
Why would i need to buy an expensive router? Why not just build my own router
using http://linuxptp.sourceforge.net/ or https://github.com/ptpd/ptpd
So far as I know, it is very difficult to get a sw ptp clock to have the
stability needed. However, if you used a computer for nothing else but ptp
and net forwarding you might do it... I just think a $50 NIC is cheaper.
How does Jack2 (dbus) fit into all of this?
That depends on the AES67 driver. If it is built to talk to jack
dirrectly, then jack is quite important. If the driver is ALSA... not so
much.
It seems like the ptp software above can connect multiple computers, so i could
just start out with a mini-pc with a 4 jack ethernet card and add more
mini-computers as i need to yes?
Maybe, the cpu inside really does matter for a sw ptp clock. Latency has
to be much better than for audio alone. Alsa deals with 32 samples at a
time or much more (128 is much more common). but to have stable audio, ptp
has to be more accurate than 1 sample. This would be time for a real time
kernel for sure. Priorities would have to be right on... and maybe
multi-cores would not be the best thing. (no hyperthreading for sure).
One place to look at real time latency is:
https://www.osadl.org/Hardware-overview.qa-farm-hardware.0.html
Where they have many combinations of HW running in real time testing
latency. often slower cpus have better latency tests than faster or higher
core count machines.
If your mini computer with 4 or more NICS will cost more than about $400,
maybe this would be better:
https://www.sweetwater.com/store/detail/AVBSwitch
I have been surprised at total cost of putting a small system together
even assuming some parts I already have laying around (case, PS, KB,
mouse, display) The best thing is do your homework, find the list of
ethernet protocols aes67 expects and see if there are more reasonably
priced switches that will give you enough assuming your NIC can provide a
network ptp clock.
Or am i completely confused?
The big thing with aes67 is A) paying for the protocol spec. (thankyou
aes) and B) doing the dev work... that is putting it all together. AES67
does not have any discovery built in, but because your speakers use
bonjour, I would work with that (linux has Avahi that covers most of
this). I am not sure how AES "you must pay for the protocol" would go with
a GPL project because open source effectively gives the protocol away for
free. AVB on the otherhand, hosts a github project that is open source.
If it was me (and I am not a great example :) I would go aes67 direct to
jack backend. That is mostly because I am familiar with the jack api and
when I looked at trying to do the same thing in alsa, it seemed confusing
and more complex but that is just my personal POV. I am sure once I have
made my first alsa connection my POV will change. Because the ethernet
code is system and not user (in particular setting up queues and
priorities), alsa may make more sense.
Having said all that, balanced xlr audio cables are a lot cheaper than
AoIP-anything. (even ones you have to make yourself) Your speakers support
balanced audio in.
--
Len Ovens
www.ovenwerks.net
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev
