root@mythLR:~ # alsactl restore 0 -f card0.before
alsactl: set_control:1464: Cannot write control '2:0:0:IEC958 Playback Default:0' : Operation not permitted error
Alsa Differences: (Left is after working, Right is after resume)
diff card0.before card0.after -y --suppress-common-lines
value.0 31 | value.0 16
value.1 31 | value.1 16
dbvalue.0 0 | dbvalue.0 -2250
dbvalue.1 0 | dbvalue.1 -2250
value '04000000000000000000000000000000000000 | value '04820002000000000000000000000000000000
access 'read write' | access 'read write locked'
Any ideas where else to look or how to restore the pre-hibernation configuration? If I power cycle/reboot audio works great every time
I added a reboot at the bottom of my suspend script because I got tired of getting up to fix the issue.
I had reported it in the list quite a while ago and it was one of the open issues when development came to a hlt.
I have always believed it was related to the NVidia driver update, but I am not positive. I was hoping the next update would fix it, but it never came
I guess I will have to find some time to did into this a little deeper.
After first resume when the audio doesn't work
root@mythLR:/usr/bin # cat /dev/urandom | aplay
aplay: main:696: audio open error: Device or resource busy
After second resume and audio does work
root@mythLR:/usr/bin # cat /dev/urandom | aplay -D hw:0,3
Playing raw data 'stdin' : Unsigned 8 bit, Rate 8000 Hz, Mono
aplay: set_params:1102: Sample format non available
So I agree is appears to be driver related and likely a timing or initialization issue, possibly due to going though an audio receiver as my second box doesn't appear to have this issue that does directly to tv.
If my TV and receiver are on first for many seconds and then I awake minimyth, then audio will work. however, if minimyth comes on earlier, then I will get no audio. Unfortunately, with my current remote, I have not had good luck getting it to always start in the expected order.