Secure, professional, low-latency audio that just works
What do we need to bridge the gap between the Pro audio's need for reliably low latency, and Ubuntu's secure and just-works standard? E g: FFADO udev rules, jack and rtkit integration, adding memlock features to rtkit, make PA a jack client when jack starts, add a jack engine whenever a FW soundcard is plugged in, etc? Perhaps we can't or shouldn't do all of these for Natty, but having some of them would be nice.
Blueprint information
- Status:
- Not started
- Approver:
- None
- Priority:
- Undefined
- Drafter:
- David Henningsson
- Direction:
- Needs approval
- Assignee:
- None
- Definition:
- New
- Series goal:
- Accepted for natty
- Implementation:
-
Unknown
- Milestone target:
-
natty-alpha-3
- Started by
- Completed by
Whiteboard
Work items:
[diwic] to maintain upstream contacts and investigate the status for moving FFADO into ALSA/kernel: DONE
[diwic] to investigate (with Ubuntu security team; jackd2 upstream; Lennart, Colin G) whether RtKit could be enhanced to hand out memlock permissions: POSTPONED
[diwic] to investigate implementing pulse module that adds pulse sinks and sources whenever jack is started (perhaps via jack announcing its availability?): DONE
[cjcurran] to investigate feasibility of integrating his command-line prototype of recording VoIP calls: TODO
First,
I'm glad to see that so many have signed up for this blueprint. It says to me that this is something that's worth our time and effort.
So here's an agenda of what I plan to discuss on the session. Session goal is to define priorities and actions for the Natty cycle.
[Firewire sound cards]
How can we make them "just work" in Ubuntu?
FFADO udev rules (for permissions), that help assigning FW sound cards to the current user, have been discussed upstream, picked up by Debian and are considered "In progress".
The second part is trying to avoid the current manual setup. Here are our four options, from easiest to hardest:
1) When a FW device is attached, run an udev rule that auto-starts jack, then tells PulseAudio to add a module-
2) Make a new PA module that talks to FFADO directly without going through jackd
3) Make an alsa-plugin module that talks to FFADO directly without going through jackd
4) Help completing upstream's effort to move FFADO into ALSA at the kernel level
[Low latency]
How can we make users have reliably low latency without "compromising" the system?
Current "compromise" is to let jackd install /etc/security/
* Could rtkit be enhanced to hand out memlock permissions (always saving say 10% and at least 128 MB of the system to be non-memlocked, for security)?
* Do we have to implement rtkit clients in every single program wanting RT permissions and/or memlocks or can we implement this seamlessly at the library level?
* Do we need a low-latency kernel? That might be related and is likely to be discussed at: https:/
[Better JACK/Pulse Audio Integration]
* Do we want to add a module-jack-detect to PA that adds sinks and sources to PA whenever jackd is started?
With the inclusion of JACK2 using D-BUS, a user with two audio interfaces can utilize one to play audio with JACK and the other to play audio with Pulse Audio. Can we integrate this further in a stable fashion?
Can JACK and Pulse Audio share the same audio interfaces? The would allow JACK to "capture" an audio stream that Pulse Audio is controlling for the audio interface.
Or can they be bridged in a stable fashion? Thereby routing audio through a audio interface, which is controlled Pulse Audio, which is then passed onto JACK.
A simple use case for this would be a podcaster who wishes to record a VoIP call through Skpe or Mumble (http://
Alternately, adding JACK functionality to Mumble would satisfy this use case.
Update 2011-02-07: Moving FFADO into the kernel is several months of work, and nobody is committed to provide sufficient funding or volunteering at this point. Well, there might be some volunteer activity, but the outcome remains to be seen. So, no FFADO in the kernel for Natty.
Update 2011-05-13: I've now talked to both Lennart (PA upstream) and Kees (Ubuntu security) and both have were optimistic about extending RtKit to hand out memlock permissions. Lennart pointed out that there is now possibility to actually grant memlock permissions to someone else (in the kernel IIRC). However finding the time to actually implement this feature might be difficult, as would the actual details of ensuring we hand it out in a safe way. // David
