[Bug 773681] directsoundsink: High cpu usage on windows x86

[GStreamer (GNOME Bugzilla)]

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

--- Comment #15 from Dustin Spicuzza <dustin at virtualroadside.com> ---
... and now I've caught up to the rest of you, and I see why the sleep is
necessary. :) I had thought that the gst ring buffer would only feed data as
fast as it was needed, but I see that isn't the case at all.

As I mentioned in 781998.. setting
GST_DEBUG="directsoundsink:5,audiobasesink:5" outputs messages that are
basically, queue a few samples, and then call sink_write A LOT of times. If
there's no sleep, then 100% CPU happens -- and I think the current version in
master does zero sleep a lot.

I did my own little rewrite of the write function, and ended up with mostly the
same result (but hey, I learned a lot). One thing I noticed is that we don't
need the loop inside the write function; just return the number of bytes
written (or 0) and the audiosink caller will just keep looping until the buffer
is completely written. Makes the code easier to understand too.

I think the suggestion to use SetNotificationPositions is the sane way to deal
with it. Allocate segment size number of notifications, all using the same
event, and then wait for that event if the buffer is full.

A simpler solution is anytime a sleep is required, make sure it's always at
least some N (maybe 5ms?), otherwise 100% CPU happens.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.