1. 16 May, 2017 2 commits
  2. 09 Mar, 2017 1 commit
  3. 24 Sep, 2016 1 commit
  4. 20 Aug, 2016 1 commit
  5. 15 Apr, 2016 1 commit
    • Jan Schmidt's avatar
      Revert "pulsesink: uncork if needed upon commit" · 46a3c9ac
      Jan Schmidt authored
      This reverts commit 0dd46acc.
      
      With some audiosinks, starting the ringbuffer on the first commit
      causes audio glitches at startup by starting to output segments
      from the ringbuffer before it has been filled / fully prerolled. This
      doesn't usually happen with pulsesink because we map the pulseaudio
      ringbuffer directly, but we should keep things consistent with
      other sinks with regards to startup latency, plus it gives more
      headway to avoid glitching, should the initial 2nd segment take
      more than 10ms to generate.
      
      https://bugzilla.gnome.org/show_bug.cgi?id=657076
      46a3c9ac
  6. 24 Mar, 2016 1 commit
  7. 05 Nov, 2015 1 commit
  8. 15 Jul, 2015 1 commit
  9. 12 Jun, 2015 1 commit
  10. 09 Mar, 2015 1 commit
  11. 13 Feb, 2015 1 commit
  12. 26 Jan, 2015 1 commit
  13. 10 Jan, 2015 1 commit
  14. 28 Oct, 2014 1 commit
  15. 23 Oct, 2014 1 commit
  16. 22 Oct, 2014 1 commit
  17. 30 Sep, 2014 2 commits
    • Arun Raghavan's avatar
      pulse: Add some documentation about threading and synchronisation · 2a3adec2
      Arun Raghavan authored
      This gives a quick introduction to how the pulsesink/pulsesrc code
      interacts with the pa_threaded_mainloop that we start up to communicate
      with the server.
      2a3adec2
    • Arun Raghavan's avatar
      pulsesink: Make emitting stream status messages synchronous · 0ed08ac3
      Arun Raghavan authored
      The stream status messages are emitted in the PA mainloop thread, which
      means the mainloop lock is taken, followed by the Gst object lock (by
      gst_element_post_message()). In all other locations, the order of
      locking is reversed (this is unavoidable in a bunch of cases where the
      object lock is taken by GstBaseSink or GstAudioBaseSink, and then we get
      control to take the mainloop lock).
      
      The only way to guarantee that the defer callback for stream status
      messages doesn't deadlock is to either stop posting those messages, or
      make sure that the message emission is completed before we proceed to
      any point that might take the object lock before the mainloop lock
      (which is what we do after this patch).
      
      https://bugzilla.gnome.org/show_bug.cgi?id=736071
      0ed08ac3
  18. 29 Jun, 2014 2 commits
  19. 26 Jun, 2014 1 commit
  20. 21 Jun, 2014 1 commit
  21. 04 May, 2014 2 commits
  22. 17 Mar, 2014 1 commit
  23. 16 Mar, 2014 2 commits
  24. 18 Feb, 2014 1 commit
  25. 04 Dec, 2013 1 commit
  26. 18 Nov, 2013 1 commit
  27. 22 Aug, 2013 6 commits
  28. 21 Aug, 2013 2 commits
  29. 19 Aug, 2013 1 commit