On Mon, 1 Oct 2018, nik(a)parkellipsen.de wrote: information time to ? It There is (so far as I know) nobody working on AVB support for Linux. No ALSA work at all. The jack support is as a jack client and so far as I know has only been tested jack to jack not jack to endpoint. Because the jack support is as a client and I do not know how or if sync is achieved, it may be external to the avb path. (or SRC) -- Len Ovens www.ovenwerks.net <http://www.ovenwerks.net> _______________________________________________ Linux-audio-user mailing list Linux-audio-user(a)lists.linuxaudio.org https://lists.linuxaudio.org/listinfo/linux-audio-user

On Mon, 1 Oct 2018, nik(a)parkellipsen.de wrote: Both put the effort in and have the hardware to test with. In my mind there are two paths one could take, jack or alsa. ALSA: in the case of ALSA one would create a driver that would start up at system start or manually after start (manually could mean using a GUI). The device once connected would be static. It would have a fixed number of audio ports and possibly break if that device went away (same as a USB device). This would be fine for many uses. It would have to be all inclusive though. Jack: This case is or could be much more flexable. In this case I would use the NIC's clock (assuming an i210 or similar that has such a thing) and use it to time the dummy backend for jack. There would be some code involved to either make this clock master or slave. I don't know if this already happens with the code as it stands. The i210 has some extra pins, it would be great if one of them could be programed to put out wordclock as well for syncing a local audio interface to the whole works. A GUI would list known interfaces that can be connected (those that have the right SR at least) either as a grid (like Ardour's audio port connection GUI) or as a list like qjackctl's Connections window. I suspect as things get more complex the patchage style might be hard to use but that is another possibility. This GUI would not just make a jack connection, but would have to first start a jack client that is connected to the remote device and then connect it. As many AVB devices only seem to deal with 8 channel streams at a time, connecting one port would mean that 8 ports would show up on the jack graph and the GUI would connect any other port for that stream without creating another jack client. Devices could be added or removed at any time and if an AVB client is no longer needed (has no connections for more than 10 seconds) it could vanish. I do not know if there is already code that allows a jack client or connection GUI to advertize stream availablity to the world but, as with all things AVB, that would be yet another piece of code. Going this route would also leave things open for AES67 using the same clock. It would seem possible to connect to both AVB and aes67 devices at the same time. Assuming a suitable aes67 jack client was available. I had thought to work on something like that and have the i210 NIC but not A) another computer to act as an end point or B) (better) an AVB endpoint to play with. In my case I would prefer inputs. Another solution, though probably more costly, is to purchase something that has both USB and AVB and use it to access a remote audio device. The Motu 8D for example (8 aes3 i/o) is 800CDN or the 8A (8 audio i/o) is 1050CDN. The advantage is that you end up with local audio i/o that is in sync with your remote. (well sort of, you may find aes3 inputs go through a SRC stage unless you provide sync to any aes3 input box) If all you want is a cheap network audio solution... an old computer with 8 outs and runs jack... use zita-njbridge... be happy. Almost all HDA mother boards have 8 outs for a number of years, but it may be almost as cheap to use a new atom based MB with 16v PS as the minidsp 8n. (or a nuc... well maybe not, they have 7.1 through hdmi but only 4 physical on the $200 model) Pulse also offers networked audio... but I have no experience with that and pulse is known to be lossy (as in samples just get lost) -- Len Ovens www.ovenwerks.net

On Mon, October 1, 2018 4:13 pm, Niklas Reppel wrote: The MOTU devices allow connecting a laptop via USB, and expanding audio channels via an AVB switch between multiple interfaces (or just direct connection if you only have two devices). The addition of AVB interface seems to add several hundred dollars/pounds/euros to the price compared to a USB only device, so either the expandability or the ability to physically separate the multiple interfaces would have to be relatively valuable to make it worth the extra cost. -- Chris Caudle _______________________________________________ Linux-audio-user mailing list Linux-audio-user(a)lists.linuxaudio.org https://lists.linuxaudio.org/listinfo/linux-audio-user

On Tue, 2 Oct 2018, nik(a)parkellipsen.de wrote: Ohh ok, that'd work with the recent MOTU ? Interesting, that makes the Almost... before starting jack, maybe before plugging in the the ultralite's USB even, connect the ndac. Then, using the web app on the ultralite... uh, oh... Hmmm I guess that means you already need an AVB type switch :) but anyway, using the web app, set up the ultralite to accept the 8channel stream from the ndac which will make the utralite have more or show more inputs. Now connect the ultralite to the computer and the extra channels shoulld show. Now I am not sure this is exactly right. The ultralite may show enough channels all the time (there is a limit BTW). However, from reading the manual, I get the idea that routing still must be performed and that ALSA (via USB) can't do that. You need to use the web interface which uses the same network port as the AVB network. So a minimal system is an ultralite only works as audio interface and the network needs to be connected to your computer. The next step to add one AVB endpoint requires an AVB hub as well. So that would be three boxes for a minimal remote box system. In my case, though I would love to experiment, it will remain on my todo list for a long time yet :) My legacy PCI interface will have to do. -- Len Ovens www.ovenwerks.net _______________________________________________ Linux-audio-user mailing list Linux-audio-user(a)lists.linuxaudio.org https://lists.linuxaudio.org/listinfo/linux-audio-user