'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. Col -- Colin Guthrie gmane(at)colin.guthr.ie http://colin.guthr.ie/ 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/]
