AudioStreamer cuts off last second or two of audio

[Bo98]

It seems that AudioStreamer cuts off the last second or two of audio.

I do have a workaround for this which stops the streamer once the progress bar hit 100 but this isn't a proper fix for it.

[alexcrichton]

What's the workaround that you have?

[Bo98]

In the handleBufferCompleteForQueue:buffer:, I removed/commented out the [self setState:AS_DONE]; in the if statement.

    if (buffersUsed == 0 && queued_head == NULL && stream != nil &&
        CFReadStreamGetStatus(stream) == kCFStreamStatusAtEnd) {
        assert(!waitingOnBuffer);
        //[self setState:AS_DONE];

    /* Otherwise we just opened up a buffer to try to fill it with some cached
     * data if there is any available */
    } else if (waitingOnBuffer) {
        waitingOnBuffer = false;
        [self enqueueCachedData];
    }

I then inserted this if statement into the updateProgress: method in the ViewController(s):

    if ([progressSlider value] == 100) {
        [streamer stop];
    }

I think that is all I did.

[alexcrichton]

Does that commit appear to fix the problem? I have a hard time reproducing this myself.

[Bo98]

Perfect. That does the trick.

[Bo98]

Okay the fix is causing a problem.

This isn't the easiest to reproduce but after sliding the progress bar to the left (the beginning of the audio) several times, the streamer sets the states as AS_DONE because the seekBarOffset sometimes == 0 after a few slide backs. Tthe ViewController picks this up and destroys the streamer - deallocating it - and causing a Zombie which crashes the app.

[alexcrichton]

Is this in your own app or in the sample one provided?

[Bo98]

It was in my own app but I've just tested the sample and that crashes too and the Zombies instrument still shows a zombie. In fact it appears to be easier to crash the app with the sample - first slide back instead of a few.

Both Mac and iOS.

[alexcrichton]

What's the URL you're using? I'm just trying to reproduce this.

[Bo98]

I have a few which is all causing this.

Try this bass test mp3:

http://www.largesound.com/ashborytour/sound/brobob.mp3

And forgot to mention that the Mac app doesn't actually crash when run through Xcode - it outputs the error log to the output debug area. I'm not sure if this is what normally happens with Mac apps because I develop for iOS.

[Bo98]

Perhaps a private BOOL which gets set to YES after the AudioQueueStop(audioQueue, false); and is checked as a part of the if statement to set the state as AS_DONE?

[Bo98]

That does the trick. Thanks.