Buffering issues -- do we adjust the cache through a setting in mopidy or mopidy-tunein?

[ibex-are-goats]

Thank you for making this extension!

I'm trying to diagnose skips in the audio, and I THINK it's simply that mopidy-tunein is caching less than my desktop software does, so I'd like to try manually increasing the size of the cache/buffer. Is that something we change in your extension, or is there a general setting in mopidy?

Thanks!

[kingosticks]

Mopidy has https://docs.mopidy.com/en/latest/config/#confval-audio-buffer_time

By all means try adjusting it but Gstreame's buffering behaviour for 'live' radio streams can sometimes behave poorly and you might find your log shows it see-sawing between 0 and 100% buffering all the time. Mopidy does now offer a fix for that but it's not always wanted so I haven't come up with a way to use it here yet. Tunein offers a mixture of live radio and historic shows/podcasts etc.

[ibex-are-goats]

Results: Changing buffer_time didn't make a difference, unfortunately. I've since gone to try different streaming services by adding their link directly into mopidy, and they're playing back fine. So that means it's just some streams, and/or just tunein. Not sure. At least I know now that it's not my internet or the box's decoding ability.

[kingosticks]

I do need to look at utilising the new buffering option, would you mind sharing what tunein stream you were using so I can test with it?

[ibex-are-goats]

Well some more good news: I just got done comparing the top stream here to its Tunein counterpart: https://gist.github.com/nevillepark/d8358256e05a23250ad845a70776776e

And eventually I did catch it skipping too. So it's not just a Tunein thing.

I also used the mpv.net app to listen to the stream on my computer, and that app handily shows its own buffer size, and you can see the performance of the buffer/cache matching your own download speed bursts. It played back fine in this app, I just guess some providers are just providing a bursty stream.

About my mopidy hardware, it's a Rpi1 (like a zero) with a Hifiberry DAC+. Only 80MB memory used, 280MB free. The CPU utilization is around 15% for mopidy and 15% for snapserver and 6% for snapclient. When the stream audio skips, the CPU utilization drops down, and I assume the first event causes the second.

Side note: I just noticed that the stream is higher pitched than it should be. There are a lot of hardware devices available in snapclient -l to select for --soundcard in /etc/default/snapclient and I've gotta test each one to see what works and what doesn't. All of this stuff is up in the air for me because I can't find much good documentation online, so I'm doing the legwork myself as a novice. I don't THINK the hardware question is the cause of the stream skipping, because I listened to other streams and local files that didn't skip. But maybe there is a hint here, so I have to mention it to you. Maybe other file types aren't coming out high pitched and rushed, or maybe this is a totally separate thing.

I hope this points you in the right direction! :)

[kingosticks]

Related to https://github.com/mopidy/mopidy/issues/1749#issuecomment-568135365

To be clear, I am reluctant to make all streams "live" since that removes the ability seek them. Which is bad for things like podcasts.

[rkachowski]

Side note: I just noticed that the stream is higher pitched than it should be. There are a lot of hardware devices available in snapclient -l to select for --soundcard in /etc/default/snapclient and I've gotta test each one to see what works and what doesn't. All of this stuff is up in the air for me because I can't find much good documentation online, so I'm doing the legwork myself as a novice. I don't THINK the hardware question is the cause of the stream skipping, because I listened to other streams and local files that didn't skip. But maybe there is a hint here, so I have to mention it to you. Maybe other file types aren't coming out high pitched and rushed, or maybe this is a totally separate thing.

@ibex-are-goats I had a similar issue due to the sample rate in snapcast and the mopidy stream being inconsistent - In my case everything was pitched down slightly.

In mopidy i have my output set to

output = audioresample ! audioconvert ! audio/x-raw,rate=44100,channels=2,format=S16LE ! wavenc ! filesink location=/home/pi/music/mopidy

and made sure snapcast was also at 44100 sample rate which fixed everything

[kingosticks]

@rkachowski is that different to how Snapcast suggest setting it up? If so can you ask them to fix it, please?

[rkachowski]

@kingosticks sorry this is a tangent - I came to this issue from a related ticket on mopidy due to buffering issues. I'm trying to point out that the change in pitch is a different and unrelated issue, I don't actually use snapcast anymore.

[kingosticks]

Sure, I understand that and it's fine. I'm just checking if Snapcast document the rate setting correctly.

[rkachowski]

It's just a configuration issue, snapcast needs to expect the audio at the same sample rate as mopidy outputs it otherwise it's played back with more / less samples than expected, resulting in unexpected pitchshift.

https://github.com/badaix/snapcast/blob/master/doc/player_setup.md#streams https://github.com/badaix/snapcast/blob/master/doc/player_setup.md#mopidy

[kingosticks]

Yes. OK. So to be clear, people just need to make sure whatever "stream" setting they have configured in their snapserver config matches their Mopidy output config. The Snapcast documentation suggests using 48k for Mopidy and that is apparently the snapserver default, so their documentation is correct as it is. Super.

[kingosticks]

I think this would be fixed by https://github.com/kingosticks/mopidy-tunein/pull/48