[pulseaudio-discuss] RFC: realtime prio for null and tunnel sinks? (Was Re: Why only selected modules try to acquire realtime priority?)

[Arun Raghavan]

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