AudioPlayer Stop() and SkipToNextTrack() broken?

[indragiek]

This is something I had working before (a long time ago), but it seems to have broken in a recent commit. First of all, here's the code I'm using to enqueue songs:

- (BOOL)enqueueURL:(NSURL*)url
{
    AudioDecoder *decoder = AudioDecoder::CreateDecoderForURL((CFURLRef)url);
    if (decoder == NULL) { return NO; }
    decoder->SetRenderingStartedCallback(renderingStarted, self);
    decoder->SetRenderingFinishedCallback(renderingFinished, self);
    if ((_player->Enqueue(decoder)) == false) {
        NSLog(@"no decoder");
        delete decoder;
        return NO;
    }
    return YES;
}

I adapted it directly from the examples, so I think it should be alright. Here's the first problem scenario

1. Enqueue song and call Play() ---> song plays fine
2. User clicks the "next" button on my audio player
3. Call Stop(), and then ClearQueuedDecoders()
4. Enqueue the next song
5. Call Play() ---> no audio but there are no errors either

Second problem scenario:

1. Enqueue two songs and call Play() ---> first song starts playing
2. User clicks the "next" button
3. Call SkipToNextTrack() ---> second song should start playing, but nothing happens (no audio)

As mentioned earlier, this is code that worked fine before, so I'm guessing something must've broken recently.

[sbooth]

I recently changed the default behavior so that decoders are no longer automatically opened when they are created. There is a static method in AudioDecoder that can be used to set whether or not decoders should be automatically opened, or they can be opened by calling Open() directly. I think that your first problem scenario could be resolved by calling Open() before you enqueue the decoder.

I'll have to investigate the second scenario a little bit more.

[indragiek]

Thanks for the reply. Calling AudioDecoder::SetAutomaticallyOpenDecoders(true); seems to have fixed both issues for the most part, but I'm still experiencing some (random) playback issues where if I enqueue a decoder and immediately call Play(), there is no audio and I have to call Play() a second time.

[sbooth]

This is not totally unexpected behavior, because if the decoding thread hasn't had time to begin decoding before you call Play() the player will automatically stop itself. This behavior is not ideal, but since I don't want to lock the player for an indeterminate amount of time in Enqueue() it's the compromise I made. One way around this is to add a decoding started callback to your decoder, and call Play() when that callback is invoked. This will ensure that the player will have audio and that it won't stop itself.

[indragiek]

This does work, but there's a minor problem. The rendering started callback is actually never called unless Play() is called first. To work around this, I call Play() immediately after enqueueing, and then I call it again in the renderingStarted callback for good measure. It might be nice to add another callback for when the data has begun decoding and is ready to play, but hasn't actually started playing yet.

EDIT: After further testing, it seems that the issue is still there even with this workaround

[sbooth]

You need to add a decoding started callback. The decoding started callback is called once the decoding thread begins decoding the audio. It will be called regardless of the player's state after a track has been enqueued.

[indragiek]

Thanks Stephen, I got mixed up between the rendering and decoding callbacks. This works great, thank you.