A side-issue: only after watching the pndevmapperd output I have noticed this message:
/usr/pandora/scripts/op_power.sh: line 247: echo: write error: operation not permitted
Line 247 in my op_power script reads "echo mem > /sys/power/state"
I think it's the line that makes the Pandora enter the suspend state. The error appear safter waking up from suspend, but only if I have a program (pnd) running, that keeps an opened file (like music/video player). I have noticed that with DeaDBeeF and SMPlayer2 when they have a media file opened (paused).
Suspend seems to be working fine despite the message. Do I have to worry? Or is that a bug in op_power?
Yes if you look at dmesg, you'll see that some powerdomains (parts of the chip basically) failed to enter low power state, which happens when there is playing audio during suspend. Those players are probably streaming silence while paused. Ideally the driver would be able to handle it, but that doesn't work in 3.2 and is not easy to fix.
Yes, if deadbeef is paused, I have to detach it from ALSA (go into the config and select null output plugin rather then alsa) before a lot of (especially newer) software will play audio, or in at least one case, even start at all. Not sure how that affects my battery runtime, or 5V power rail (the light on my USB network nub is sometimes on despite my having turned off USB host and TV out). That needs a little more exploration still.
Yes, if deadbeef is paused, I have to detach it from ALSA (go into the config and select null output plugin rather then alsa) before a lot of (especially newer) software will play audio, or in at least one case, even start at all.
I use a simpler solution: I close deadbeef before starting anything requiring audio. Deadbeef remembers its playlist and playing position between runs (I'm not sure if that doesn't need to be enabled in settings).
Yeah, I listen to a three hour podcast and a two hour podcast each week, so I can't afford to close deadbeef really. Admittedly, it does lose your place in the file when you restart it after reconnecting alsa(*), but you only have to remember the time for a moment in that case, so you don't need to memorise anything, just notice the time and it'll be there in your short term memory when you reset the slider to the right point.
(*) Which makes me suspect it's actually playing nothing or in some special paused mode, as it seems to need a persistent connection to remember its paused location.
I listen to about five 1,5~3-hour podcasts per week, and I had the same problem until I discovered this option in deadbeef: Preferences -> Playback tab -> Resume previous session on startup. It works every time.
Only two times in half of a year I had situation that deadbeef lost all of its settings, but it was always after I have taken out the SD card (deadbeef was not running, I suspect some pnd closing or filesystem syncing problem, as it happened with other apps too).