LPC Audio BoF Notes

Post Syndicated from Lennart Poettering original http://0pointer.net/blog/projects/audio-bof-notes.html

Here are some very short notes from the Audio BoF
at the Linux Plumbers
Conference
in Portland two weeks ago. Sorry for the delay!

Biggest issue discussed was audio routing. On embedded devices this gets
more complex each day, and there are a lot of open questions on the desktop,
too. Different DSP scenarios; how do mixer controls match up with PCM streams
and jack sensing? How do we determine which volume control sliders that are in
the pipeline we are currently interested in? How does that relate to policy
decisions? Format to store audio routing in?

The ALSA scenario subsystem
currently being worked on by Liam Girdwood and the folks at SlimLogic and
currently on its way to being integrated into ALSA proper hopefully helps us,
so that we can strip a lot of complexity related to the routing logic from
PulseAudio and move it into a lower level which naturally knows more about the
hardware’s internal routing.

Does it make sense for some apps to bypass the ALSA userspace layer and
to talk to the kernel drivers via ioctl()s directly?i (i.e. thus not depending on ALSA’s
LISP intepreter, and a lot of other complexities)? Probably yes, but certainly
not in the short term future. Salsa? libsydney?

Should the timing deviation estimation/interpolation be moved from
PulseAudio into the kernel? Might be a good idea. Particularly interesting
when we try to to monitor not only the system and audio clocks, but the video
output and particularly the video input (i.e. video4linux) clocks, too. A
unified kernel-based timing system has advantages in accuracy, allows better
handling of (pseudo-) atomic timing snapshots, and would centralize timing
handling not only between different applications (PA and JACK) but also
between different subsystems. Problem: current timing stuff in PulseAudio
might be a bit too homegrown for moving it 1:1 into the kernel. Also, depends
on FP. Needs someone to push this. Apple does the clock handling in the
kernel. How does this relate to ALSA’s timer API?

Seems Ubuntu is going to kill OSS pretty soon too, following Fedora’s lead. Yay!

And that’s all I have. Should be the biggest points raised. Ping me if I
forgot something.