Re: [alsa-devel] Headphone output doesn't work with 3.0.0-rc* anymore
At Thu, 9 Jun 2011 13:14:01 +0200, Michal Hocko wrote:
On Thu 09-06-11 11:44:41, Takashi Iwai wrote:
At Thu, 9 Jun 2011 11:28:26 +0200, Michal Hocko wrote:
[1 <text/plain; us-ascii (7bit)>] On Thu 09-06-11 11:20:04, Takashi Iwai wrote:
At Thu, 9 Jun 2011 11:06:07 +0200, Michal Hocko wrote:
On Thu 09-06-11 10:56:16, Michal Hocko wrote:
On Thu 09-06-11 08:09:18, Takashi Iwai wrote: > At Wed, 8 Jun 2011 19:48:55 +0200,
[...]
> Thanks, that's helpful. > As a quirk solution, could you try to pass model=auto option to > snd-hda-intel module?
Headphones work now but speakers are quite... I have tried to play with Headphone and Speaker controls in alsamixer but no changes.
Here is what I get in logs when the module is loaded: [ 5320.360277] HDA Intel 0000:00:1b.0: PCI INT A disabled [ 5326.920247] HDA Intel 0000:00:1b.0: power state changed by ACPI to D0 [ 5326.920262] HDA Intel 0000:00:1b.0: power state changed by ACPI to D0 [ 5326.920279] HDA Intel 0000:00:1b.0: PCI INT A -> GSI 17 (level, low) -> IRQ 17 [ 5326.920375] HDA Intel 0000:00:1b.0: irq 42 for MSI/MSI-X [ 5326.920405] HDA Intel 0000:00:1b.0: setting latency timer to 64 [ 5326.981085] input: HDA Intel Mic as /devices/pci0000:00/0000:00:1b.0/sound/card0/input18 [ 5326.981262] input: HDA Intel Mic as /devices/pci0000:00/0000:00:1b.0/sound/card0/input19 [ 5326.987934] input: HDA Intel Headphone as /devices/pci0000:00/0000:00:1b.0/sound/card0/input20
[maybe not important but input numbers are increasing for every new load]
There is another strange thing. After I stop mplayer and wait for some time (~1min) I can hear a "click" sound and then there is no sound at all... If I start mplayer in the meantime it just works... If I try to remove the module and load it again then things work and stop working after first playback again.
And I have just found out that I do not have to start any playback to see this. It is sufficient to load the module and wait a minute and there is no sound at all (both from speakers or headphones).
OK, could you give alsa-info.sh outputs at both working and non-working states?
Sure. Attached. The only change seems to be: Node 0x02 [Audio Output] wcaps 0x11: Stereo Device: name="ALC262 Analog", type="Audio", device=0
- Converter: stream=5, channel=0
- Converter: stream=0, channel=0
This is OK. It shows that the converter was assigned once to this stream when you played back a sound before power-save.
As long as the codec registers show the same value, it's not obviously what went wrong. The symptom sounds like a resume issue. If so, S3/S4 might show the same problem.
BTW, does my patch fix the problem when you load without model=auto?
I have just booted to the rc2 with the patch (https://lkml.org/lkml/2011/6/9/25) and it looks it didn't solve the problem. Playback works only from speakers when headphones are not plugged in - no sound if plugged in.
So, the auto-mute now works but now the headphone doesn't work. Weird... Maybe the same reason the speaker doesn't work with auto-mode. I saw that the only one converter keeps the stream in your alsa-info.sh output although multiple converters (0x02, 0x03, 0x06) should be used simultaneously.
See alsa-info.txt-fresh-boot. Same thing happens if I modprobe -r snd-hda-intel and then load it again (without any parameters).
If yes, does the problem appear with it? I.e. is the silence problem specific to model=auto or not?
If I try to modproble with model=auto I get headphones working but not output from speakers. Have a look at alsa-info.txt-modprobe_auto.
For testing, just copy 2.6.39/sound/pci/*.[ch] into 3.0 tree and rebuild. Does it work as expected? If you have a good-working reference, please take alsa-info.sh output while playing back a stream.
Note that the one-minute thing happens only when you unplug AC cable, supposedly. Or, simply write some value (in seconds) to /sys/modules/snd_hda_intel/parameters/powersave and access the device once (either mixer or PCM) to activate the power-saving mode.
thanks,
Takashi
On Fri 10-06-11 08:53:01, Takashi Iwai wrote:
At Thu, 9 Jun 2011 13:14:01 +0200, Michal Hocko wrote:
On Thu 09-06-11 11:44:41, Takashi Iwai wrote:
At Thu, 9 Jun 2011 11:28:26 +0200,
[...]
BTW, does my patch fix the problem when you load without model=auto?
I have just booted to the rc2 with the patch (https://lkml.org/lkml/2011/6/9/25) and it looks it didn't solve the problem. Playback works only from speakers when headphones are not plugged in - no sound if plugged in.
So, the auto-mute now works but now the headphone doesn't work. Weird... Maybe the same reason the speaker doesn't work with auto-mode. I saw that the only one converter keeps the stream in your alsa-info.sh output although multiple converters (0x02, 0x03, 0x06) should be used simultaneously.
See alsa-info.txt-fresh-boot. Same thing happens if I modprobe -r snd-hda-intel and then load it again (without any parameters).
If yes, does the problem appear with it? I.e. is the silence problem specific to model=auto or not?
If I try to modproble with model=auto I get headphones working but not output from speakers. Have a look at alsa-info.txt-modprobe_auto.
For testing, just copy 2.6.39/sound/pci/*.[ch] into 3.0 tree and rebuild.
OK, I git checkout v2.6.39 -- sound/pci/*.[ch] (see the patch bellow for reference). I have kept the earlier patch.
Does it work as expected?
No. There is no sound at all with or without headphones plugged in. See attached alsa-info output (alsa-info.txt-fresh_boot_*) while mplayer was running. After I unloaded the module and loaded it back with model=auto headphones started working while speakers are still silent as grave (see alsa-info.txt-modprobe_auto_* taken while playing music).
If you have a good-working reference, please take alsa-info.sh output while playing back a stream.
Note that the one-minute thing happens only when you unplug AC cable, supposedly.
Hmmm, I was plugged during testing all the time. OK, this looks like a separate issue. I will repost it as a separate thread once we are done with this. Any idea who to CC?
Or, simply write some value (in seconds) to /sys/modules/snd_hda_intel/parameters/powersave and access the device once (either mixer or PCM) to activate the power-saving mode.
---
I really need a "you forgot your attachment" reminder...
At Fri, 10 Jun 2011 09:56:40 +0200, Michal Hocko wrote:
On Fri 10-06-11 08:53:01, Takashi Iwai wrote:
At Thu, 9 Jun 2011 13:14:01 +0200, Michal Hocko wrote:
On Thu 09-06-11 11:44:41, Takashi Iwai wrote:
At Thu, 9 Jun 2011 11:28:26 +0200,
[...]
BTW, does my patch fix the problem when you load without model=auto?
I have just booted to the rc2 with the patch (https://lkml.org/lkml/2011/6/9/25) and it looks it didn't solve the problem. Playback works only from speakers when headphones are not plugged in - no sound if plugged in.
So, the auto-mute now works but now the headphone doesn't work. Weird... Maybe the same reason the speaker doesn't work with auto-mode. I saw that the only one converter keeps the stream in your alsa-info.sh output although multiple converters (0x02, 0x03, 0x06) should be used simultaneously.
See alsa-info.txt-fresh-boot. Same thing happens if I modprobe -r snd-hda-intel and then load it again (without any parameters).
If yes, does the problem appear with it? I.e. is the silence problem specific to model=auto or not?
If I try to modproble with model=auto I get headphones working but not output from speakers. Have a look at alsa-info.txt-modprobe_auto.
For testing, just copy 2.6.39/sound/pci/*.[ch] into 3.0 tree and rebuild.
OK, I git checkout v2.6.39 -- sound/pci/*.[ch] (see the patch bellow for reference). I have kept the earlier patch.
Gah, sorry, a wrong path. It must be sound/pci/hda/*.[ch]. Also, please remove my previous patch. It's irrelevant with 2.6.39 although it should be harmless.
Regarding the missing speaker-output on model=auto: I found the culprit. The current auto-parser for ALC262 doesn't probe the secondary DAC. So, it's a logical bug. I'm going to fix this for 3.1. From now on, let's keep tracking only the issue without model option.
thanks,
Takashi
On Fri 10-06-11 10:14:13, Takashi Iwai wrote:
At Fri, 10 Jun 2011 09:56:40 +0200, Michal Hocko wrote:
On Fri 10-06-11 08:53:01, Takashi Iwai wrote:
At Thu, 9 Jun 2011 13:14:01 +0200, Michal Hocko wrote:
On Thu 09-06-11 11:44:41, Takashi Iwai wrote:
At Thu, 9 Jun 2011 11:28:26 +0200,
[...]
BTW, does my patch fix the problem when you load without model=auto?
I have just booted to the rc2 with the patch (https://lkml.org/lkml/2011/6/9/25) and it looks it didn't solve the problem. Playback works only from speakers when headphones are not plugged in - no sound if plugged in.
So, the auto-mute now works but now the headphone doesn't work. Weird... Maybe the same reason the speaker doesn't work with auto-mode. I saw that the only one converter keeps the stream in your alsa-info.sh output although multiple converters (0x02, 0x03, 0x06) should be used simultaneously.
See alsa-info.txt-fresh-boot. Same thing happens if I modprobe -r snd-hda-intel and then load it again (without any parameters).
If yes, does the problem appear with it? I.e. is the silence problem specific to model=auto or not?
If I try to modproble with model=auto I get headphones working but not output from speakers. Have a look at alsa-info.txt-modprobe_auto.
For testing, just copy 2.6.39/sound/pci/*.[ch] into 3.0 tree and rebuild.
OK, I git checkout v2.6.39 -- sound/pci/*.[ch] (see the patch bellow for reference). I have kept the earlier patch.
Gah, sorry, a wrong path. It must be sound/pci/hda/*.[ch]. Also, please remove my previous patch. It's irrelevant with 2.6.39 although it should be harmless.
OK, I have reverted the whole hda directory to 2.6.39 which means AFAIU that the driver is at the same state as it was in that kernel. And the sound really works. Both outputs are active whem they should be.
I have attached alsa-info output while mplayer is running.
Regarding the missing speaker-output on model=auto: I found the culprit. The current auto-parser for ALC262 doesn't probe the secondary DAC. So, it's a logical bug. I'm going to fix this for 3.1. From now on, let's keep tracking only the issue without model option.
OK
At Fri, 10 Jun 2011 10:51:17 +0200, Michal Hocko wrote:
On Fri 10-06-11 10:14:13, Takashi Iwai wrote:
At Fri, 10 Jun 2011 09:56:40 +0200, Michal Hocko wrote:
On Fri 10-06-11 08:53:01, Takashi Iwai wrote:
At Thu, 9 Jun 2011 13:14:01 +0200, Michal Hocko wrote:
On Thu 09-06-11 11:44:41, Takashi Iwai wrote:
At Thu, 9 Jun 2011 11:28:26 +0200,
[...]
BTW, does my patch fix the problem when you load without model=auto?
I have just booted to the rc2 with the patch (https://lkml.org/lkml/2011/6/9/25) and it looks it didn't solve the problem. Playback works only from speakers when headphones are not plugged in - no sound if plugged in.
So, the auto-mute now works but now the headphone doesn't work. Weird... Maybe the same reason the speaker doesn't work with auto-mode. I saw that the only one converter keeps the stream in your alsa-info.sh output although multiple converters (0x02, 0x03, 0x06) should be used simultaneously.
See alsa-info.txt-fresh-boot. Same thing happens if I modprobe -r snd-hda-intel and then load it again (without any parameters).
If yes, does the problem appear with it? I.e. is the silence problem specific to model=auto or not?
If I try to modproble with model=auto I get headphones working but not output from speakers. Have a look at alsa-info.txt-modprobe_auto.
For testing, just copy 2.6.39/sound/pci/*.[ch] into 3.0 tree and rebuild.
OK, I git checkout v2.6.39 -- sound/pci/*.[ch] (see the patch bellow for reference). I have kept the earlier patch.
Gah, sorry, a wrong path. It must be sound/pci/hda/*.[ch]. Also, please remove my previous patch. It's irrelevant with 2.6.39 although it should be harmless.
OK, I have reverted the whole hda directory to 2.6.39 which means AFAIU that the driver is at the same state as it was in that kernel. And the sound really works. Both outputs are active whem they should be.
Thanks, it's really good to know that we have a good working-base.
Now, can you switch back to 3.0rc2 with my fix patch and retest? Please get alsa-info.sh output at the same state, i.e. mplayer running, so that we can compare directly two states.
Takashi
On Fri 10-06-11 11:18:51, Takashi Iwai wrote:
At Fri, 10 Jun 2011 10:51:17 +0200, Michal Hocko wrote:
On Fri 10-06-11 10:14:13, Takashi Iwai wrote:
At Fri, 10 Jun 2011 09:56:40 +0200, Michal Hocko wrote:
On Fri 10-06-11 08:53:01, Takashi Iwai wrote:
At Thu, 9 Jun 2011 13:14:01 +0200,
[...]
OK, I git checkout v2.6.39 -- sound/pci/*.[ch] (see the patch bellow for reference). I have kept the earlier patch.
Gah, sorry, a wrong path. It must be sound/pci/hda/*.[ch]. Also, please remove my previous patch. It's irrelevant with 2.6.39 although it should be harmless.
OK, I have reverted the whole hda directory to 2.6.39 which means AFAIU that the driver is at the same state as it was in that kernel. And the sound really works. Both outputs are active whem they should be.
Thanks, it's really good to know that we have a good working-base.
Now, can you switch back to 3.0rc2 with my fix patch and retest?
Sorry, I am confused now. How this would be different from the previous testing where I had that patch applied on top of rc2?
At Fri, 10 Jun 2011 11:30:19 +0200, Michal Hocko wrote:
On Fri 10-06-11 11:18:51, Takashi Iwai wrote:
At Fri, 10 Jun 2011 10:51:17 +0200, Michal Hocko wrote:
On Fri 10-06-11 10:14:13, Takashi Iwai wrote:
At Fri, 10 Jun 2011 09:56:40 +0200, Michal Hocko wrote:
On Fri 10-06-11 08:53:01, Takashi Iwai wrote:
At Thu, 9 Jun 2011 13:14:01 +0200,
[...]
OK, I git checkout v2.6.39 -- sound/pci/*.[ch] (see the patch bellow for reference). I have kept the earlier patch.
Gah, sorry, a wrong path. It must be sound/pci/hda/*.[ch]. Also, please remove my previous patch. It's irrelevant with 2.6.39 although it should be harmless.
OK, I have reverted the whole hda directory to 2.6.39 which means AFAIU that the driver is at the same state as it was in that kernel. And the sound really works. Both outputs are active whem they should be.
Thanks, it's really good to know that we have a good working-base.
Now, can you switch back to 3.0rc2 with my fix patch and retest?
Sorry, I am confused now. How this would be different from the previous testing where I had that patch applied on top of rc2?
Never mind, I found the possible spot. Could you try the patch below in addition? There was one missing initialization in the transition.
The headphone would have been working when you mute/unmute "Master" volume once.
thanks,
Takashi
--- diff --git a/sound/pci/hda/patch_realtek.c b/sound/pci/hda/patch_realtek.c index bef7a77..20f01f8 100644 --- a/sound/pci/hda/patch_realtek.c +++ b/sound/pci/hda/patch_realtek.c @@ -1141,6 +1141,13 @@ static void update_speakers(struct hda_codec *codec) struct alc_spec *spec = codec->spec; int on;
+ /* Control HP pins/amps depending on master_mute state; + * in general, HP pins/amps control should be enabled in all cases, + * but currently set only for master_mute, just to be safe + */ + do_automute(codec, ARRAY_SIZE(spec->autocfg.hp_pins), + spec->autocfg.hp_pins, spec->master_mute, true); + if (!spec->automute) on = 0; else @@ -6202,11 +6209,6 @@ static const struct snd_kcontrol_new alc260_input_mixer[] = { /* update HP, line and mono out pins according to the master switch */ static void alc260_hp_master_update(struct hda_codec *codec) { - struct alc_spec *spec = codec->spec; - - /* change HP pins */ - do_automute(codec, ARRAY_SIZE(spec->autocfg.hp_pins), - spec->autocfg.hp_pins, spec->master_mute, true); update_speakers(codec); }
On Fri 10-06-11 12:08:03, Takashi Iwai wrote:
At Fri, 10 Jun 2011 11:30:19 +0200, Michal Hocko wrote:
On Fri 10-06-11 11:18:51, Takashi Iwai wrote:
At Fri, 10 Jun 2011 10:51:17 +0200, Michal Hocko wrote:
On Fri 10-06-11 10:14:13, Takashi Iwai wrote:
At Fri, 10 Jun 2011 09:56:40 +0200, Michal Hocko wrote:
On Fri 10-06-11 08:53:01, Takashi Iwai wrote: > At Thu, 9 Jun 2011 13:14:01 +0200,
[...]
OK, I git checkout v2.6.39 -- sound/pci/*.[ch] (see the patch bellow for reference). I have kept the earlier patch.
Gah, sorry, a wrong path. It must be sound/pci/hda/*.[ch]. Also, please remove my previous patch. It's irrelevant with 2.6.39 although it should be harmless.
OK, I have reverted the whole hda directory to 2.6.39 which means AFAIU that the driver is at the same state as it was in that kernel. And the sound really works. Both outputs are active whem they should be.
Thanks, it's really good to know that we have a good working-base.
Now, can you switch back to 3.0rc2 with my fix patch and retest?
Sorry, I am confused now. How this would be different from the previous testing where I had that patch applied on top of rc2?
Never mind, I found the possible spot. Could you try the patch below in addition? There was one missing initialization in the transition.
I have applied this patch on top of clean rc2. Unfortunately, the sound works only from headphones, now. See alsa-info attached. I have tried to get info also when headphones were unplugged but the content is very same (except for timestamp when the script ran).
At Fri, 10 Jun 2011 14:42:32 +0200, Michal Hocko wrote:
On Fri 10-06-11 12:08:03, Takashi Iwai wrote:
At Fri, 10 Jun 2011 11:30:19 +0200, Michal Hocko wrote:
On Fri 10-06-11 11:18:51, Takashi Iwai wrote:
At Fri, 10 Jun 2011 10:51:17 +0200, Michal Hocko wrote:
On Fri 10-06-11 10:14:13, Takashi Iwai wrote:
At Fri, 10 Jun 2011 09:56:40 +0200, Michal Hocko wrote: > > On Fri 10-06-11 08:53:01, Takashi Iwai wrote: > > At Thu, 9 Jun 2011 13:14:01 +0200,
[...]
> OK, I git checkout v2.6.39 -- sound/pci/*.[ch] (see the patch bellow for > reference). I have kept the earlier patch.
Gah, sorry, a wrong path. It must be sound/pci/hda/*.[ch]. Also, please remove my previous patch. It's irrelevant with 2.6.39 although it should be harmless.
OK, I have reverted the whole hda directory to 2.6.39 which means AFAIU that the driver is at the same state as it was in that kernel. And the sound really works. Both outputs are active whem they should be.
Thanks, it's really good to know that we have a good working-base.
Now, can you switch back to 3.0rc2 with my fix patch and retest?
Sorry, I am confused now. How this would be different from the previous testing where I had that patch applied on top of rc2?
Never mind, I found the possible spot. Could you try the patch below in addition? There was one missing initialization in the transition.
I have applied this patch on top of clean rc2.
And apply my previous patch, too. There are two fixes.
thanks,
Takashi
On Fri 10-06-11 14:43:43, Takashi Iwai wrote:
At Fri, 10 Jun 2011 14:42:32 +0200, Michal Hocko wrote:
On Fri 10-06-11 12:08:03, Takashi Iwai wrote:
At Fri, 10 Jun 2011 11:30:19 +0200, Michal Hocko wrote:
On Fri 10-06-11 11:18:51, Takashi Iwai wrote:
At Fri, 10 Jun 2011 10:51:17 +0200, Michal Hocko wrote:
On Fri 10-06-11 10:14:13, Takashi Iwai wrote: > At Fri, 10 Jun 2011 09:56:40 +0200, > Michal Hocko wrote: > > > > On Fri 10-06-11 08:53:01, Takashi Iwai wrote: > > > At Thu, 9 Jun 2011 13:14:01 +0200,
[...]
> > OK, I git checkout v2.6.39 -- sound/pci/*.[ch] (see the patch bellow for > > reference). I have kept the earlier patch. > > Gah, sorry, a wrong path. It must be sound/pci/hda/*.[ch]. > Also, please remove my previous patch. It's irrelevant with 2.6.39 > although it should be harmless.
OK, I have reverted the whole hda directory to 2.6.39 which means AFAIU that the driver is at the same state as it was in that kernel. And the sound really works. Both outputs are active whem they should be.
Thanks, it's really good to know that we have a good working-base.
Now, can you switch back to 3.0rc2 with my fix patch and retest?
Sorry, I am confused now. How this would be different from the previous testing where I had that patch applied on top of rc2?
Never mind, I found the possible spot. Could you try the patch below in addition? There was one missing initialization in the transition.
I have applied this patch on top of clean rc2.
And apply my previous patch, too. There are two fixes.
Sorry, I have missed that I should apply the previous one as well. Nevermind, I have good news. With both patches applied, sound works as expected.
Feel free to add my Tested-by.
Thanks a lot
At Fri, 10 Jun 2011 15:20:29 +0200, Michal Hocko wrote:
On Fri 10-06-11 14:43:43, Takashi Iwai wrote:
At Fri, 10 Jun 2011 14:42:32 +0200, Michal Hocko wrote:
On Fri 10-06-11 12:08:03, Takashi Iwai wrote:
At Fri, 10 Jun 2011 11:30:19 +0200, Michal Hocko wrote:
On Fri 10-06-11 11:18:51, Takashi Iwai wrote:
At Fri, 10 Jun 2011 10:51:17 +0200, Michal Hocko wrote: > > On Fri 10-06-11 10:14:13, Takashi Iwai wrote: > > At Fri, 10 Jun 2011 09:56:40 +0200, > > Michal Hocko wrote: > > > > > > On Fri 10-06-11 08:53:01, Takashi Iwai wrote: > > > > At Thu, 9 Jun 2011 13:14:01 +0200,
[...]
> > > OK, I git checkout v2.6.39 -- sound/pci/*.[ch] (see the patch bellow for > > > reference). I have kept the earlier patch. > > > > Gah, sorry, a wrong path. It must be sound/pci/hda/*.[ch]. > > Also, please remove my previous patch. It's irrelevant with 2.6.39 > > although it should be harmless. > > OK, I have reverted the whole hda directory to 2.6.39 which means AFAIU > that the driver is at the same state as it was in that kernel. And the > sound really works. Both outputs are active whem they should be.
Thanks, it's really good to know that we have a good working-base.
Now, can you switch back to 3.0rc2 with my fix patch and retest?
Sorry, I am confused now. How this would be different from the previous testing where I had that patch applied on top of rc2?
Never mind, I found the possible spot. Could you try the patch below in addition? There was one missing initialization in the transition.
I have applied this patch on top of clean rc2.
And apply my previous patch, too. There are two fixes.
Sorry, I have missed that I should apply the previous one as well. Nevermind, I have good news. With both patches applied, sound works as expected.
Feel free to add my Tested-by.
Great, thanks for patient testing!
Takashi
At Fri, 10 Jun 2011 09:56:40 +0200, Michal Hocko wrote:
Note that the one-minute thing happens only when you unplug AC cable, supposedly.
Hmmm, I was plugged during testing all the time. OK, this looks like a separate issue. I will repost it as a separate thread once we are done with this. Any idea who to CC?
First off, check /sys/modules/snd_hda_intel/parameters/powersave value. If this is set to non-zero, someone must have played with it, e.g. pm-utils or such.
Takashi
[changed subject]
As a summary: I am loosing sound after powe_save timeout expires if there is no device activity. The only way how to get sound back is to unload the module and load it again.
On Fri 10-06-11 10:17:09, Takashi Iwai wrote:
At Fri, 10 Jun 2011 09:56:40 +0200, Michal Hocko wrote:
Note that the one-minute thing happens only when you unplug AC cable, supposedly.
Hmmm, I was plugged during testing all the time. OK, this looks like a separate issue. I will repost it as a separate thread once we are done with this. Any idea who to CC?
First off, check /sys/modules/snd_hda_intel/parameters/powersave value. If this is set to non-zero, someone must have played with it, e.g. pm-utils or such.
Yes, it contains 60. And the value comes from: CONFIG_SND_HDA_POWER_SAVE_DEFAULT=60
which defaults to 0 so it must have been changed by me some time ago (really do not remember when and why, though). Anyway I have the same value in 2.6.39 kernel as well and I do not see any problem there. So it looks like a regression.
At Fri, 10 Jun 2011 10:39:56 +0200, Michal Hocko wrote:
[changed subject]
As a summary: I am loosing sound after powe_save timeout expires if there is no device activity. The only way how to get sound back is to unload the module and load it again.
On Fri 10-06-11 10:17:09, Takashi Iwai wrote:
At Fri, 10 Jun 2011 09:56:40 +0200, Michal Hocko wrote:
Note that the one-minute thing happens only when you unplug AC cable, supposedly.
Hmmm, I was plugged during testing all the time. OK, this looks like a separate issue. I will repost it as a separate thread once we are done with this. Any idea who to CC?
First off, check /sys/modules/snd_hda_intel/parameters/powersave value. If this is set to non-zero, someone must have played with it, e.g. pm-utils or such.
Yes, it contains 60. And the value comes from: CONFIG_SND_HDA_POWER_SAVE_DEFAULT=60
which defaults to 0 so it must have been changed by me some time ago (really do not remember when and why, though). Anyway I have the same value in 2.6.39 kernel as well and I do not see any problem there. So it looks like a regression.
Interestingly, I see power_save=0 value in some of your alsa-info.sh outputs. That is, something changed it to 0 dynamically even though you set to 60 as default. (I thought it was set to 60 by daemon, but in reality, it was reverted -- it was clear to 0 dynamically.)
It might be just coincidence that the older kernel didn't show the problem. It might have power_save=0 set dynamically without noticing...
thanks,
Takashi
On Fri 2011-06-10 10:39:56, Michal Hocko wrote:
[changed subject]
As a summary: I am loosing sound after powe_save timeout expires if there is no device activity. The only way how to get sound back is to unload the module and load it again.
Hmm, today my x60 with 3.0-rc was strangely quiet. Coincidence? pavel
At Wed, 15 Jun 2011 06:08:18 +0000, Pavel Machek wrote:
On Fri 2011-06-10 10:39:56, Michal Hocko wrote:
[changed subject]
As a summary: I am loosing sound after powe_save timeout expires if there is no device activity. The only way how to get sound back is to unload the module and load it again.
Hmm, today my x60 with 3.0-rc was strangely quiet. Coincidence?
quiet = no sound at all, or softer volume?
If it's about a mixer or an EAPD issue, you should be able to see differences by comparing alsa-info.sh outputs at working and non-working states. This is the most cases of powersave-mode bugs.
thanks,
Takashi
participants (3)
-
Michal Hocko -
Pavel Machek -
Takashi Iwai