[pulseaudio-discuss] Windows7 audio architecture
lennart at poettering.net
Mon Oct 19 09:57:40 PDT 2009
On Mon, 19.10.09 10:38, pl bossart (bossart.nospam at gmail.com) wrote:
> >> The video is available at:
> >> http://channel9.msdn.com/shows/Going+Deep/Elliot-H-Omiya-Larry-Osterman-and-Frank-Yerrace-Inside-Windows-7-Audio-Stack/
> >> for download in various formats. Here is a direct download URL:
> >> http://mschnlnine.vo.llnwd.net/d1/ch9/0/2/8/9/7/4/InsideWin7Audio_ch9.wmv
> > Thanks for the link. This is really quite interesting.
> > It's fun that they now are playing catch up with us. Allowing streams
> > to move between devices during playback and automatic per-role routing
> > seem to be the big new features in Windows7 audio. And we had that for
> > a longer time now already ;-)
> This is interesting indeed. The main points I captured were:
> - Win7 doesn't seem to rely on timer-based scheduling, my
> understanding is that they rely on hardware events to avoid the issues
> with audio/wall clock drifts. At the same time, they don't seem to be
> shooting for reduction in wake-ups by using large buffers when latency
> is not an issue. The events are 15ms apart at most, and the benefits
> of timers are not clear in that case.
This I actually am not sure about. First they talk about using system
timers, and then they talk about the hw triggering the requests. Made
no sense to me. I am pretty sure though that they actually do use
system timers because they were talking about clock deviation issues.
> - 'capture monitors' seem to be the equivalent of the loopback module
> I wrote (shameless bit of self-promotion for once...). The MSFT
> developer described the same issues I had with internal mics with
> feedback loops/larsen. The 'capture monitors are configured with a
> 'listen-to' tab in the UI.
Yes, and they talked that they were shutting off those monitors
automatically when the power is unplugged. That makes it sound exactly
like the digital audio path that module-loopback implements.
> - Win7 implements some sort of audio policy and redirect streams based
> on 'heuristics'. While this is common on embedded devices, this is not
> very common on laptops/desktops. We really need to have a unique
> policy-related API for apps to provide the relevant support for
We already have that. As long as you tag your streams in PA
module-intended-roles and module-x11-cork-on-phone implement this policy.
> - Apps can listen to rerouting events
We can too!
> - Apps can listen to pause/resume events and make decisions on their
> own, without entirely relying on the audio policy
Yepp, we have that too. This is now even forwarded through Gst. But to
my knowledge no gst consumer makes use of that yet.
> - Apps can prevent automatic volume modifications or docking if they
> don't fell this is relevant for their content (e.g games)
Not convinced this makes sense, though.
Lennart Poettering Red Hat, Inc.
lennart [at] poettering [dot] net
http://0pointer.net/lennart/ GnuPG 0x1A015CC4
More information about the pulseaudio-discuss