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

GStreamer (bugzilla.gnome.org) bugzilla at gnome.org
Thu Jan 24 06:20:41 PST 2013


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

Wim Taymans <wim.taymans> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
                 CC|                            |wim.taymans at gmail.com
         Resolution|                            |FIXED
   Target Milestone|HEAD                        |1.0.6

--- Comment #6 from Wim Taymans <wim.taymans at gmail.com> 2013-01-24 14:20:35 UTC ---
I commited the one with two locks.

commit db7ff0e290274d75172aef2544df70e653feb9ea
Author: yanghuolin <Huolin.Yang at delphi.com>
Date:   Thu Nov 15 03:31:47 2012 -0500

    alsasink: don't use 100% CPU

    The root cause is that alsa-lib is not thread safe for the same handle.
    There are two threads in the gstreamer accessing alsa-lib not serilized.
    The race condition happens when one thread holds the old framebuffer
app_ptr
    position in the kernel, another thread advances the framebuffer app_ptr.
    when the former thread is scheduled to run again, it overwrites the app_ptr
    to old value by copying from kernel.Thus,the app_ptr in the upper
    alsa-lib(pcm_rate) become one period size more advanced than the lower
    alsa-lib(pcm_hw & kernel).

    gstreamer uses noblock and poll method to communicate with the alsa-lib.
    The app_ptr unsync situation as described above makes the poll return
immediately because
    it concludes there is enough space for the ring-buffer via the low-level
alsa-lib.
    The write function returns immediately because it concludes there is not
enough
    space for the ring-buffer from the upper-level alsa-lib. Then the loop of
poll
    and write runs again and again until another period size is available for
    ring-buffer.This leads to the cpu 100 problem.

    delay_lock  is used to avoid the race condition.

    Fixes: https://bugzilla.gnome.org/show_bug.cgi?id=690937

-- 
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.


More information about the gstreamer-bugs mailing list