Multithread app that just changes volume

[Stefan Kost]

On 06/09/2011 11:32 AM, marcin at saepia.net 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,
>
>