[Bug 793289] wasapi: Several improvements to latency and glitch-free playback

[GStreamer (GNOME Bugzilla)]

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

--- Comment #12 from Nirbheek Chauhan <nirbheek.chauhan at gmail.com> ---
(In reply to Sebastian Dröge (slomo) from comment #9)
> Comment on attachment 368127 [details] [review]
> wasapisink: pre-load the buffer with silence
> 
> Only needed for the sink? And you don't actually fill the buffer with
> silence, but just get and release it. Intentional?

Yes, this is only needed for the sink because there's a possible race where
WASAPI relinquishes the device to us and before the first streaming event hits
us, the driver flips the buffer and writes out garbage or an old buffer.

While releasing, we set the SILENT flag which tells wasapi to write out
silence.

(In reply to Sebastian Dröge (slomo) from comment #10)
> Comment on attachment 368128 [details] [review]
> wasapisink: Re-align device period if necessary
> 
> This also makes sure to set the correct things in the ringbuffer spec? Then
> it should be fine, but ugly :)

Yeah, we set this (potential) device period (in ms) on the device, and get the
actual value back (in frames) from GetBufferSize. We then use that to set
segsize and segtotal on the spec, and the acquire() function sets
latency_time/buffer_time using that.

(In reply to Sebastian Dröge (slomo) from comment #11)
> Review of attachment 368123 [details] [review]:
> 
> ::: sys/wasapi/gstwasapisink.c
> @@ +401,3 @@
> +    use_period = min_period;
> +    /* For some reason, we need to call this another time for exclusive
> mode */
> +    CoInitialize (NULL);
> 
> Isn't this basically refcounted, i.e. you need to uninitialize it the same
> number of times again? If prepare() fails, I'm not sure if unprepare() is
> always called

You're right, it looks like it's not, so we need to release a bunch of other
things that are released in unprepare() too, will add a new patch for that
instead of trying to fiddle with rebase too much.

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