I’ve got a headless pi 4 set up with raspbian, and installed mopidy on it. It’s running as a service.
Sometimes after going to the next song the music starts “cracking”. Voices sound lower, the song itself is quieter but there’s loud noise through it. Faster songs give faster noise (loud pops closer together).
Usually restarting the song (seek 0) fixes the issue, sometimes it’s only fixed after skipping the song.
The music is on a USB3-stick. I see no high CPU nor RAM usage, and swap is disabled. I’ve got no HAT, just the normal aux.
How do I begin to look for the cause?
This isn’t actually Pi Musicbox, is it?
You could try some different audio file formats. You could try moving the files to the SD card. Maybe you could check if the CPU frequency is being dynamically lowered by running vcgencmd measure_clock arm both when it’s working well and when it’s crackling? Could you experiment with HDMI audio output or a USB soundcard?
It’s indeed not but I figured that given the “Pi” part it would fit in this forum best. Correct me if I’m wrong. (And if so, how can I move this post?)
I’ll give vcgencmd measure_clock arm and the usb soundcard a shot tonight, hdmi would be difficult.
Please try some other audio file formats too if you can. What format is giving you the crackling? Also maybe try a different audio player to see if this is a Mopidy (Gstreamer) issue or a Pi firmware issue.
I ran VLC before, that one gave clear audio. (I did have some issues with “waiting for FIFO to clear” in the decoder of VLC, which is the whole reason I switched to Mopidy.) Of top of my head it’s MP3, but I’ll try some other formats too tonight.
Okay, some more information. I’ve added Mopidy to my node-red environment, and implemented “restart” as “seek: 0”. For more advanced commands I use Mopidy mobile.
I just came home, and my wife thinks that restart through node-red does not fix the cracking, but restart in Mopidy mobile does.
I’ll come back to the other suggestions later tonight.
What does ‘restart’ mean in the context of mopidy mobile? If you could translate that to the actual mopidy core API request it does (you’d see it in the debug log) that would be useful.
vcgencmd measure_clock arm always seems to gives back either
frequency(48)=600117184
or
frequency(48)=600169920
Cracking also does not happen when I skip songs (tested +/- 20 times), but when i seek towards the end and let it play on to the next song it happened after 3 times.
“Restart” from mopidy mobile I just figured is actually a “bug”, if you’ve got shuffel turned on, previous results in a restart.
DEBUG 2019-08-13 18:07:34,112 [8110:HttpServer] mopidy.http.handlers
Received WebSocket message from 192.168.0.113: u’{“method”:“core.playback.previous”,“jsonrpc”:“2.0”,“id”:300}’
DEBUG 2019-08-13 18:07:34,126 [8110:MainThread] mopidy.audio.gst
Got STATE_CHANGED bus message: old=GST_STATE_PLAYING new=GST_STATE_PAUSED pending=GST_STATE_READY
DEBUG 2019-08-13 18:07:34,130 [8110:Audio-2] mopidy.audio.gst
Changing state to GST_STATE_READY: result=GST_STATE_CHANGE_SUCCESS
I’ve also managed to capture a relatively short debug log. I hit play on a playlist (in mopidy mobile), it played fine, I "seek"ed towards the end, it played fine still, starts the next song, all noisy. https://pastebin.com/Hw7BQL5s (Is there any way for me to insert a scrollbar here? Then I’ll post the entire log in this forum.)
“restart” seems to be a “bug”, it’s when you have it on shuffle and hit previous. It’s implemented as (I’m quite sure it was, I just typed out an answer and apparently didn’t hit reply but cancel or so) playback.previous
vcgencmd measure_clock arm gives nothing weird.
I just managed to get it reproduced with a relatively short debug log: https://pastebin.com/Hw7BQL5s (can I make a scrollable area here? Then I’ll copy it to this forum.)
I use Mopidy mobile to add a playlist to the current tracklist, and then hit play. First song works fine. I seek towards the end, it still works fine. The next song starts (line 172) and it makes noise.
Okay, it’s fixed. An external USB sound card fixed it. (Or well, so it seems, didn’t have it the last ten or so times.)
Restart apparently was a “bug”, if you hit “previous” when in shuffle (playback.previous) it restarts the current song.
If desired for further development, I still managed to capture a debug log: https://pastebin.com/Hw7BQL5s
Around line 867 the 2nd song of that “session” starts playing, which gives the crackling.
If the issue isn’t present for a USB soundcard then it’s a problem with the rapaberry pi onboard audio and there’s nothing we can do in Mopidy. However, saying that, it’s not an issue I’ve ever encountered. Perhaps there’s a bug in their latest firmware which I don’t have.
Hmm but of course you did say the issue wasn’t present when using other software. Not sure what to make of that.