[Pm-utils] code available to solve sound-after-suspend problems

[Mark Stosberg]

Stefan Seyfried wrote:
> On Sat, Feb 24, 2007 at 11:27:05PM -0500, Mark Stosberg wrote:
>> Since some sound modules can't survive suspend, it's necessary to unload
>> them and reload them. However, some of them won't "let go" as long as
>> something is talking to the sound card.
>>
>> For this case, Mandriva has had a solution for the last few years that
>> has worked reasonable well: They kill all the programs that are talking
>> to the sound card and restart them. (It's an option, not the default
>> behavior!).
>>
>> It makes sense to me to offer to the same option through pm-utils, for
>> people would like to make this trade-off. (Personally, it has worked
>> well for me).
>>
>> Mandriva' GPL code for this available here, and it should be trivial to
>> port to pm-utils, it seems:
>>
>> http://cvs.mandriva.com/cgi-bin/viewvc.cgi/soft/suspend-scripts/suspend.d/sound?revision=1.5&view=markup
> 
> Yes, it is trivial. I also had requests to do something similar in suse
> (basically "service alsasound restart" does all this for me, since it
> kills the applications and reloads the drivers).

Interesting. On Ubuntu, the equivalent script doesn't kill the
applications. Anyway, the proposed solution doesn't just kill
applications, it restarts them all, too.

Suse apparently has users who would benefit from this solution as well.
Here are some SUSE users who have broken sound-after-suspend:

http://www.suseforums.net/lofiversion/index.php/t25585.html

One user there has a ThinkPad T21, so it likely the same sound card I have.

Ubuntu users have been in the same boat as well:
https://launchpad.net/ubuntu/+source/linux-source-2.6.15/+bug/11149

No one from either the Ubuntu thread or the Suse thread figured out the
solution I"m proposing, so I assume a number of them are just stuck,
because the proper kernel module fix isn't available e ither.

I'm only aware that Mandriva provided the easy "RESTORE_SOUND" option to
handle this.

> We should not ship such workarounds in pm-utils upstream (and normally no
> distro should do this in their default configuration). Just report the
> problems with your sound drivers to the kernel developers and have them fix
> the drivers.

My soundcard and laptop, the ThinkPad T20, works very well, but is 7
years old, I think. The sound card is no longer made. I'm not sure any
developers for the sound module have this hardware to test with anymore,
and as time passes, it will be less likely. It hasn't worked for the
past seven years. Why would developer who knew how to fix this /not/
have fixed it yet? How long would you suggest users wait, rebooting
their computers to get sound to work after they suspend? Two or three
more years?

> Until this happens, adding a custom hook to /etc/pm/hooks is trivial.

Trivial for who? Trival for my retired father who runs Linux on a T21
and is already skeptical about Linux? Frankly, you have to be fairly
savvy just to understand what needs to be done.

Or trivial for distributions, so they can all continue to duplicate
efforts for code to handle suspends?

> Papering over the driver issues in userspace is not a sustainable strategy.

The solution has worked reliably for me for the last couple years and
would help a number of people on number of distributions with a number
of sound cards *right now*.  Sure, the solution isn't as ideal as a
sound driver fix, but it is not a solution that is specific to any
particular sound driver, and I hardly find it to be "paper".

I humbly ask you to reconsider.

    Mark