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

[marcin at saepia.net]

Hi,

I can send more detailed information if that solves my issue in 1-2
weeks. Now I am in a place where I can use only weak GPRS connection
so let's say, the access to my server with PA is limited by my
patience ;)

The other problem is that that drops appear accidentaly so it takes a
long time to debug. I am not sure if it's the RT case, it's just my
guess after digging in the PA source code. But I thought its worth
considering. I an not expert on RT programming at all, so maybe my
ideas are just plain wrong.

Currently I've written a small app that just call sched_setscheduler()
on all PA threads (is it correct approach at all?), and I will check
if that drops still exist.

m.

2011/6/22, David Henningsson <david.henningsson at canonical.com>:
> 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.
>
> 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?
>
> --
> David Henningsson, Canonical Ltd.
> http://launchpad.net/~diwic
> _______________________________________________
> pulseaudio-discuss mailing list
> pulseaudio-discuss at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
>