2

I wrote a music player using OpenSL ES. It works fine besides one warning message coming out of libOpenSLES library. Here is the message.

03-05 00:10:15.367: W/libOpenSLES(12055): Missed SL_PLAYEVENT_HEADATNEWPOS for position 7000; current position 724009
...
03-05 00:10:27.226: W/libOpenSLES(12055): Missed SL_PLAYEVENT_HEADATNEWPOS for position 329015; current position 816013

It comes when I seek a media track. Sometimes I can seek with no warning, sometimes the message appears in the log.

Implementation is very simple. At initialization I pick up the seek control.

SLObjectItf decoder;
SLSeekItf seek;
...

SLresult result = (*decoder)->GetInterface(decoder, SL_IID_SEEK, &seek);

Then later, when user changes track position, I call SetPosition method as following.

SLresult result = (*seek)->SetPosition(seek, position, SL_SEEKMODE_ACCURATE);

Both calls return success result, and position change works all the time too. The only issue is the warning message mentioned above.

Any ideas why this message comes and how to avoid it?

Update:

Although the half of bounties were automatically assigned, the question is not yet answered. We don't know what causes the issue and how to avoid it.

sergej shafarenka
  • 20,071
  • 7
  • 67
  • 86

1 Answers1

2

A quick google of part of that log message found the following code snip, with your log print in the middle here, (complete source):

    // nextVirtualMarkerMs will be set to the position of the next upcoming virtual marker
    int32_t nextVirtualMarkerMs;
    if (mObservedPositionMs <= virtualMarkerMs && virtualMarkerMs <= positionMs) {
        // we did pass through the virtual marker, now compute the next virtual marker
        mDeliveredNewPosMs = virtualMarkerMs;
        nextVirtualMarkerMs = virtualMarkerMs + mPositionUpdatePeriodMs;
        // re-synchronize if we missed an update
        if (nextVirtualMarkerMs <= positionMs) {
            SL_LOGW("Missed SL_PLAYEVENT_HEADATNEWPOS for position %d; current position %d",
                    nextVirtualMarkerMs, positionMs);
            // try to catch up by setting next goal to current position plus update period
            mDeliveredNewPosMs = positionMs;
            nextVirtualMarkerMs = positionMs + mPositionUpdatePeriodMs;
        }
        notify(PLAYEREVENT_PLAY, (int32_t) SL_PLAYEVENT_HEADATNEWPOS, true /*async*/);

If you search pass a certain point there's some catching up to be done (jump) and perhaps an update was missed, that's what the log is stating, that we need to resynchronize the marker position.

Update The whole code snip above is for calculating the oneshot (a stable temporary state) pause time if interpret the code correct, definition of oneshot, row 116:

    // deferred (non-0 timeout) handler for SL_PLAYEVENT_*
    // As used here, "one-shot" is the software equivalent of a "retriggerable monostable
    // multivibrator" from electronics.  Briefly, a one-shot is a timer that can be triggered
    // to fire at some point in the future.  It is "retriggerable" because while the timer
    // is active, it is possible to replace the current timeout value by a new value.
    // This is done by cancelling the current timer (using a generation count),
    // and then posting another timer with the new desired value.

And you get the log message because of jumping to often for the code to catch up, I think. So try to not jump that often? By the way it's a warning log, it will catch up the next time in this code path.

Magnus
  • 1,483
  • 11
  • 14
  • I have source code locally too and I've interpreted the comments similarly as you did. The question was how to avoid this? – sergej shafarenka Mar 07 '14 at 19:49
  • Updated my answer, sorry for not reading the question to its full extent. – Magnus Mar 07 '14 at 20:59
  • Thanks for looking into this. It happens even when I set position just once. I suspect it's because when I call SetPosition, either event or decoder thread gets blocked for a while. This leads to outdated position state in the player. Although it's just a warning and repositioning work fine - as I mentioned in the question - it's still a warning which doesn't appear with standard Music Player, which uses same API. I just have a bad feeling I use something not exactly correct or in a way it was primarily intended to be used, that's why the question. – sergej shafarenka Mar 07 '14 at 21:21