[gst-devel] problem with pa_stream_make_writeable_size() failed connection terminated

[David Henningsson]

On 2011-01-27 07:55, Nathanael D. Noblet wrote:
> On 01/26/2011 10:21 AM, pl bossart wrote:
>>>     So I read from an IP camera via rtspsrc. It sends video in MP4 format
>>> and Audio in AAC. We're running a beta with our client and recently
>>> after installing it on location I've run into issues with one location.
>>> After 5-9 seconds I get
>>>
>>> pa_stream_make_writeable_size() failed connection terminated
>>
>> This is an issue in the connection with PulseAudio. Since it's PCM at
>> that point, I don't think it's an issue with the bitrate of the AAC
>> payload.
>> Can you try and capture the pulseaudio log (pulseaudio -vvvv 2>
>> log.txt). Don't send the log, which can be pretty long, just a link on
>> something like pastebin.
>
> Yeah I can't seem to figure out what it could be either. I do have
> SELinux rules in place, however the messages don't stop when SELinux is
> disabled. Also in testing, my x86_64 box doesn't exhibit the same
> behaviour *nearly* as often/reliably as the little netbooks do. In
> anycase, here's the output from a pulseaudio session where I did get
> this message....
>
> http://fpaste.org/j0Jo/
>
>
> I don't see anything obvious but with that many lines I really didn't
> have a clue what to look for at all. Ask for whatever output you need
> and I'll do my best to make it happen.
>
> Since you feel it is permissions based I'll also explain that my app is
> setgid in the areas that are starting the gstreamer threads. So it is
> quite possible that for one reason or another gstreamer/pulse
> interaction is having issues, however they do go away with higher
> bitrates which is really odd to me... Perhaps the bitrates/clock-rate
> cause a change request or something that doesn't happen when they are
> higher but I'm really at a loss. I may try to debug using gdb to see if
> I can get a bt...
>
> Thanks for the help thus far, I'd really like to understand what is
> going on...

PulseAudio eats too much CPU in RT-prio time and ends up getting killed 
by the kernel. One way to counteract this is for gstreamer to send few 
big packets instead of many small ones, so soes the patch I posted here 
recently help to resolve this symptom?

See 
http://gstreamer-devel.966125.n4.nabble.com/attachment/3207515/0/default-buffer-size.patch

-- 
David Henningsson, Canonical Ltd.
http://launchpad.net/~diwic