Glib mutex performance with uClibc 0.9.28

Wed Jul 12 23:16:04 UTC 2006

Hi Peter,

It is quite easy to reproduce the issue, if you are willing to install 2 
packages which are gstreamer-0.10.4 and gst-plugins-base-0.10.5. Just run 
configure without nls support, install it and run:
gst-launch audiotestsrc ! alsasink
and
gst-launch audiotestsrc ! osssink

The osssink stuff is working perfectly, the alsa one is fully buggy (you 
have to listen to your output), with an AC97 sound board.
I am still investigating from where the issue could come, but it is really 
hard to track down, the alsa implementation is much more complexe to 
understand. But my current status:

Gstreamer is spawning 4 differents threads, one could be considered as a 
master one, it is the time keeper for synchronazing the other, through 
thread signals.
1 threads is used to construct the pipeline ( exchange between different 
stages ).
1 thread is used to send data to the render thread.
Last thread is used to render the sound, under gdb this is mostly the 
number 5 (number 1 is the original binary).

The stack you will get with alsa is something like:
#0  0xb7bdd218 in poll () from /lib/libc.so.0
#1  0xb7afede1 in snd_pcm_wait_nocheck (pcm=0x80efc90, timeout=-1)
     at pcm.c:2300
#2  0xb7afef94 in snd_pcm_wait (pcm=0x80efc90, timeout=-1) at pcm.c:2269
#3  0xb7b03ca5 in snd_pcm_write_areas (pcm=0x80efc90, areas=0xbefffc30,
     offset=0, size=1, func=0xb7b0eb2c <snd_pcm_mmap_write_areas>) at 
pcm.c:6485
#4  0xb7b0edcc in snd_pcm_mmap_writei (pcm=0x80efc90, buffer=0x80dc6b0, 
size=1)
     at pcm_mmap.c:186
#5  0xb7afd121 in snd_pcm_writei (pcm=0x80e32d0, buffer=0x80dc6b0, size=1)
     at pcm_local.h:401
#6  0xb7b7a5ae in gst_alsasink_write (asink=0x80d74a0, data=0x80dc6b0,
     length=2) at gstalsasink.c:902
#7  0xb7aaeda6 in audioringbuffer_thread_func (buf=0x805b8a8)
     at gstaudiosink.c:177
#8  0xb7c6fce8 in g_static_private_free () from /usr/lib/libglib-2.0.so.0
#9  0xb7cba4f9 in pthread_start_thread () from /lib/libpthread.so.0
#10 0xb7bdefae in clone () from /lib/libc.so.0

For the thread doing the rendering. As you will see it is using the 
libasound, which is coming with ALSA, there is a call to poll function 
which could imply synchronisation issue ( it is called with -1 timeout ).

( I try with various libasound, with same result, various, gstreamer, glib 
etc ... )

The oss implementation is directly writing raw data to the /dev/dsp0 
device, without so many calls and thread synchronisation.

If you need connection to my system I can provide one to you without any 
issue, the key thing is that you will not hear the sound which is 
frustrating to debug such things.

Jm

The "clock" thread is mostly in this state, he is probably the one 
producing the event to wake up the rendering thread into the poll fd:

#0  0xb7bde2bc in __rt_sigsuspend () from /lib/libc.so.0
#1  0xb7bde2f3 in sigsuspend () from /lib/libc.so.0
#2  0xb7cbc79c in __pthread_wait_for_restart_signal ()
    from /lib/libpthread.so.0
#3  0xb7cb999b in pthread_cond_wait () from /lib/libpthread.so.0
#4  0xb7e67e7e in gst_system_clock_async_thread (clock=0x80d7e68)
     at gstsystemclock.c:254
#5  0xb7c6fce8 in g_static_private_free () from /usr/lib/libglib-2.0.so.0
#6  0xb7cba4f9 in pthread_start_thread () from /lib/libpthread.so.0
#7  0xb7bdefae in clone () from /lib/libc.so.0

The master thread the one which request sound redering is in this state

#0  0xb7bde2bc in __rt_sigsuspend () from /lib/libc.so.0
#1  0xb7bde2f3 in sigsuspend () from /lib/libc.so.0
#2  0xb7cbc79c in __pthread_wait_for_restart_signal ()
    from /lib/libpthread.so.0
#3  0xb7cb999b in pthread_cond_wait () from /lib/libpthread.so.0
#4  0xb7ab5536 in wait_segment (buf=0x805b8a8) at gstringbuffer.c:1095
#5  0xb7ab5929 in gst_ring_buffer_commit (buf=0x805b8a8, sample=1198127,
     data=0x80f039e 
