Multithread app that just changes volume
ensonic at hora-obscura.de
Mon Jun 13 15:01:57 PDT 2011
On 06/09/2011 11:32 AM, marcin at saepia.net wrote:
> 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
> 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
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.
> Thank you in advance,
More information about the gstreamer-devel