1. 04 Feb, 2013 1 commit
  2. 31 Jan, 2013 2 commits
  3. 29 Jan, 2013 1 commit
  4. 28 Jan, 2013 1 commit
  5. 27 Jan, 2013 1 commit
  6. 25 Jan, 2013 2 commits
  7. 24 Jan, 2013 1 commit
    • yanghuolin's avatar
      alsasink: don't use 100% CPU · 67a7b5a9
      yanghuolin authored
      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
      67a7b5a9
  8. 19 Jan, 2013 1 commit
  9. 17 Jan, 2013 1 commit
  10. 16 Jan, 2013 2 commits
  11. 15 Jan, 2013 5 commits
  12. 14 Jan, 2013 2 commits
  13. 09 Jan, 2013 1 commit
  14. 07 Jan, 2013 1 commit
  15. 31 Dec, 2012 2 commits
  16. 29 Dec, 2012 1 commit
  17. 23 Dec, 2012 3 commits
  18. 22 Dec, 2012 3 commits
  19. 21 Dec, 2012 3 commits
  20. 20 Dec, 2012 2 commits
  21. 18 Dec, 2012 3 commits
  22. 17 Dec, 2012 1 commit