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

Colin Guthrie gmane at colin.guthr.ie
Wed Jun 22 14:35:32 PDT 2011

'Twas brillig, and Arun Raghavan at 22/06/11 21:29 did gyre and gimble:
> 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.

That's a corner case tho' and (ideally) it wouldn't happen. If at all
possible we should make it such that this doesn't happen rather than add
a work around here...

And besides, if you're changing profiles you pretty much expect a drop
out of some sort as the sink itself changes.



Colin Guthrie

Day Job:
  Tribalogic Limited [http://www.tribalogic.net/]
Open Source:
  Mageia Contributor [http://www.mageia.org/]
  PulseAudio Hacker [http://www.pulseaudio.org/]
  Trac Hacker [http://trac.edgewall.org/]

More information about the pulseaudio-discuss mailing list