On Wed, 2011-06-22 at 22:06 +0200, David Henningsson wrote: > On 2011-06-22 15:56, Colin Guthrie wrote: > > 'Twas brillig, and marcin at saepia.net at 20/06/11 17:20 did gyre and gimble: > >> And the next one, for tunnels. > > > > Both seem reasonable, but let me consult with others first. > > > > So guys, should these modules' threads look to be using RT prio? > > > > Col > > > > FWIW, I remember Lennart told me something long ago about redesigning > PulseAudio so that audio packets did not have to pass through non-RT > threads. E g, if you would have a client which had its output thread RT, > that would keep the entire chain RT prio (to minimize risk of dropouts > at all stages), something that's not possible now, at least not with > protocol-native. I think this makes a lot of sense. There's 3 context-switches (client, PA main thread, sink I/O thread) to get your samples through to the hardware in just the ALSA case, so minimising the risk of getting switched out by the scheduler is definitely desirable. > With that in the back of our heads, I'm not sure what problem we solve > by having null-sink thread(s) running on RT prio? I believe module-always-sink can load a null-sink/source momentarily during profile switches (since there's a sink/source deletion + addition in some cases). So might not be a bad idea to add it. -- Arun
