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?

Havener

Answer 1

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.

Havener

It's been a while since I've looked at this code (at a different job now), but as I recall the app went in and out of buffering states without issue. – Havener

argh, mine doesn't go into these states. Thank you for your information, @Havener – Lamm

Answer 2

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.

Nineveh

Under what circumstances is it appropriate to call ReportGetSampleCompleted? That seems to be the crux of the issue - the only time I know I have finished buffering, I'm on a different thread and can't safely call it. – Havener

It's safe to call if there's been a GetSampleAsync you weren't able to provide a sample to. Maybe you've got another issue here... – Nineveh

It's certainly possible that there's another issue, but I'm positively observed that reporting a sample from a ThreadPool thread (using the same sample-reading code path) results in an exception marshalled from a COM error; the same code succeeds as documented when called from within a call to GetSampleAsync. This is both on-device and in the emulator. – Havener

The exception is marshalled as a NullReferenceException. I have verified in the debugger that nothing that I pass to ReportGetSampleCompleted is null: the sample is constructed, it has the right stream description, attribute keys, etc. The stack trace shows the throwing class to be XcpImports which is just mapping HRESULTs to predefined exceptions. – Havener

@PaulAnnetts I tried what you suggested and it actually works. Main part is to call ReportGetSampleCompleted after ReportGetSampleProgress(1.0); But PlayState never goes to Buffering. – Lamm

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.

Otherwhere