BackgroundAudioPlayer is 'Playing' but not calling GetSampleAsync()

Question

I am streaming music from the web in a background agent using a custom MediaStreamSource. In good network conditions this works fine, but when network connectivity is spotty a strange problem surfaces.

When a track starts playback, all goes well up through the first call to MediaStreamSource.GetSampleAsync(). Because the connection is spotty, if not enough data is available the source calls ReportGetSampleProgress(double) and returns without reporting a sample. This is in accordance with MSDN documentation and code samples.

What's curious is that there are no further calls to GetSampleAsync at all! As buffering continues, the source continues to ReportGetSampleProgress until a sample is ready, when it calls ReportGetSampleProgress(1.0) to indicate a full buffer.

I've tried several approaches, including:

• ReportGetSampleCompleted when buffering is complete; this fails because download events come in on arbitrary threads and this method is evidently sensitive both to the calling thread and whether a call to GetSampleAsync is on the stack; invalid calling circumstances result in COM errors.
• In the precise error condition, stop and start the BackgroundAudioPlayer: this fails to restart streaming.

How can I get streaming going again once the initial failure to read a sample hangs things?

Answer 1

ReportGetSampleCompleted once data is available is the correct approach in this scenario.

You will have to keep track in your MSS whether you need to report any new sample data immediately or wait for GetSampleAsync to be called.

However watch that failures due to race condition are possible between the various threads involved.

Answer 2

As it happens, a solution appears to be to break the contract suggested by the name GetSampleAsync, and block in that method when not enough data has been buffered. The stream callbacks can then pulse the locked object, and the sample read can be retried. Something like this works well:

private void OnMoreDataDownloaded(object sender, EventArgs e)
{
    // We're on an arbitrary thread, so instead of reporting
    // a sample here we should just pulse.
    lock (buffering_lock) {
        is_buffering = false;
        Monitor.Pulse(buffering_lock);
    }
}

protected override void GetSampleAsync()
{
    while (we_need_more_data) {
        lock (buffering_lock) {
            is_buffering = true;
            while (is_buffering) {
                Monitor.Wait(buffering_lock);
            }
    }

    // code code code
    ReportGetSampleCompleted(sample);
}

It would seem that blocking in an Async method might not be wise, but the experience of running this code on a device suggests otherwise. Per http://msdn.microsoft.com/en-us/library/system.windows.media.mediastreamsource.getsampleasync(v=vs.95).aspx, blocking could prevent other streams from being read. As a streaming music app, we only ever serve one stream at a time, so in this case it seems that we're OK.

I wish I knew a general solution here, though, because this clearly is cheating.

Answer 3

If you don't have any data available then fill a buffer with silence and report that. This will give you time for real data to come in.

You want to center the data to the middle of a PCM range on your silence data or you'll get a click when going silent.

MemoryStream stream = new MemoryStream();

byte[] silenceBuffer = BitConverter.GetBytes( (ushort)(short.MaxValue) );
for(int i=0; i < 1000; i++ )
    stream.Write( silenceBuffer, 0, silenceBuffer.Length );

Gook luck.