[Bug 690937] alsasink: playing video files with gst-launch causes CPU 100%

[GStreamer (bugzilla.gnome.org)]

https://bugzilla.gnome.org/show_bug.cgi?id=690937
  GStreamer | gst-plugins-base | 0.10.28

--- Comment #4 from Daniel Drake <dsd at laptop.org> 2013-01-21 17:41:58 UTC ---
Created an attachment (id=234034)
 View: https://bugzilla.gnome.org/attachment.cgi?id=234034
 Review: https://bugzilla.gnome.org/review?bug=690937&attachment=234034

alternative patch that shares the lock

I don't have very extensive knowledge of ALSA, so I'm not immediately sure of
the the answer there.

But, through some experimentation: without taking yanghuolin's patch, simply
taking GST_ALSA_SINK_LOCK while calling snd_pcm_delay() does not solve the
issue. Now the audio plays OK but the video plays back with a framerate of
about 1 new frame being shown every 10 seconds (and plenty of "A lot of buffers
are being dropped" warnings).

Through reading the source, I estimate that this is caused because
GST_ALSA_SINK_LOCK is taken while we call snd_pcm_wait(), which is a function
that actually sleeps until buffer space is available. I guess that prevents the
snd_pcm_delay() call from executing within any reasonable timeframe, causing
the above effect.

Experimenting further, we *can* share the single ALSA lock if we drop the lock
while sleeping, as in the attached patch. Now the video and audio plays back
fine. However, I'm not sure of the implications of dropping the lock while
calling snd_pcm_wait() are - is this 100% safe?

-- 
Configure bugmail: https://bugzilla.gnome.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
You are the assignee for the bug.