Why does my Pi streamer cap the sample rate when running Android?

Yeah, Android does exactly this. Its audio mixer runs at whatever sample rate the output was configured for, usually 48k, and everthing gets resampled to match before it reaches the DAC. There's no system-wide setting to change it, it's just how the audio stack works. Some apps can grab the DAC directly and skip the mixer entirely, but only if the app supports it. Worth checking your streaming app's settings for an exclusive or direct output mode before you assume you're stuck, becasue a few of them have it buried in there. If your app doesn't, then yes, a different OS is the clean fix. The good news is you don't have to start over. The Pi, the hat, the screen, the knob, all of that carries over. You're only rebuilding the software side. I did the same move on mine a while back, went from Android to Raspberry Pi OS with a music player daemon doing the output and my own little interface on the display. I gave up the streaming app I'd been using, but there are other routes to get those services running, and now the DAC locks to whatever rate the file acutally is. The knob is the easiest part to migrate. If it goes through GPIO you just remap it, and if it's USB it's even simpler. The screen is the bigger job since whatever interface you built is tied to the OS you were on. I kept mine fairly dumb in the end, album art and transport controls, and do the deeper stuff from my phone. Wife approval survived the transition intact. Easy way to confirm you're fixed afterward: play a test file at a known high rate and check what the DAC reports. Lots of hats have a rate LED, or you can query it from the command line and see it switch up instead of sitting at the same number all day.

New here so hope this fits the thread, but I've got a similar box built around a Pi with a USB DAC instead of a hat, and I only found out about the resampling thing because a test tone I played sounded duller than it should. Never would have noticed otherwise, which makes me wonder how long mine has been doing it. One thing I'd add, the LED on my DAC only shows the rate after a track starts, so don't panic if it looks stuck at boot. Also does the switch to a music player daemon mess with gapless playback at all? That's the one thing I use constantly and I'd hate to lose it.

Before you commit to any rebuild, one thing I'd check is wether the resampling is actually happening where you think it is. I chased this on my own box for weeks, blaming the OS, when the culprit turned out to be an old config file left over from the first setup that was forcing everything down to a fixed rate no matter what played. I only found it because I hooked the DAC up to a laptop and watched the rate change live while it refused to budge on the Pi. Same file, same hardware, two different behaviors, which narrowed it down fast. So do the laptop test first, then start rebuilding if it still misbehaves.

Did the same move on mine last year and the one thing that made it painless was a tiny script that polls the DAC and prints the live sample rate in the corner of my little display. Before that I was playing test files and squinting at LEDs, after that I coud just watch it jump up when a hi-res track came on and settle back down after. Made the whole rebuild feel worth it the first time I saw it happen. One tip for the migration, write down how your volume knob behaves before you wipe anything. Mine was doing volume in the old OS, and on the new setup I had to pick between the player or the hardware handling it. Took a couple tries to get the feel right.

Update: sorted, and it was embarrassing. Took the advice about checking where the resampling was actually happening, and found an old config file from my first setup pinning the output down. Deleted it and the DAC now shows the proper rate for each track. Also added that little script that prints the live rate on the display, so I can see it change without guessing. No rebuild needed after all.