Initial CPU spikes playing back High-Res FLAC (88.2/96khz, 24bit) causes stuttering

Plex Media Server
,
1

Server Version#: 1.28.2.6151
Player Version#: Plexamp 4.2.2-beta1 (headless pi),

Plex Media Server and Headless Plexamp are located on the same Rasberry Pi 4B (2gb RAM).

When I begin the playback of any track (and on any device/client), the Plex Media Server process shows CPU spikes which seem to vary depending on the type of audio file. High-resolution FLAC files cause spikes up to 160% during the first minute or so of playback.

Possibly related is that, during this time, playback of these hi-rez files via Plexamp on the same device as the server will occasionally stop and start.

After a few minutes, playback seems to stabilize and there are no more dropouts.

I have tried increasing swap memory from 100 MB to 2048, but this has not changed the behavior.

I will possibly try to use nice to decrease PMS’s priority or use taskset to ensure that PMS and Plexamp are pinned to different cores.

2

in settings for the Pi (viewed/set using the web gui), what do you have currently set for Advanced → Caching → WiFi caching? setting this to “Only next track” might help, if it’s not already selected

I think you generally want to avoid having to use swap space on the SD card, as the write access is really slow, and this can be a cause of the stuttering during playback

1 Like
3

Oh wow, I didn’t even know about that setting. It’s at 15 tracks right now. I assume you know that this setting for headless plexamp is in effect regardless of whether the pi is connected via wifi or ethernet?

So is the theory, then, that attempting to grab and cache 15 beefy audio tracks at once is killing the cpu and/or memory?

I’ll give it a go!

Also, the swap memory thing was just a guess, top does not indicate that memory is particularly constrained.

4

I think that did, thank you!

I’ll be back if it seems unresolved.

5

I’m reading here that caching to the card is the main culprit of stuttering. Is that the bottleneck for sure? This solution didn’t work for me.

Anything in the 24bit range is unlistenable. I’ve set up caching to only grab the next track, limited bandwidth to 1Mbit, and increased the cache size to 16gb. It fixed the stuttering on everything but my highest bandwidth files.

I have an extra pi4 laying around and could repurpose it but don’t want to go through the process unless it’s actually going to fix the problem—and if it’s SD card i/o speed that’s the issue, I don’t see that being improved on that platform.

Anyone else have thoughts on this? Am I the only one still stuttering along?

This is a fantastic solution, btw—thanks for making it happen.

6

caching to the SD card when low on memory is a common cause of stuttering, but it could also be caused by slow network speed, slow cpu, etc.

what Pi model (and how much memory) are you currently using? and does it have a wired or wifi connection?

regarding your current settings …

the 1Mbps network bandwidth limit might be too low for the highest bitrate files (especially if you tend to skip ahead, you might end up playing something that’s not fully cached yet … and beyond 44/16 FLAC will often exceed 1Mbps … recommend trying 10Mbps)

and the 16GB max cache size will mostly result in a lot of files filling up your SD card … even the minimum 512MB should be enough to hold the currently playing and next track

7

Thanks for the reply and the suggestions.

I’m running a Pi 3 Model B rev 1.2. This should give me 1GB of ram. I could run a wired connection to it, but it’s currently running wireless. I easily get 100Mbit+ of internet when doing a speed test standing next to where the pi is located. Wired would be a pain to do, so I’ve been saving that as a last resort.

In addition, I’ve got a HifiBerry DAC+ board (rev 2.6) and a 7" capacitive touch screen (1024x600 pixels) attached. So there are other things that require cycles.

The server side is fine. I’ve tested serving multiple 4k streams so the upstream bandwidth should be fine.

Your point on the 1Mbit setting is solid. I was thinking only about caching… not whether that would throttle my entire connection. Duh. Of course it does.

I’ll knock back the cache size. It didn’t seem to make much of a difference when I increased it.

Dropping bandwidth to 1mbit seemed to make it marginally better (only 2-3 short drops per track rather than 5-6 long gaps). I’m running it at 5 right now and I’m still getting gaps.

I’ll say one weird thing… it’s as though the song is still playing, I just can’t hear it. It’s not like it stops playing and picks back up… it’s like it keeps going and I can’t hear it. I think. Maybe I’m losing my mind.

Thanks again for your expertise. This is sooooo close to being perfect for what I need I can taste it. This is the last bit. :slight_smile:

8

thanks for the additional details on your setup … and you’re probably right about the touchscreen impacting the available system resources, especially for a pi3 (might want to ssh to the pi and run top to compare system resources while plexamp is idle vs when it’s playing and having issues?)

also your wifi connection on the pi might be quite a bit slower than whatever device you’re using in its vicinity for a speedtest … looking at the plex server dashboard (from either the plex web app or the mobile plex dash app) during playback should show the actual transfer rate

1 Like
9

Here’s what it looks like with plexAmp stuttering its way through a 24/96 file:

top - 18:10:57 up 15 min,  3 users,  load average: 2.90, 2.40, 1.59
Tasks: 184 total,   1 running, 183 sleeping,   0 stopped,   0 zombie
%Cpu(s): 10.2 us,  6.0 sy,  0.0 ni, 83.2 id,  0.3 wa,  0.0 hi,  0.3 si,  0.0 st
MiB Mem :    909.6 total,     25.5 free,    565.8 used,    318.3 buff/cache
MiB Swap:    100.0 total,      0.0 free,    100.0 used.    252.0 avail Mem

If I had to guess, memory is pinned and it’s going to swap. Optimally plexamp is caching to RAM, not going to swap. Depends on what that 318 MB in buff/cache is getting uses for. Maybe that’s what I’m hearing, the switch to swap?

Watching the bandwidth on the server, I notice two things. First, it sticks with 5mbit nicely and it’s clear how setting it any lower would mean I’m risking running out of data at 1mbit since it often finishes caching the next track 4/5 of the way through the current track. Second thing is that I get gaps at exactly the point where the next track starts to be dowloaded (jump in bandwidth) and again when it’s finished (drop in bandwidth).

Thanks for helping troubleshoot this with me.

10

Yes, it sure looks like the pi3 just doesn’t have enough memory to deal with these hi-res files … I also had this issue on a pi3 (and that was without a touchscreen), resolved when I switched to a pi4 with more RAM

I haven’t tried this myself (so can’t advise on the details), but another possible option with the pi3 would be adding an external USB drive (HDD or SSD, not a slow flash drive) and using it as faster swap

11

Sure does. When I’m running 16/44 files everything works beautifully and I’m showing 50MB free of ram. So… it’s that close to working at higher resolutions.

Since this is running on top of a full install of Raspbian with a browser instance in place to provide control and UI for my media center, I suspect I can do better with the Pi3. Anyone have ideas on services I could kill to free up more RAM? I’m 100% sure my install is bloated for the few services I need just to run Plexamp.

I could decommission the Pi4 I have in place running retroPi. I don’t use it much. Obviously with the continued supply issues on the pi side I can’t just go buy one. But I’d rather not if I can get the RAM issue solved easily.

12

I have a 3b+ that stutters and gets temporarily frozen, especially when skipping tracks. To confirm, when you upgraded to a 4, skipping tracks works as planned and is snappy?

13

in my case yes, switching to a system with more memory resolved the stuttering I sometimes experienced with hi-res files using a pi3 (and its 1GB of RAM) … this assumes you’re not also limited by a bad wifi connection etc.

I have not tried a system with 2GB of RAM, but expect this would be good enough … I have tried a pi4 with 8GB, a nanopi r4s with 4GB, and an odroid c4 with 4GB … all work great

1 Like
14

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.