Well mostly I'd be interested in having a somewhat modular, compact yet
extensible solutions for
multiple channels on recent laptops.
The choice of multichannel options (esp. exceeding 8 channels) for Linux
is unfortunately very small,
and often the devices that are compatible are not that compact.
So being able to patch together multiple devices as the situation
requires via an AVB switch seems more than desirable ...
On 10/1/18 7:17 PM, Len Ovens wrote:
On Mon, 1 Oct 2018, nik@xxxxxxxxxxxxxxx wrote:
Hmm but you wrote in a previous mail that there might be a chance to
make it work if sb is willing to put the effort in?
Are there any resources on that ? I only found a thread in the ardour
forums, but couldn't extract any info about where to start. (tbh i
just skimmed
it quickly).
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
--
Niklas Reppel
www.parkellipsen.de
_______________________________________________
Linux-audio-user mailing list
Linux-audio-user@xxxxxxxxxxxxxxxxxxxx
https://lists.linuxaudio.org/listinfo/linux-audio-user
