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 >
