-
Notifications
You must be signed in to change notification settings - Fork 52
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
Comments
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. |
I continually scan fr AVB related Linux utilities, libraries periodically. Will reach out if I see anything that might fit the bill. |
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! |
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 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). |
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. |
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. |
I was really hoping you would say this 😃 |
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.
The text was updated successfully, but these errors were encountered: