First off, I tinkered with this nonsense and got a solution which includes proper volume control. It also includes crashes when fast-forwarding, stopping or exiting. Yay.
http://boards.openpandora.org/topic/15193-bluetooth-headsets-a-partly-working-solution//URL]
If any of you are interested in an actual permanent perfect solution, I believe that updating alsa is the magic we're looking for. Make some noise.
http://boards.openpandora.org/topic/15192-update-alsa-or-the-kitten-gets-it//URL]
--
Could someone hack 2 simple shell scripts? (I am not that experienced with those)
Maybe.
My answers will have technical crap in them, meant for others interested in such a project.
First script: A daemon that uses mplayer to play songs from a queue-file, kills mplayer automatically when freezed (watchdog-mechanic) and plays the next song from that list.
- mplayer may not support the concept of playing from a queue file, I don't know. I've used console software (like cplay) which handle such things, but I don't know how they do it. This may not be easy.
- I don't know if there is an easy way to tell when a process is frozen. If an existing mplayer process can be interacted with (e.g. through some sort of pipe mechanism?) then it feels like it would be easy. If not, then some other piece of software would have to be used -- or probably compiled for the pandora.
[edit] Oh, I wonder if sending a sig USR1 or some such would give a little feedback.
Second script: Is called from the file browser when clicking on music files (doesn't get easier). Then just adds that file to the queue-file and pops up one of those notifications on the lower right screen corner.
- Running a script when clicking on music files should be as simple as mucking about with the mime type association from whatever it is to a script. I think I've done this before, but I can't remember anything about it. This is probably doable.
- A pop up notification at the lower-right should be simple. Lots of existing scripts already do this sort of thing, so I'd bet that the os already has something cooked-in.
--
I would go further than all of this, and have any startup script overwrite the .asoundrc with a bluetooth-default one. Then on exit, return it to its earlier not-bluetooth state.
I'm also mildly interested in having some sort of alternate device, alternate mixer or whatever alsa does. Maybe it's possible to have a more complex .asoundrc, and then just have specific applications already set to use the bluetooth device. Then double-clicking a music file pops up your favourite media player, which is already configured to use bluetooth by default, but its preferences can be trivially changed to go back to regular alsa. Right now, I have alsa default to bluetooth, but I can adjust players to go back to using oss if I want playback on the pandora's speakers.