On 11/19/2015 04:17 PM, James Harkins wrote:
Thanks, David, for the reply. My normal practice for suspending the session is to stop the Jack server first. I've also configured PulseAudio *not* to start itself, so at the time I suspend the session, there is no process actively using the audio hardware. After resuming the session, that's when I restart the Jack server and this fires up the ALSA driver.
Hmm, I thought ALSA drivers loaded during boot, not when JACKD tries to start? I only use JACK when I'm making music - but can still play audio from programs that don't use JACK, without starting JACK. (I have no trace of PulseAudio on my system).
Don't know for certain about audio hardware, but was quite familiar with network hardware (usually wireless) for which system drivers set the device state at load and/or when a connection was established. When the system was suspended, everything went to sleep/hibernated/whatever - except the hardware.
The state of the hardware could change when the system was suspended. (Or in the case of network hardware, the state of the network would change.) In fact, if it was "hibernate to disk, then shut off", guaranteed the state of the hardware changed. When a system comes up from a cold state like that and loads a hibernation image, does the hibernated system reload any required firmware, for instance?
When the system resumed from suspension, the drivers just assumed that "their" device was in the same state as before ... leading to failure.
That was a good while ago, don't know if it's still an issue. Just an idea.
Weird. hjh
Yah. -- David W. Jones gnome@xxxxxxxxxxxxx authenticity, honesty, community http://dancingtreefrog.com _______________________________________________ Linux-audio-user mailing list Linux-audio-user@xxxxxxxxxxxxxxxxxxxx http://lists.linuxaudio.org/listinfo/linux-audio-user
