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

[Stefan Seyfried]

On Mon, Feb 26, 2007 at 07:43:21PM -0500, Mark Stosberg wrote:
> Stefan Seyfried wrote:
> > 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.

And if all the time that was put into creating these elaborate workarounds
was spent fixing the real bug, then we'd all not have to write mails about
that problem. So go ahead and file a bug for the kernel.
 
> 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

Of course. Since this is a kernel problem, it is very likely that most
distributions will see it.
 
> 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.

But maybe just because nobody even bothered to file a bug against the kernel.
It might also very well be that it is just not documented well enough. I
figure that you would not google for "pm-utils custom hook" if you had a
problem with sound after suspend. I will try to get this better documented
(and google-indexed :-), but this is where you can also help.

> 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,

There are lots of T2[013] still around.

> 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?

I'll accept this argument once you can show me for example Takashi Iwai
telling you "i won't fix this, because your hardware is too old".
He never said this to me.

I am willing to include workarounds for drivers that can not be fixed. There
are some of those (a PCMCIA ISDN card for example, whose driver are derived
from reverse-engineered ISA-ISDN card code. Nobody really will touch such a
driver if it is not absolutely unavoidable). However, you need to convince me
that the driver cannot be fixed.

I was adding workarounds in the powersave code, three or four years ago. Back
then, it was the only way of getting suspend to work at all. Today we are on
a different stage of development and general consensus is that adding these
workarounds does slow down development.

> > 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.

Then go ahead and document it in a prominent place so that people googling
for help will find it. I tried to document the pm-utils hooks for my users
in http://en.opensuse.org/Pm-utils, but maybe i failed.

-- 
Stefan Seyfried

"Any ideas, John?"
"Well, surrounding them's out."