[Bug 695187] New: directsoundsrc: occasional garbled audio

[GStreamer (bugzilla.gnome.org)]

https://bugzilla.gnome.org/show_bug.cgi?id=695187
  GStreamer | gst-plugins-bad | 1.0.5

           Summary: directsoundsrc: occasional garbled audio
    Classification: Platform
           Product: GStreamer
           Version: 1.0.5
        OS/Version: Windows
            Status: UNCONFIRMED
          Severity: normal
          Priority: Normal
         Component: gst-plugins-bad
        AssignedTo: gstreamer-bugs at lists.freedesktop.org
        ReportedBy: bugstuff at jstump.com
         QAContact: gstreamer-bugs at lists.freedesktop.org
     GNOME version: ---


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.

-- 
Configure bugmail: https://bugzilla.gnome.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
You are the assignee for the bug.