Playback opus sometimes stuck on `buffering` about player-sdk-swift

[alexiscreuzot]

Here are 2 .opus files :

• working.opus
• not_working.opus
  Archive.zip

The behavior is the same on simulator and actual device, although that's to be expected as I'm on a M1

Although I put Logger.verbose = true, I don't seem to get any logs from the library

[FlorianAtNacamar]

Intension of this player SDK is to support live and on demand audio. A pretty good guess to distinguish between infinite and finite audio is to take the header content-length into account. In the demo app we offer on demands in the bottom of the picker wheel. "organ sound" and "music" are mp3s and "paper lights" is opus. Finite audio can be paused.

I did reproduce the problem of short audio with mp3s shorter than 500 ms as well. (With opus there were empty pages that just extended the same problem to durations shorter than 1.5s.)

Currently, in a fixed developer version, all durations can be played. We will fix this (maybe in a version 0.13.2).

[FlorianAtNacamar]

Dear Alexis,
with version 0.13.2 this is fixed.

I like the two opus-files you sent here. Woud you mind if I add them to our test-files-Repository?

[alexiscreuzot]

I don't mind at all. Thanks for your work @FlorianAtNacamar !

[FlorianAtNacamar]

I'm using Xcode 13 and iOS 15 simulator during development. And I also played local opus files. So, what is the difference between playing foo.opus and bar.opus?

Idea 1: Mapping family != 0
The playerSDK does not support ogg with mapping families other than 0 yet, because we assume other mapping families are very rare. If another one is detected you could see it in the log. See file OpusData.swift lines 222..224

       guard opusHead.mappingFamily == 0 else {
            let errMsg = "opus mapping family \(opusHead.mappingFamily) not supported, currently only 0"
            Logger.decoding.error(errMsg)

If so, we know more.

Otherwise:

Idea 2: real devices
Does the YbridPlayerSDK play the file on a real device? Or does it work on your Mac (if it is one)? If you opened player-sdk-swift.xcworkspace in Xcode you can execute UseAudioPlayerTests in target player-sdk-swiftUITests. Run a test with your file-url on a connected device (or 'My Mac'). Does the same problem occur?

Idea 3: verbose logging
Did you have a look at the log? Please set Logger.verbose = true in the beginning of test code to see more details. Could you post the resulting log into this thread? On a Mac, you can also use console.app and filter by subsystem io.ybrid.player-sdk-swift.

Idea 4: me
If you don't mind, you can pass me the file itself so I can have a look.

Thanks for your interest and for your post.

[FlorianAtNacamar]

First of all thank you very much for sending both audio files. I have to admit: The current version of the SDK has a problem with buffering and scheduling of short audio.

Originating from playing live and infinite audio, we implemented a prebuffering of 0.5s. Rebuffering is currently set to 1.5s, so after a network stall decoded audio is buffered until 1.5 s are ready to be played.

In both opus files there are two empty pages in the beginning of ogg/opus data that unfortunatetly trigger the rebuffering condition! working.opus contains 1.64s of audio, and not_working.opus 1.08s. Working.opus is played and not_working.opus waits. That’s really not nice, but it explains the behaviour.

My learning from this issue

• Prebuffering and rebuffering lead to problems with audio material shorter than these durations.
• Empty audio blocks should not lead to rebuffering.
• When loading is finished, the resiudal audio should be scheduled, without taking pre or rebuffering into account.

Of course there are several ways to solve the problems and I will. I just wanted to keep you informed.

[alexiscreuzot]

Thanks a lot for the explanation, I was actually expecting something along those lines as I saw the example project is only showcasing live streams. By the way it's working all the time with mp3, so I guess the system is different for this format.
I'm not sure if it's technically possible to detect wether an URL points to a live stream or a finite audio file.