I vote for B as well. I am working on porting a Mac OS X radio automation system I wrote to Linux/FreeBSD using Jack2. AVB is certainly on my radar for use! However, I was under the impression, without having dug to deep into the protocol, that the AVB's precision network time management allows all devices to share a sample clock. That sure would make it easy from a JACK perspective. No asynchronous re-sampling would be required (if I am correct about network time). Since I have no AVB equipment, I am not clear how one goes about setting up which device on the network is the clock master, but it must be configurable somehow.
Ethan...
On Thu, April 11, 2019 3:44 pm, Christoph Kuhr wrote:
I wanted to start a discussion of what kind of AVB connectivity makes the
most sense for jack.
But please keep in mind what AVB is and isn't.
a) Fully functional Backend
b) Media Clock Backend with AVB jack clients
...
con a),
- only one talker/listener, single audio interface
...
pro b)
- multiple talkers/listeners with multiple audio interface using alsa api
I did not see many replies to this, but if I understand the limitations
correctly I believe b would be the more useful.
Is the limit described for a implying that if you had for example two or
three of the MOTU AVB interfaces, you could only connect to one at a time?
If so then definitely b would be the preference, since one of the
advantages of network audio protocols is that you can have a distributed
recording and playback system, and if your input needs grow you do not
have to trade out a small interface for a larger interface, you can just
add an additional small interface, with the added benefit that the
interfaces can be in two different rooms.
If you are limited to one interface at a time then the only benefit over
USB is a longer cable.