After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 695187 - directsoundsrc: occasional garbled audio
directsoundsrc: occasional garbled audio
Status: RESOLVED OBSOLETE
Product: GStreamer
Classification: Platform
Component: gst-plugins-bad
1.0.5
Other Windows
: Normal normal
: git master
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2013-03-05 07:09 UTC by John Stumpo
Modified: 2018-05-05 15:26 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description John Stumpo 2013-03-05 07:09:35 UTC
I'm using GStreamer on Windows to feed audio input to an icecast server, using directsoundsrc to capture. It works nicely most of the time, but sometimes after an extended (but variable; it enters this state once or twice a week but unpredictably) period of time after the stream is started, the audio becomes garbled. I know it's directsoundsrc because immediately after it in my pipeline I tee the stream three ways (to stream in three formats), and all of them are affected.

The specific garbling is that snippets of audio are replaced with the corresponding audio from two seconds later in time. The intervals on which this occurs always begin exactly a fifth of a second apart, and their length varies, but is usually 1500-2000 samples (at 48 kHz). This suggests to me that directsoundsrc is getting into a state where it is sending buffer contents forward in the pipeline while they are still being written into by DirectSound. The fact that a look at the source shows directsoundsrc using a two-second buffer makes this seem especially likely.

It starts working correctly again just as randomly as it enters the garbling state, though I usually just restart the pipeline in question when it gets into that state.

I fortuitously heard a transition into the garbling state once. The snippeting-forward-in-time behavior began immediately as described above, while the audio the snippets are overlaid on jumped back by two seconds (i.e. the last two seconds repeated once). This seems to suggest that the snippets are live and what they are overlaid on is from the last cycle through the buffer.

Hopefully this is enough information to track this down. It'll be annoying to get samples, backtraces, or dumps, and I didn't think to save what I analyzed.

I see the "If the plug-ins break, you can't complain - instead, you can fix the problem and send us a patch" part in -bad's README, but I figured I'd leave this here anyway so that if someone decides to do some work on this plugin they'll see it.
Comment 1 Tim-Philipp Müller 2018-05-05 15:26:33 UTC
Sorry no one ever got around to investigating this. However, there isn't really a lot of info to go on and it's not exactly easy to reproduce either.

There have been a lot of changes in directsoundsrc since then, and in any case we recommend to use the WASAPI plugin instead these days, so I think we'll have to close this as it doesn't contain a lot of actionable info.

Please re-open if you're still having problems with WASAPI elements in 1.14 or git master, thanks!