camilladsp icon indicating copy to clipboard operation
camilladsp copied to clipboard

Future feature idea: AoIP device support

Open siraaris opened this issue 1 year ago • 3 comments

This is an "out there idea", and probably not something for right now.

The idea is to add support for virtual audio over IP devices as CamillaDSP playback and capture devices.

For example, a playback device that presents as an AVB Talker, or capture device that presents as an AVB Listener. For AES67 it would be sinks (receiver), and sources (transmitters).

I only mention the open standard ones above (ie, not Dante for example).

I know this is non-trivial, just seeding an idea for the future, maybe. Feel free to close straight away if the idea is naff.

siraaris avatar Sep 05 '24 14:09 siraaris

Some kind of audio over ip would be nice. Unfortunately I don't think there are any rust libraries for avb or aes67. This means that adding this feature is a very large project. I will never find the time for that, but if someone publishes a nice library, then it could become feasible to implement this.

HEnquist avatar Sep 05 '24 16:09 HEnquist

I continually scan fr AVB related Linux utilities, libraries periodically. Will reach out if I see anything that might fit the bill.

siraaris avatar Sep 05 '24 17:09 siraaris

It's really only Linux that would benefit from this. My device supports MADI and AVB, so I can also use an ALSA driver to bridge to the device. Unfortunately there aren't that many of these cards either with Linux drivers!

siraaris avatar Sep 10 '24 07:09 siraaris

I think that's a bit out of scope for Camilla :)

Fortunately, Pipewire actually supports AES67! Things seem much more experimental for AVB, unfortunately, but i think it's just a matter of someone picking up the work who can also test it.

I've tested it before (though between two Pipewire hosts, not with any "pro" equipment) and it was shockingly easy to set up (once i figured out how Pipewire is configured). I recommend using the latest Pipewire releases though, because they got quite a few AES67 improvements in after the 1.0 release.

Here's the official guide/documentation on AES67 in Pipewire: https://gitlab.freedesktop.org/pipewire/pipewire/-/wikis/AES67

I basically took the config template from /usr/share/pipewire/pipewire-aes67.conf, put it into ~/.config/pipewire/pipewire-aes67.conf.d/pipewire-aes67.conf and filled out a few settings according to the comments.

Then, after starting ptp4l in another terminal, just running pipewire-aes67 makes a new output device show up. Any available streams on the network also show up as input devices automatically.

My use case was just forwarding the audio to a DAC, but plugging camilla into these inputs/outputs should be as trivial as with any other audio sink/source (even without native pipewire support of course, works just as well through the pulse or jack APIs).

fridtjof avatar Nov 20 '24 01:11 fridtjof

I do tend to agree that Camilla isn't the ideal place to support AoIP. At a basic level there are cards available eg Dante that present ALSA devices natively that's we can use and of course piggy backing on Pipewire or other layers above ALSA.

siraaris avatar Nov 20 '24 02:11 siraaris

I'm thinking that it's time to start thinking seriously about adding a pipewire backend. The Pulse backend is a bit outdated and I'm not really able to support the jack backend properly. It's tempting to drop them both and go for pipewire instead.

HEnquist avatar Nov 20 '24 13:11 HEnquist

I was really hoping you would say this 😃

siraaris avatar Nov 20 '24 18:11 siraaris

I think this one could close and be subsumed in #233 ?

siraaris avatar Feb 10 '25 04:02 siraaris