"\215R\204X#^bc>hlpJtiw\020z<|}\034\177\177\177\177~\214}{ryvpso\236k\021g\033b\\\017W\002QJC\r=5\201.&:\037d\027v\017x\atpt\211\004z 
\030y&%|2\235J\230\223\217\030\214\2107\206\203?\202", len=1024) at 
gstringbuffer.c:1201
#6  0xb7ab1639 in gst_base_audio_sink_render (bsink=0x80d74a0, 
buf=0x80ed908)
     at gstbaseaudiosink.c:610
#7  0xb7f8da32 in gst_base_sink_render_object (basesink=0x80d74a0,
     pad=0x80d7830, obj=0x80ed908) at gstbasesink.c:999
#8  0xb7f8e029 in gst_base_sink_queue_object_unlocked (basesink=0x80d74a0,
     pad=0x80d7830, obj=0x80ed908, prerollable=1) at gstbasesink.c:1168
#9  0xb7f8e5cc in gst_base_sink_chain_unlocked (basesink=0x80d74a0,
     pad=0x80d7830, buf=0x80ed908) at gstbasesink.c:1413
#10 0xb7f8ea01 in gst_base_sink_chain (pad=0x80d7830, buf=0x80ed908)
     at gstbasesink.c:1448
#11 0xb7e59e9d in gst_pad_chain (pad=0x80d7830, buffer=0x80ed908)
     at gstpad.c:3189
#12 0xb7e5a52a in gst_pad_push (pad=0x80602d8, buffer=0x80ed908)
     at gstpad.c:3288
#13 0xb7f92373 in gst_base_src_loop (pad=0x80602d8) at gstbasesrc.c:1381
#14 0xb7e6b9fc in gst_task_func (task=0x80ef280, tclass=0x80ef1a0)
     at gsttask.c:193
#15 0xb7c71a05 in g_thread_pool_free () from /usr/lib/libglib-2.0.so.0
#16 0xb7c6fce8 in g_static_private_free () from /usr/lib/libglib-2.0.so.0
#17 0xb7cba4f9 in pthread_start_thread () from /lib/libpthread.so.0
#18 0xb7bdefae in clone () from /lib/libc.so.0

On Wed, 12 Jul 2006, Peter S. Mazinger wrote:

> On Wed, 12 Jul 2006 jean-marie.verdun at splitted-desktop.org wrote:
>
>> Hi,
>>
>> I fix the threading type issue, it is recognized as posix (forced by hand
>> with-threads configure option) now. The mutex implementation is still
>> slow.
>> I do not face issue with gstreamer 0.8.X family, but this release do not
>> use threading mutex at all !
>>
>> Jm
>
> So you need to enforce posix threads? Though looking at configure, it has
> to pass the checks as well, independently of the fact that you enforce the
> type. Why does not auto-detect then?
>
> Any testcase around? Or could you tell me how to reproduce your
> "slowness"? I would want to check if the (new) linuxthreads works better
> than what is enabled by LINUXTHREADS_OLD.
>
> Thanks, Peter
>>
>> On Wed, 12 Jul 2006, Peter S. Mazinger wrote:
>>
>>> On Tue, 11 Jul 2006 jean-marie.verdun at splitted-desktop.org wrote:
>>>
>>>> Hi,
>>>>
>>>> I am investigating an ALSA issue with Gstreamer. The sound playback is
>>>> really poor and crampy. I am using a basic test with:
>>>> gst-launch audiotestsrc ! alsasink
>>>> the alsasink implementation is heavily using thread mutex implemented into
>>>> glib-2.
>>>> The call to the mutex is done through GST_ALSA_LOCK functions into
>>>> gst_alsasink_write.
>>>> I do not face any sound issue with the osssink, which is not using heavily
>>>> the mutex stuff.
>>>>
>>>> Does any of you have soon meet such issue ? Is there any recommandation to
>>>> build glib-2 ? Various threads implementation seems to be supported from
>>>> posix/dce/solaris/win32. My build is using for ever the gthread-impl.c
>>>> code rather than the gthread-posix.c. This could be a bug into the
>>>> configure script that I need to check.
>>>>
>>>> I am using the 2.8.5 glib release.
>>>>
>>>> Any feedback, or experience result appreciated !
>>>>
>>>> Jm
>>>
>>> with 2.10.3 if I run configure, it tells me that pthread type is posix,
>>> see what yours does
>>>
>>> Peter
>>>
>>> --
>>> Peter S. Mazinger <ps dot m at gmx dot net>           ID: 0xA5F059F2
>>> Key fingerprint = 92A4 31E1 56BC 3D5A 2D08  BB6E C389 975E A5F0 59F2
>>>
>>
>>
>
> -- 
> Peter S. Mazinger <ps dot m at gmx dot net>           ID: 0xA5F059F2
> Key fingerprint = 92A4 31E1 56BC 3D5A 2D08  BB6E C389 975E A5F0 59F2
>