GNOME Bugzilla – Bug 796280
wasapisink: crash on pipeline tear down on Windows 7
Last modified: 2018-05-23 10:31:26 UTC
After the update to 1.14.1 wasapi sink now no longer crashes on start, but crashes when I destroy the pipeline. But between that it works nicely, so thanks for working on this :) This is what I get (consistently) 0:00:04.890555468 6560 47b5d20 INFO wasapisink gstwasapisink.c:680:gst_wasapi_sink_reset:<wasapisink0> reset called 0:00:04.890849502 6560 47b5d20 ERROR wasapisink gstwasapisink.c:687:gst_wasapi_sink_reset:<wasapisink0> IAudioClient::Stop failed (1): Incorrect function. If there is anything I can provide/help with, please tell me.
Do you have a stack trace of the crash?
Created attachment 372276 [details] stacktrace gdb failed to get a stacktrace right at the crash, but here is one at the last execution of gst_wasapi_sink_reset before the crash. To reproduce: gst-play-1.0 https://github.com/quodlibet/quodlibet/raw/master/quodlibet/tests/data/empty.opus
When compiling the wasapi plugin under MSYS2/MingGW, the following two warnings are emitted: ../../../gst-plugins-bad-1.14.1/sys/wasapi/gstwasapiutil.c: In function 'gst_wasapi_util_init_thread_priority': ../../../gst-plugins-bad-1.14.1/sys/wasapi/gstwasapiutil.c:958:52: warning: assignment from incompatible pointer type [-Wincompatible-pointer-types] gst_wasapi_avrt_tbl.AvSetMmThreadCharacteristics = ^ ../../../gst-plugins-bad-1.14.1/sys/wasapi/gstwasapiutil.c:960:55: warning: assignment from incompatible pointer type [-Wincompatible-pointer-types] gst_wasapi_avrt_tbl.AvRevertMmThreadCharacteristics = ^ Compiler is gcc 7.3.0. Could it have to do with the crash on reset. I did not look at the code luch (lazy me...) but may be the reverting of thread characteristics is broken.
Tha above could be a red herring but note the error about an "Incorrect function" and the warnings that happen when getting pointers to functions.
PS: compiling on Windows 10 (freshly updated a few days ago to stop the nagging...).
One thing standing out is that the code does "hr != S_OK" to check for errors, but it should use "FAILED(hr)". That would explain the kinda bogus error status for IAudioClient_Stop(). I'll give that a try.
OK, scratch that, this line crashes (and gdb is confused as always..): g_clear_pointer (&self->mix_format, CoTaskMemFree); If I free it without g_clear_pointer it works, if I move CoTaskMemFree into a static function it works as well... (??)
ah, right, conflicting calling conventions.
Created attachment 372348 [details] [review] wasapi: Don't pass CoTaskMemFree to g_clear_pointer CoTaskMemFree has a different calling convention than GDestroyNotify and things crash at least with MinGW.
Created attachment 372349 [details] [review] wasapi: use FAILED to detect errors S_FALSE is a valid return value which does not indicate an error. For example IAudioClient_Stop() returns S_FALSE when it is already stopped. Use the FAILED macro instead which just checks if an error occured or not. This fixes spurious warnings when using the wasapisink element.
With that things seem to work fine. Except that I get a lot of clipping noise, but that's another issue I guess.
Review of attachment 372348 [details] [review]: Interesting that I couldn't reproduce this with Cerbero's MinGW or with MSVC.
Review of attachment 372349 [details] [review]: lgtm, thanks!
(In reply to Christoph Reiter (lazka) from comment #11) > With that things seem to work fine. > > Except that I get a lot of clipping noise, but that's another issue I guess. When do you hear the clipping noise? Are you testing on a virtual machine?
Attachment 372348 [details] pushed as adb1df3 - wasapi: Don't pass CoTaskMemFree to g_clear_pointer Attachment 372349 [details] pushed as 2d98a5c - wasapi: use FAILED to detect errors
> When do you hear the clipping noise? When I use the element in Quod Libet (just default playbin). Sometimes when I rebuild the pipeline there is no noise, but I can then trigger the noise again by seeking. I need to come up with a smaller reproduce. > Are you testing on a virtual machine? No.
(In reply to Christoph Reiter (lazka) from comment #16) > When I use the element in Quod Libet (just default playbin). Sometimes when > I rebuild the pipeline there is no noise, but I can then trigger the noise > again by seeking. > > I need to come up with a smaller reproduce. > Which Windows version is this? Can you open a new bug about this, CC me, and attach a sample file? Does this also happen with `audiotestsrc ! wasapisink`?
(In reply to Nirbheek Chauhan from comment #17) > (In reply to Christoph Reiter (lazka) from comment #16) > > When I use the element in Quod Libet (just default playbin). Sometimes when > > I rebuild the pipeline there is no noise, but I can then trigger the noise > > again by seeking. > > > > I need to come up with a smaller reproduce. > > > > Which Windows version is this? Can you open a new bug about this, CC me, and > attach a sample file? > By sample file I mean a recording of the noise.
> Can you open a new bug about this, CC me, and attach a sample file? bug 796354