I took a look and that's pretty slick. So it fits underneath and eliminates any hat conflict?Or use one of the many third party M.2 NVMe boards that don't connect to the GPIO header. I'm using this one: https://shop.pimoroni.com/products/nvme ... 9587178579
Yep.
This comment is a little beyond me, so something to research. I do fiddle with tech some, do it for a living, but this sort of thing is not in my area of expertise. I suspect that if I use a USB port to connect the SSD, none of that will matter. That being said, would the USB be the better solution or would the base you suggested above work better? I'm not stuck on using the M2 SSD hat, it was just listed as a requirement to use the SSD. I certainly don't mind ditching it for some other solution.Your chosen DAC doesn't appear to use the PCIe connector so no conflict there. The only likely conflict between the official M.2 HAT and the DAC (aside from power and ground which can be shared) are the ID EEPROM pins and that's because both HATs will probably have the same I2C address. But find and check the pin outs and addresses as I don't have them. Or either of those baords. And if one board is an old school HAT and the other is a HAT+ there shouldn't be a conflict as HAT+ use a different address.This is an in-vehicle sound system, so I wouldn't have any real need for saving data, but I would want the system to pick up where it left off on the song rotation rather than restarting from the beginning every time. Is this going to be an issue?As for getting a clean shutdown, you can do without that if you use the read only root filesystem overlay but you won't be able to save any changes across reboots.
That means you need some writable storage.
Really I could just use a regular head unit and load music off USB cards like I've done the last few years but having to swap music periodically is getting old.
So put the SSD into a USB enclosure and format it to something the head unit understands. Problem solved and a lot less work and expense.
FAT32 is as close to universal as it gets and can support partitions up to 2TB in size though I think the Windows GUI formatter still limits you to 32GB.
It came up during research as a possible solution allowing the use of multiple hats, but not one I want to use.I'm not at all sure why you think you'd need a "wireless mux". What are you expecting to mux with it?
Really? I don't see what wireless has to do with it. Nor do I see how it would help.
I like overkill. If there was an option for 512GB of RAM I'd use it. More RAM means faster boot times and better program responseLastly, 16GB RAM is likely overkill. I ran headless MPD on shuffle in my car for several years on an A+ with UBS2 external storage and a Pimorni pHatDAC (now discontinued).
It sounds like I would want to use the microSD for the OS and the SSD for the music then. Will that affect boot speed or picking up the music where it left off? It also looks like that base you recommended comes with a two SSD option, I suppose I could use that, put the music on one SSD and use a much smaller SSD for the OS. How well would that work for this?Oh, and whatever you decide keep, the OS and media files on separate physical devices. A car is a hostile environment (12v isn't, 12v is noisy, etc) so when the OS gets corrupted it'll be much easier to deal with if you don't have to first back up 1TB of media files.
Both are options. Booting from SD card would be slower than from SSD. That dual board uses a PCIe switch which means splitting bandwidth between both drives if both are active at the same time. As I don't have one, I'm also unsure if the Pi5 can boot solely from a drive behind the switch.
Statistics: Posted by thagrol — Mon Oct 27, 2025 9:06 pm