Thank you, will plug this info to my AI query and see if that context helps it troubleshoot any better. Meanwhile - this specific issue is being investigated at Headless Plexamp on Pi5 with DAC8x configured for 4.0 output - #7 by tgp-2, but without my specific DAC that limits the efforts there. I posted all logs I had to that point there - this morning I cleared out the logs, stopped everything, did a reboot, did a playback of a 5.1 file, and grabbed a new fresh log, to cut down on historical noise and have a short log of a specific test to current configurations. Plexamp.log (97.5 KB)
Please let me know if that log offers any further insights. Will post on the other thread as well.
Your app is a gamechanger in the world of surround sound!
Up until now the only diy surround option for 5.1 in the car is dated SACD/DVD head units, and burning DVDs.
When I pull out a disc to put in a car radio, I get looks that I’d expect one to get if they pulled out an 8-track to put into a car 8-track player. Time moves along too fast.
This takes things beyond setting something up to take a USB drive, which I think some but very few cars can support with surround - my whole surround and quad library in the cloud, playable from a Pi.
Anyways, your simple explanation, along with my simple log, got an answer from AI that now has plexamp on the default output using my 5.1 to 4.0 downmix, so I can feed a 4.0 amp in a car with my Pi.
Now I just need to figure out how to get a power line through a firewall of a Ford Taurus X, which is unfortunately built like fort knox.
Details will be posted to the linked thread that is specifically for this 4.0 output issue.
Spoke too soon - my rears come through, but my center is being dropped. But - still, thank you thank you thank you, you’ve helped push this past the standstill I was stuck at and helped me get rears working, now I need to figure out why my center works in the OS test, but gets dropped from the plexamp output.
Also, I"m having buffering issues, and shouldn’t - can you offer insight there? It stops periodically with the play button giving a rotating animation.
Earlier when I was having this problem, AI had me run some networking tests that suggest it isn’t network related. Not that that’s conclusive. Also, for the high bitrate files that run into this problem, it works great for an amount of time, a minute-ish?, which suggests it’s capable of doing this, but then it buffers like crazy. Not sure where the bottleneck is. What specifically does the play/pause button doing a rotating animation, or blinking like crazy, mean? On some tests it was giving periodic long pauses, on others it gets jittery and blinks like crazy, like frequent stop/start.
I do have some 5.1 192kHz 24bit files in my library, off the Rhino Quadio Bluray reissue program. So this is a good stress test - if we can get these playing back, we can get anything in theory.
I cleared all logs, and restarted plexamp. Played back 1 test file.
It played cleanly for about 5 seconds, then buffered like crazy until about 45 seconds into the song. I paused for a while, then resumed playback. It played cleanly to around the 1 minute mark from that point, so about 15 seconds of clean playback, then resumed buffering like crazy.
Any insight you can offer would be greatly appreciated, thank you so much for taking the time you have to help with these matters.
Ok - taking a break from my broken 5.1 center output that AI is stubbornly stuck on making worse instead of better, I’ve shifted focus here and found the network and cache settings, and with a little tweaking have things playing back great on my wifi. Thanks for poitning me in the right direction here, you da man.
I previously adjusted some settings based on your guidance, and at first, I thought the issue was resolved. However, I’m still experiencing frequent and severe buffering.
Since you developed this, I know you have a deeper understanding of how it operates—far beyond what I do. If this app is meant to be user-friendly, there needs to be a clear troubleshooting process to identify and address bottlenecks. Right now, only someone with a deep technical understanding of its inner workings can provide that.
I’d really appreciate your help in pinpointing the issue. Thank you in advance for your support.
As I said before, this is about your environment, not the app at this point. I gave you the two main causes (slow disk writes or slow network), it’s not something more I can support you on as it’s not something which requires “a deep technical understanding of its inner workings”.
A while ago I reported that the play button in plexamp isn’t identified as play in a text sense - that is, if I use voice command to “tap play button” when it’s on the screen in the android app, voice command doesn’t recognize any object as play. For me this is a minor inconvenience, as it means it limits my handsfree capabilities when driving - but I think the bigger issue here is that this renders the app not very blind friendly. Is this on your radar to fix?
I am going out of my mind with these buffering issues.
I can test for long periods of time at the high rates, and they work fine. And then out of nowhere I get massive buffering issues, but I’ve changed nothing.
If I can’t get help for this, then this project is useless!
Please provide the support I require to use this product.
I assure you I am trying to investigate everything on my system and setup in good faith. Here is a summary of what troubleshooting has provided so far:
Things That Are NOT the Problem
CPU Bottleneck
Your Raspberry Pi is running at ~10% CPU during buffering, meaning it’s not struggling to decode FLAC files.
Network Bandwidth
The iperf3 test showed a stable 150Mbps connection with zero retransmissions, confirming that your Wi-Fi is fast enough for high-resolution FLAC streaming.
Insufficient RAM
Your system has plenty of free RAM (~5.5GB available), and swap isn’t being used, meaning there’s no memory pressure affecting playback.
SD Card Performance Issues
Your SanDisk Extreme microSDXC has a high-speed 190MB/s read rate, far exceeding the ~21MB/s write spikes, so raw storage speed isn’t the limiting factor.
Cache Size Adjustments
We’ve tested both reducing and increasing Plexamp’s cache size (512MB, 2GB), but buffering persisted, indicating that cache size alone isn’t the issue.
Disk Writes to SD Card
We temporarily moved the cache to RAM (tmpfs), yet buffering still occurred, proving that SD card write speed wasn’t the root cause.
What’s Left to Investigate?
Plexamp’s Internal Buffering Strategy
Higher-resolution FLAC files may require larger internal buffers, and Plexamp may not be handling them efficiently.
We need to check buffer settings within Plexamp—do any allow increased playback buffer size or caching behavior tweaks?
Disk I/O Patterns & Access Behavior
The playback log shows sudden write spikes (~21MB/s) and high iowait (8.86%), meaning Plexamp struggles with large buffer dumps for high-resolution tracks.
If Plexamp writes large chunks inefficiently, playback might stall while waiting for I/O completion.
Network Jitter for Large Streams
iperf3 showed stable speeds, but FLAC streaming might involve bursty traffic patterns that aren’t buffered efficiently, causing pauses.
The rationale: When you begin a playback queue in Plexamp, it uses the caching settings to determine how many tracks to cache and how quickly to do it. So if, for example, you configure it to cache forty tracks and set its network speed to unlimited, it will attempt to fill its cache as quickly as possible, up to a maximum of the configured cache size.
This can lead to potentially long periods of sustained network traffic along with the requisite disk I/O (I know you tested tmpfs; leave that aside for now) to store the data. This leads to a situation where there is not only a good deal network utilization but corresponding long periods of disk (SD card) writes while simultaneously reading.
So, depending on your specific settings, this can be challenging for a Pi using SD card storage. The settings above will mitigate the bursty network traffic (and consequently, the bursty disk I/O) and spread it over time (5 Mb/s = 0.625 MB/s, 10 Mb/s = 1.25 MB/s).
You can try bumping that network speed up in increments to see how it affects things. The biggest thing you may notice with lower values is it may take a few seconds for the track to begin playing. Increase the network speed incrementally until you find the sweet spot between initial buffering and playback stutters.
On the subject of SD card read speeds, you may not be getting their advertised transfer speeds, particularly in a Pi. You can test to see what you’re actually achieving for sequential reads (or something close to it) using the hdparm utility. So, something like: sudo hdparm -t --direct /dev/mmcblk2 sudo hdparm -T --direct /dev/mmcblk2
Replace mmcblk2 with the actual device name of your SD card (you can find it using the lsblk utility). The -t variant is without prior caching; the -T variant shows reading from the Linux buffer cache.
Given what @armyofquad1 is trying to do, it’s possible that an SD card just isn’t going to cut it and he needs to go with an nvme ssd hat (that particular piece of advice from a Plexamp tester with a lot of experience).
