With monster commutes by car on track to resume for the 1st time in 10 years, the need has returned for a decent mp3 player.  Obviously, it would run on a phone, to have common code with the mp3 player used for running.  In a sign of regression, dedicated mp3 players are either no longer made or ridiculously expensive.  Phone apps no longer do nearly as much as what Rockbox or a high end player from 15 years ago did.  A high end player made out of an STM32 discovery board would not be useful for running.

The mane requirements:

Uses the directory structure as the playlists.

Automatically resume playing with engine ignition.

Recursively advance playlists.

Easy deletion of songs.

User interface for navigating songs.

No dropouts.

Retain playback position when quit.

2 playback positions have to be stored: 1 for running & 1 for driving

Manual playback from the running position or automatic playback from the driving position, depending on detection of the car speaker & whether it was playing when the engine was stopped.

There were several competing ideas: a cheap, dedicated phone that stayed in the car, a reuse of the same phone for daily use, & a ground up hardware solution on an STM32 discovery board.  

Bluetooth speakers are virtually free, nowadays, so scratch built hardware is pointless.  The speaker hardware just has to be modified to begin advertising with engine ignition & output line levels for the car radio.  To automatically start playing, the phone can rely on detection of the speaker or some alternate way of detecting the car's state.  In another sign of corporate dysfunction, Android automatically resumes playback & resets the volume when a TRS connector is plugged in, but doesn't resume playback or reset the volume when a bluetooth speaker is detected.

Automatic detection of bluetooth speakers has been extremely unreliable, so it may require low energy or a wifi access point in the car.  The reliability of a bluetooth system has to be determined before going to a custom solution.  Requiring a TRS connector to be plugged in would be very painful.  

The program would be some kind of service that always waited for the bluetooth speaker to become present.  The mane problem is the phone has to be plugged in to have enough power for such a long drive.  For rare, shorter drives, the phone could still be ignored.

The STM32 solution tends to shine when it comes to automating the process.  It would store all the songs on its own storage, never have to be touched, & the complexity of detecting the speaker would go away.  It would expose a user interface over BLE which would be accessed by the daily phone.  It's a lot of redundant code, but so is the dual playhead idea.  There's also modifying playlists.  The lion kingdom went many years just moving an SD card between the car & the computer, but the future is web based file management.

The user interface still requires firing up the phone, but the user interface was extremely rarely used, 10 years ago.

Dropouts are a real problem for Android, since the spec requires it to stop music playback whenever in the presence of another phone.  Lions can bypass the spec by using their own software decoder, but it uses more power.