[Bug 781998] Windows: directsound sink stutter

[GStreamer (GNOME Bugzilla)]

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

--- Comment #8 from Dustin Spicuzza <dustin at virtualroadside.com> ---
Alright, so more playing around, and after spending a long time reading other
sinks and looking at the old 0.10.x directsound ringbuffer patch in #584980...
instead of rewriting the sink, I've hit upon a combination of hacks that seems
to perform as well as WMP. There are two pieces:

* I changed my sync handler to listen for stream status ENTER instead, and when
that occurs then I call AvSetMmThreadCharacteristics. Since stream status ENTER
is emitted by the ring buffer thread in addition to the other threads, the
result is that all threads that seem to be consuming CPU get an elevated
priority, and then the stutter mostly goes away.

* The other piece that helps is modifying the sink to call GST_DSOUND_UNLOCK
before the sleep occurs, and GST_DSOUND_LOCK once again after the sleep -- I
got this idea after noticing a comment in the ringbuffer patch [1] that one
shouldn't hold the object lock while sleeping.

The combination of the two results in output that seems to be as difficult to
get it to stutter as WMP, which is good enough for now IMHO. The CPU usage
seems pretty minimal too.

So where do we go from here?

Ideally, anywhere that Gstreamer creates a thread, we should call the magic API
to get more processing power. It seems like perhaps the sink could listen to
its own bus for these stream enter events and bump the priority there. Or
perhaps on Windows anytime one creates a GstTask then it automatically bumps
the priority?

I did try bumping the priority only on the sink thread, and there were still
stutter issues.

[1]
https://github.com/psi-im/psimedia/blob/master/gstprovider/gstelements/directsound_sinkonly/gstdirectsoundringbuffer.c#L729

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