Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Future feature idea: AoIP device support #359

Open
siraaris opened this issue Sep 5, 2024 · 7 comments
Open

Future feature idea: AoIP device support #359

siraaris opened this issue Sep 5, 2024 · 7 comments

Comments

@siraaris
Copy link

siraaris commented Sep 5, 2024

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.

@HEnquist
Copy link
Owner

HEnquist commented Sep 5, 2024

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.

@siraaris
Copy link
Author

siraaris commented Sep 5, 2024

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

@siraaris
Copy link
Author

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!

@fridtjof
Copy link

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).

@siraaris
Copy link
Author

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.

@HEnquist
Copy link
Owner

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.

@siraaris
Copy link
Author

I was really hoping you would say this 😃

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants