Multithread app that just changes volume

[saepia]

Hi,

I am developing an application that does simple thing: Takes an audio
from pulseaudio (pulsesrc), process it (currently only using volume
element) and sends it back to the pulseaudio (pulsesink). pulsesrc and
pulsesink is separated by queue2 to avoid clock issues.

This app also connects itself to PulseAudio and D-Bus (GIO bindings),
both via GLib's mainloop.

The application logic is simple - it receives signal from D-Bus and
then performs fade in or fade out on the signal. To schedule fade
steps I use GLib's g_timeout_add().

From time to time I encounter strange segfaults. Once it was caused by
EINTR. The next one was related to PulseAudio mutexes. The last one
was was thrown from libc itself. (unfortunately I had stripped
binaries installed so I cannot debug that case).

I guess that those segfaults are related to threading. Even if I don't
spawn any threads in my app, seems that underliying libraries
(including GStreamer) do that. When I list /proc/PID/tasks, I find 8
PIDs.

In know that it's not too good practice, but I store current state of
the app in global variables. When GLib's timeout callback is called I
check that state, and change "volume" element's properties.

Is it possible that timeout callback is called from different thread
than "volume" element operates and that causes those hangs?  Should I
perform somehow locking to avoid those issues?

Thank you in advance,

--
Marcin
_______________________________________________
gstreamer-devel mailing list
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[Stefan Sauer]

On 06/09/2011 11:32 AM, [hidden email] wrote:

> Hi,
>
> I am developing an application that does simple thing: Takes an audio
> from pulseaudio (pulsesrc), process it (currently only using volume
> element) and sends it back to the pulseaudio (pulsesink). pulsesrc and
> pulsesink is separated by queue2 to avoid clock issues.
>
> This app also connects itself to PulseAudio and D-Bus (GIO bindings),
> both via GLib's mainloop.
>
> The application logic is simple - it receives signal from D-Bus and
> then performs fade in or fade out on the signal. To schedule fade
> steps I use GLib's g_timeout_add().
>
> From time to time I encounter strange segfaults. Once it was caused by
> EINTR. The next one was related to PulseAudio mutexes. The last one
> was was thrown from libc itself. (unfortunately I had stripped
> binaries installed so I cannot debug that case).
>
> I guess that those segfaults are related to threading. Even if I don't
> spawn any threads in my app, seems that underliying libraries
> (including GStreamer) do that. When I list /proc/PID/tasks, I find 8
> PIDs.
>
> In know that it's not too good practice, but I store current state of
> the app in global variables. When GLib's timeout callback is called I
> check that state, and change "volume" element's properties.
>
> Is it possible that timeout callback is called from different thread
> than "volume" element operates and that causes those hangs?  Should I
> perform somehow locking to avoid those issues?
>  

Timeouts are scheduled from the mainloop. Just add another global var
main_thread=g_thread_self() and then add an assert to your callback
g_assert(main_thread==g_thread_self());

When asking this kind of questions, please add a pointers to where we
can look at the source. Also run your app under e.g. valgrind to see if
it yells a bout certain kind of errors.

Stefan
> Thank you in advance,
>
>  

_______________________________________________
gstreamer-devel mailing list
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel