[alsa-devel] HDA: no sound [was: mmotm 2010-10-20-15-01 uploaded]
On 10/21/2010 12:01 AM, akpm@linux-foundation.org wrote:
The mm-of-the-moment snapshot 2010-10-20-15-01 has been uploaded to
Hi, I've lost sound with my intel hda (sigmatel) in this release (regression against mmotm 2010-10-13-17-13).
All outputs were silented at level 0 after reboot, but even after setting them non-zero in alsamixer -D hw, no sound can be heard by: mplayer -ao alsa:device=hw /usr/share/sounds/alsa/Front_Center.wav
I don't knwo if it's related, but aplay complains like (even if I pass -c 2): aplay -D hw /usr/share/sounds/alsa/Front_Center.wav Playing WAVE '/usr/share/sounds/alsa/Front_Center.wav' : Signed 16 bit Little Endian, Rate 48000 Hz, Mono aplay: set_params:1065: Channels count non available
alsa-info: http://www.alsa-project.org/db/?f=a7a09703bcc8c43386c87a984e513ce35fc91ca4
regards,
At Thu, 21 Oct 2010 09:41:08 +0200, Jiri Slaby wrote:
On 10/21/2010 12:01 AM, akpm@linux-foundation.org wrote:
The mm-of-the-moment snapshot 2010-10-20-15-01 has been uploaded to
Hi, I've lost sound with my intel hda (sigmatel) in this release (regression against mmotm 2010-10-13-17-13).
All outputs were silented at level 0 after reboot, but even after setting them non-zero in alsamixer -D hw, no sound can be heard by: mplayer -ao alsa:device=hw /usr/share/sounds/alsa/Front_Center.wav
I don't knwo if it's related, but aplay complains like (even if I pass -c 2): aplay -D hw /usr/share/sounds/alsa/Front_Center.wav Playing WAVE '/usr/share/sounds/alsa/Front_Center.wav' : Signed 16 bit Little Endian, Rate 48000 Hz, Mono aplay: set_params:1065: Channels count non available
This is irrelevant. The hardware supports only stereo streams while you are trying to play a mono-channel stream.
alsa-info: http://www.alsa-project.org/db/?f=a7a09703bcc8c43386c87a984e513ce35fc91ca4
I see the Front volume is set to zero. Try to raise it.
Takashi
On 10/21/2010 09:49 AM, Takashi Iwai wrote:
At Thu, 21 Oct 2010 09:41:08 +0200, Jiri Slaby wrote:
alsa-info: http://www.alsa-project.org/db/?f=a7a09703bcc8c43386c87a984e513ce35fc91ca4
I see the Front volume is set to zero. Try to raise it.
I set all the values to ~ 70 and then tried with pure alsa. It basically works.
BUT, when I run pulse and it suspends the device (or whatever), all the levels get down to 0 back again. When I raise it and run mplayer, it gets to 0 immediately. If I raise it gets to 0 when mplayer finishes and pulse writes 'protocol-native.c: Connection died.'. It never raises automatically. And if I raise it during playback, nothing plays at all.
regards,
At Thu, 21 Oct 2010 09:57:16 +0200, Jiri Slaby wrote:
On 10/21/2010 09:49 AM, Takashi Iwai wrote:
At Thu, 21 Oct 2010 09:41:08 +0200, Jiri Slaby wrote:
alsa-info: http://www.alsa-project.org/db/?f=a7a09703bcc8c43386c87a984e513ce35fc91ca4
I see the Front volume is set to zero. Try to raise it.
I set all the values to ~ 70 and then tried with pure alsa. It basically works.
BUT, when I run pulse and it suspends the device (or whatever), all the levels get down to 0 back again. When I raise it and run mplayer, it gets to 0 immediately. If I raise it gets to 0 when mplayer finishes and pulse writes 'protocol-native.c: Connection died.'. It never raises automatically. And if I raise it during playback, nothing plays at all.
Hrm, I don't remember any so critical changes done recently in the sound tree. The only possibly affecting commits are:
commit 1cc9e8f4c45999e6069f41521d9d391eeeccc3b3 ALSA: hda - Fix codec muted after rebooting from Windows
commit de8c85f7840e5e29629de95f5af24297fb325e0b ALSA: HDA: Sigmatel: work around incorrect master muting
Could you try to revert them?
thanks,
Takashi
On 10/21/2010 10:05 AM, Takashi Iwai wrote:
At Thu, 21 Oct 2010 09:57:16 +0200, Jiri Slaby wrote:
BUT, when I run pulse and it suspends the device (or whatever), all the levels get down to 0 back again. When I raise it and run mplayer, it gets to 0 immediately. If I raise it gets to 0 when mplayer finishes and pulse writes 'protocol-native.c: Connection died.'. It never raises automatically. And if I raise it during playback, nothing plays at all.
Hrm, I don't remember any so critical changes done recently in the sound tree. The only possibly affecting commits are:
commit 1cc9e8f4c45999e6069f41521d9d391eeeccc3b3 ALSA: hda - Fix codec muted after rebooting from Windows
commit de8c85f7840e5e29629de95f5af24297fb325e0b ALSA: HDA: Sigmatel: work around incorrect master muting
Reverting this one helps.
thanks,
At Thu, 21 Oct 2010 20:27:01 +0200, Jiri Slaby wrote:
On 10/21/2010 10:05 AM, Takashi Iwai wrote:
At Thu, 21 Oct 2010 09:57:16 +0200, Jiri Slaby wrote:
BUT, when I run pulse and it suspends the device (or whatever), all the levels get down to 0 back again. When I raise it and run mplayer, it gets to 0 immediately. If I raise it gets to 0 when mplayer finishes and pulse writes 'protocol-native.c: Connection died.'. It never raises automatically. And if I raise it during playback, nothing plays at all.
Hrm, I don't remember any so critical changes done recently in the sound tree. The only possibly affecting commits are:
commit 1cc9e8f4c45999e6069f41521d9d391eeeccc3b3 ALSA: hda - Fix codec muted after rebooting from Windows
commit de8c85f7840e5e29629de95f5af24297fb325e0b ALSA: HDA: Sigmatel: work around incorrect master muting
Reverting this one helps.
The latter one?
Takashi
On 10/21/2010 09:20 PM, Takashi Iwai wrote:
At Thu, 21 Oct 2010 20:27:01 +0200, Jiri Slaby wrote:
On 10/21/2010 10:05 AM, Takashi Iwai wrote:
At Thu, 21 Oct 2010 09:57:16 +0200, Jiri Slaby wrote:
BUT, when I run pulse and it suspends the device (or whatever), all the levels get down to 0 back again. When I raise it and run mplayer, it gets to 0 immediately. If I raise it gets to 0 when mplayer finishes and pulse writes 'protocol-native.c: Connection died.'. It never raises automatically. And if I raise it during playback, nothing plays at all.
Hrm, I don't remember any so critical changes done recently in the sound tree. The only possibly affecting commits are:
commit 1cc9e8f4c45999e6069f41521d9d391eeeccc3b3 ALSA: hda - Fix codec muted after rebooting from Windows
commit de8c85f7840e5e29629de95f5af24297fb325e0b ALSA: HDA: Sigmatel: work around incorrect master muting
Reverting this one helps.
The latter one?
Yeah. Otherwise I would write it to the former :).
At Thu, 21 Oct 2010 21:21:32 +0200, Jiri Slaby wrote:
On 10/21/2010 09:20 PM, Takashi Iwai wrote:
At Thu, 21 Oct 2010 20:27:01 +0200, Jiri Slaby wrote:
On 10/21/2010 10:05 AM, Takashi Iwai wrote:
At Thu, 21 Oct 2010 09:57:16 +0200, Jiri Slaby wrote:
BUT, when I run pulse and it suspends the device (or whatever), all the levels get down to 0 back again. When I raise it and run mplayer, it gets to 0 immediately. If I raise it gets to 0 when mplayer finishes and pulse writes 'protocol-native.c: Connection died.'. It never raises automatically. And if I raise it during playback, nothing plays at all.
Hrm, I don't remember any so critical changes done recently in the sound tree. The only possibly affecting commits are:
commit 1cc9e8f4c45999e6069f41521d9d391eeeccc3b3 ALSA: hda - Fix codec muted after rebooting from Windows
commit de8c85f7840e5e29629de95f5af24297fb325e0b ALSA: HDA: Sigmatel: work around incorrect master muting
Reverting this one helps.
The latter one?
Yeah. Otherwise I would write it to the former :).
Yeah, I'm just be careful now ;)
Takashi
At Thu, 21 Oct 2010 21:21:32 +0200, Jiri Slaby wrote:
On 10/21/2010 09:20 PM, Takashi Iwai wrote:
At Thu, 21 Oct 2010 20:27:01 +0200, Jiri Slaby wrote:
On 10/21/2010 10:05 AM, Takashi Iwai wrote:
At Thu, 21 Oct 2010 09:57:16 +0200, Jiri Slaby wrote:
BUT, when I run pulse and it suspends the device (or whatever), all the levels get down to 0 back again. When I raise it and run mplayer, it gets to 0 immediately. If I raise it gets to 0 when mplayer finishes and pulse writes 'protocol-native.c: Connection died.'. It never raises automatically. And if I raise it during playback, nothing plays at all.
Hrm, I don't remember any so critical changes done recently in the sound tree. The only possibly affecting commits are:
commit 1cc9e8f4c45999e6069f41521d9d391eeeccc3b3 ALSA: hda - Fix codec muted after rebooting from Windows
commit de8c85f7840e5e29629de95f5af24297fb325e0b ALSA: HDA: Sigmatel: work around incorrect master muting
Reverting this one helps.
The latter one?
Yeah. Otherwise I would write it to the former :).
This might be a user-space issue, then.
Could you try once the latest alsa-lib? If you are using SUSE packages, the snapshot rpms are available on OBS multimedia:audio:snapshot/alsa repo. (The version number of the package is still 1.0.22, but don't care; I just forgot to change the spec file.)
thanks,
Takashi
On Thu, 21 Oct 2010 21:40:08 +0200, Takashi Iwai said:
commit de8c85f7840e5e29629de95f5af24297fb325e0b ALSA: HDA: Sigmatel: work around incorrect master muting
Reverting this one helps.
The latter one?
Yeah. Otherwise I would write it to the former :).
Confirming - reverting that one commit fixes sound on my Dell laptop as well.
This might be a user-space issue, then.
That would be icky, if we have to lockstep a 2.6.37 kernel upgrade to an alsa-lib upgrade. Stuff like udev and perf having to lockstep is bad enough...
Could you try once the latest alsa-lib? If you are using SUSE packages, the snapshot rpms are available on OBS multimedia:audio:snapshot/alsa repo. (The version number of the package is still 1.0.22, but don't care; I just forgot to change the spec file.
Hmm... on my laptop, Fedora Rawhide is showing:
% rpm -qi alsa-lib Name : alsa-lib Relocations: (not relocatable) Version : 1.0.23 Vendor: Fedora Project Release : 1.fc14 Build Date: Fri 16 Apr 2010 07:48:17 AM EDT Install Date: Sun 18 Apr 2010 03:22:04 PM EDT Build Host: x86-02.phx2.fedoraproject.org Group : System Environment/Libraries Source RPM: alsa-lib-1.0.23-1.fc14.src.rpm Size : 1188301 License: LGPLv2+ Signature : (none) Packager : Fedora Project URL : http://www.alsa-project.org/ Summary : The Advanced Linux Sound Architecture (ALSA) library Description : The Advanced Linux Sound Architecture (ALSA) provides audio and MIDI functionality to the Linux operating system.
Is that "recent enough", or do I need to find something newer?
[Added Colin to Cc]
At Thu, 21 Oct 2010 16:29:17 -0400, Valdis.Kletnieks@vt.edu wrote:
On Thu, 21 Oct 2010 21:40:08 +0200, Takashi Iwai said:
commit de8c85f7840e5e29629de95f5af24297fb325e0b ALSA: HDA: Sigmatel: work around incorrect master muting
Reverting this one helps.
The latter one?
Yeah. Otherwise I would write it to the former :).
Confirming - reverting that one commit fixes sound on my Dell laptop as well.
This might be a user-space issue, then.
That would be icky, if we have to lockstep a 2.6.37 kernel upgrade to an alsa-lib upgrade. Stuff like udev and perf having to lockstep is bad enough...
Yeah, if this is really the culprit, we should think of reverting the commit, at least until the use-space fix is more populated.
Could you try once the latest alsa-lib? If you are using SUSE packages, the snapshot rpms are available on OBS multimedia:audio:snapshot/alsa repo. (The version number of the package is still 1.0.22, but don't care; I just forgot to change the spec file.
Hmm... on my laptop, Fedora Rawhide is showing:
% rpm -qi alsa-lib Name : alsa-lib Relocations: (not relocatable) Version : 1.0.23 Vendor: Fedora Project Release : 1.fc14 Build Date: Fri 16 Apr 2010 07:48:17 AM EDT Install Date: Sun 18 Apr 2010 03:22:04 PM EDT Build Host: x86-02.phx2.fedoraproject.org Group : System Environment/Libraries Source RPM: alsa-lib-1.0.23-1.fc14.src.rpm Size : 1188301 License: LGPLv2+ Signature : (none) Packager : Fedora Project URL : http://www.alsa-project.org/ Summary : The Advanced Linux Sound Architecture (ALSA) library Description : The Advanced Linux Sound Architecture (ALSA) provides audio and MIDI functionality to the Linux operating system.
Is that "recent enough", or do I need to find something newer?
Well, this doesn't tell much... The fix patch for alsa-lib is pretty recent. Attached below.
thanks,
Takashi
--- commit 2f6206da0c1ff88235e6eca0077343f22a4b43ee Author: Clemens Ladisch clemens@ladisch.de Date: Fri Oct 15 10:33:20 2010 +0200
tlv: fix returned dB information for min-is-mute controls
For TLV information that indicates that the minimum value is actually muted, the returned range used the wrong minimum dB value, and converting dB values to raw control values did not round up correctly near the minimum.
Signed-off-by: Clemens Ladisch clemens@ladisch.de Signed-off-by: Takashi Iwai tiwai@suse.de
diff --git a/src/control/tlv.c b/src/control/tlv.c index ba52752..f7c9976 100644 --- a/src/control/tlv.c +++ b/src/control/tlv.c @@ -167,17 +167,23 @@ int snd_tlv_get_dB_range(unsigned int *tlv, long rangemin, long rangemax, } case SND_CTL_TLVT_DB_SCALE: { int step; - *min = (int)tlv[2]; + if (tlv[3] & 0x10000) + *min = SND_CTL_TLV_DB_GAIN_MUTE; + else + *min = (int)tlv[2]; step = (tlv[3] & 0xffff); - *max = *min + (long)(step * (rangemax - rangemin)); + *max = (int)tlv[2] + step * (rangemax - rangemin); return 0; } case SND_CTL_TLVT_DB_MINMAX: - case SND_CTL_TLVT_DB_MINMAX_MUTE: case SND_CTL_TLVT_DB_LINEAR: *min = (int)tlv[2]; *max = (int)tlv[3]; return 0; + case SND_CTL_TLVT_DB_MINMAX_MUTE: + *min = SND_CTL_TLV_DB_GAIN_MUTE; + *max = (int)tlv[3]; + return 0; } return -EINVAL; } @@ -217,7 +223,7 @@ int snd_tlv_convert_to_dB(unsigned int *tlv, long rangemin, long rangemax, min = tlv[2]; step = (tlv[3] & 0xffff); mute = (tlv[3] >> 16) & 1; - if (mute && volume == rangemin) + if (mute && volume <= rangemin) *db_gain = SND_CTL_TLV_DB_GAIN_MUTE; else *db_gain = (volume - rangemin) * step + min; @@ -327,7 +333,11 @@ int snd_tlv_convert_from_dB(unsigned int *tlv, long rangemin, long rangemax, step = (tlv[3] & 0xffff); max = min + (int)(step * (rangemax - rangemin)); if (db_gain <= min) - *value = rangemin; + if (db_gain > SND_CTL_TLV_DB_GAIN_MUTE && xdir > 0 && + (tlv[3] & 0x10000)) + *value = rangemin + 1; + else + *value = rangemin; else if (db_gain >= max) *value = rangemax; else { @@ -345,7 +355,11 @@ int snd_tlv_convert_from_dB(unsigned int *tlv, long rangemin, long rangemax, min = tlv[2]; max = tlv[3]; if (db_gain <= min) - *value = rangemin; + if (db_gain > SND_CTL_TLV_DB_GAIN_MUTE && xdir > 0 && + tlv[0] == SND_CTL_TLVT_DB_MINMAX_MUTE) + *value = rangemin + 1; + else + *value = rangemin; else if (db_gain >= max) *value = rangemax; else {
On Thu, 21 Oct 2010 22:48:08 +0200, Takashi Iwai said:
Yeah, if this is really the culprit, we should think of reverting the commit, at least until the use-space fix is more populated.
Am I allowed to NAK this commit till we get it sorted out? :)
Well, this doesn't tell much... The fix patch for alsa-lib is pretty recent. Attached below.
commit 2f6206da0c1ff88235e6eca0077343f22a4b43ee Author: Clemens Ladisch clemens@ladisch.de Date: Fri Oct 15 10:33:20 2010 +0200
That looks like a pretty self-contained patch, I should be able to build a local test alsa-lib with that one added and see if it works with both old and new kernels. If I don't get a chance to do it tonight, won't be till Monday I suspect, am booked solid with other stuff till then...
At Thu, 21 Oct 2010 17:24:24 -0400, Valdis.Kletnieks@vt.edu wrote:
On Thu, 21 Oct 2010 22:48:08 +0200, Takashi Iwai said:
Yeah, if this is really the culprit, we should think of reverting the commit, at least until the use-space fix is more populated.
Am I allowed to NAK this commit till we get it sorted out? :)
Well, it's not confirmed whether it just triggered an alsa-lib bug or not. A revert is an easy option, and we can do it at any time. But I'd like to know first what is the real problem.
Well, this doesn't tell much... The fix patch for alsa-lib is pretty recent. Attached below.
commit 2f6206da0c1ff88235e6eca0077343f22a4b43ee Author: Clemens Ladisch clemens@ladisch.de Date: Fri Oct 15 10:33:20 2010 +0200
That looks like a pretty self-contained patch, I should be able to build a local test alsa-lib with that one added and see if it works with both old and new kernels. If I don't get a chance to do it tonight, won't be till Monday I suspect, am booked solid with other stuff till then...
OK. Maybe someone else can check it meanwhile.
thanks,
Takashi
On 10/21/2010 11:31 PM, Takashi Iwai wrote:
OK. Maybe someone else can check it meanwhile.
Someone else rebooted the 13th time today and checked :): $ rpm -q `rpmqpack |egrep 'alsa|asound'|sort` alsa-1.0.22.git20101018-1.1.x86_64 alsa-firmware-1.0.23-3.7.noarch alsa-oss-1.0.17-31.4.x86_64 alsa-plugins-1.0.23-4.5.x86_64 alsa-plugins-pulse-1.0.23-4.5.x86_64 alsa-plugins-pulse-32bit-1.0.23-4.5.x86_64 alsa-plugins-32bit-1.0.23-4.5.x86_64 alsa-utils-1.0.23-4.5.x86_64 libasound2-1.0.22.git20101018-1.1.x86_64 libasound2-32bit-1.0.23-6.5.x86_64
No success. I still need the revert.
regards,
'Twas brillig, and Jiri Slaby at 21/10/10 22:42 did gyre and gimble:
On 10/21/2010 11:31 PM, Takashi Iwai wrote:
OK. Maybe someone else can check it meanwhile.
Someone else rebooted the 13th time today and checked :): $ rpm -q `rpmqpack |egrep 'alsa|asound'|sort` alsa-1.0.22.git20101018-1.1.x86_64 alsa-firmware-1.0.23-3.7.noarch alsa-oss-1.0.17-31.4.x86_64 alsa-plugins-1.0.23-4.5.x86_64 alsa-plugins-pulse-1.0.23-4.5.x86_64 alsa-plugins-pulse-32bit-1.0.23-4.5.x86_64 alsa-plugins-32bit-1.0.23-4.5.x86_64 alsa-utils-1.0.23-4.5.x86_64 libasound2-1.0.22.git20101018-1.1.x86_64 libasound2-32bit-1.0.23-6.5.x86_64
No success. I still need the revert.
regards,
Just tested the latest kernel patch in a "proper" (i.e. patched in kernel) build (as opposed to my previous out-of-tree builds).
It's working great for me (stac9200)
I tried without the userspace patch and things still work fine for me under this setup - it's just that PAs flat volumes do not properly control the Master+PCM pipeline (they both go to mute when master hits 0).
But it doesn't seem to cause any other problems for me.
I'm no expert at the kernel side, but can't see much in the code that would cause this.
However, from Jiri's alsa-info, this looks a bit suspicious:
Simple mixer control 'Master',0 Capabilities: pvolume pvolume-joined pswitch pswitch-joined penum Playback channels: Mono Limits: Playback 0 - 64 Mono: Playback 40 [62%] [1620.40dB] [on]
1620.40dB?? Really?
Is perhaps the TLV fix for min-is-mute conflicting with a db range fix?
Col
At Fri, 22 Oct 2010 09:46:06 +0100, Colin Guthrie wrote:
'Twas brillig, and Jiri Slaby at 21/10/10 22:42 did gyre and gimble:
On 10/21/2010 11:31 PM, Takashi Iwai wrote:
OK. Maybe someone else can check it meanwhile.
Someone else rebooted the 13th time today and checked :): $ rpm -q `rpmqpack |egrep 'alsa|asound'|sort` alsa-1.0.22.git20101018-1.1.x86_64 alsa-firmware-1.0.23-3.7.noarch alsa-oss-1.0.17-31.4.x86_64 alsa-plugins-1.0.23-4.5.x86_64 alsa-plugins-pulse-1.0.23-4.5.x86_64 alsa-plugins-pulse-32bit-1.0.23-4.5.x86_64 alsa-plugins-32bit-1.0.23-4.5.x86_64 alsa-utils-1.0.23-4.5.x86_64 libasound2-1.0.22.git20101018-1.1.x86_64 libasound2-32bit-1.0.23-6.5.x86_64
No success. I still need the revert.
regards,
Just tested the latest kernel patch in a "proper" (i.e. patched in kernel) build (as opposed to my previous out-of-tree builds).
It's working great for me (stac9200)
I tried without the userspace patch and things still work fine for me under this setup - it's just that PAs flat volumes do not properly control the Master+PCM pipeline (they both go to mute when master hits 0).
So, you mean it works without alsa-lib patch on your system?
The symptom was somehow related with the suspend or initialization. In the early post (sorry, this wasn't cited in the mail you added to Cc), Jiri mentioned:
BUT, when I run pulse and it suspends the device (or whatever), all the levels get down to 0 back again. When I raise it and run mplayer, it gets to 0 immediately. If I raise it gets to 0 when mplayer finishes and pulse writes 'protocol-native.c: Connection died.'. It never raises automatically. And if I raise it during playback, nothing plays at all.
But it doesn't seem to cause any other problems for me.
I'm no expert at the kernel side, but can't see much in the code that would cause this.
However, from Jiri's alsa-info, this looks a bit suspicious:
Simple mixer control 'Master',0 Capabilities: pvolume pvolume-joined pswitch pswitch-joined penum Playback channels: Mono Limits: Playback 0 - 64 Mono: Playback 40 [62%] [1620.40dB] [on]
1620.40dB?? Really?
Is perhaps the TLV fix for min-is-mute conflicting with a db range fix?
Well, it doesn't conflict but the old alsa-lib just takes the value as is -- i.e. the mute high bit is evaluated as a normal value. So, obviously it passes a wrong value for the old alsa-lib.
The above result is likely because alsa-info was generated with the unpatched alsa-lib. Jiri, could you regenerate alsa-info output with the fixed alsa-lib packages? With the fixed alsa-lib, the dB value should be given correctly.
Anyway, judging from the fact above (giving a really wrong value), we will have to revert the commit...
thanks,
Takashi
On 10/22/2010 11:02 AM, Takashi Iwai wrote:
unpatched alsa-lib. Jiri, could you regenerate alsa-info output with the fixed alsa-lib packages? With the fixed alsa-lib, the dB value should be given correctly.
Sure, but I don't know which version you want, so with the patch reverted: http://www.alsa-project.org/db/?f=4efd8e3b74a51adbd014a85052a83b4a3c5bd9fc
with the patch NOT reverted: http://www.alsa-project.org/db/?f=e619bba74bb9ea007c2e5314761411a658ff677b
regards,
At Fri, 22 Oct 2010 11:18:37 +0200, Jiri Slaby wrote:
On 10/22/2010 11:02 AM, Takashi Iwai wrote:
unpatched alsa-lib. Jiri, could you regenerate alsa-info output with the fixed alsa-lib packages? With the fixed alsa-lib, the dB value should be given correctly.
Sure, but I don't know which version you want, so with the patch reverted: http://www.alsa-project.org/db/?f=4efd8e3b74a51adbd014a85052a83b4a3c5bd9fc
with the patch NOT reverted: http://www.alsa-project.org/db/?f=e619bba74bb9ea007c2e5314761411a658ff677b
Hrm, is it with alsa.rpm and libasound2.rpm from OBS multimedia:audio:snapshot repo?
If yes, something wrong in the alsa-lib packaging...
Takashi
On 10/22/2010 11:40 AM, Takashi Iwai wrote:
Hrm, is it with alsa.rpm and libasound2.rpm from OBS multimedia:audio:snapshot repo?
Aha, I dupped in the meantime and it vanished.
With the revert: http://www.alsa-project.org/db/?f=7b9b41e9494674b1e5a8ec0b5dd250058ecff887
Without the revert: http://www.alsa-project.org/db/?f=dc92721d4587f8f6289dfb25eb0ac523a2704f21
regards,
At Fri, 22 Oct 2010 11:45:36 +0200, Jiri Slaby wrote:
On 10/22/2010 11:40 AM, Takashi Iwai wrote:
Hrm, is it with alsa.rpm and libasound2.rpm from OBS multimedia:audio:snapshot repo?
Aha, I dupped in the meantime and it vanished.
With the revert: http://www.alsa-project.org/db/?f=7b9b41e9494674b1e5a8ec0b5dd250058ecff887
Without the revert: http://www.alsa-project.org/db/?f=dc92721d4587f8f6289dfb25eb0ac523a2704f21
It's still showing a strange value. Weird.
I updated the version number and triggered rebuilds on OBS multimedia:audio:snapshot packages. To be sure, install alsa.rpm, libasound2.rpm and alsa-utils.rpm later from the project. Now they should have version 1.0.23.git*.
Also, you don't need to check the reverted kernel. The only interesting thing is to see whether the dB range brokeness is fixed by alsa-lib update.
thanks,
Takashi
On 10/22/2010 12:26 PM, Takashi Iwai wrote:
I updated the version number and triggered rebuilds on OBS multimedia:audio:snapshot packages. To be sure, install alsa.rpm, libasound2.rpm and alsa-utils.rpm later from the project. Now they should have version 1.0.23.git*.
alsa-1.0.23.git20101018-1.1.x86_64 alsa-firmware-1.0.23-3.7.noarch alsa-oss-1.0.17-31.4.x86_64 alsa-plugins-1.0.23-4.5.x86_64 alsa-plugins-pulse-1.0.23-4.5.x86_64 alsa-plugins-pulse-32bit-1.0.23-4.5.x86_64 alsa-plugins-32bit-1.0.23-4.5.x86_64 alsa-utils-1.0.23.git20101022-3.1.x86_64 libasound2-1.0.23.git20101018-1.1.x86_64 libasound2-32bit-1.0.23-6.5.x86_64
Also, you don't need to check the reverted kernel. The only interesting thing is to see whether the dB range brokeness is fixed by alsa-lib update.
With patch not reverted (i.e. no sound): http://www.alsa-project.org/db/?f=378efb40f8c5b1d6204e93221512506e7bb7b061
regards,
'Twas brillig, and Takashi Iwai at 22/10/10 10:02 did gyre and gimble:
At Fri, 22 Oct 2010 09:46:06 +0100, Colin Guthrie wrote:
Just tested the latest kernel patch in a "proper" (i.e. patched in kernel) build (as opposed to my previous out-of-tree builds).
It's working great for me (stac9200)
I tried without the userspace patch and things still work fine for me under this setup - it's just that PAs flat volumes do not properly control the Master+PCM pipeline (they both go to mute when master hits 0).
So, you mean it works without alsa-lib patch on your system?
Yeah everything still works OK, but the infamous "mute at 16%" issue is obviously unresolved.
The difference with the kernel patch applied vs. not applied is that alsamixer reports the device volume as "mute" when Master is at 0 with the patch and it reports it as -46.5dB without the patch.
The symptom was somehow related with the suspend or initialization. In the early post (sorry, this wasn't cited in the mail you added to Cc), Jiri mentioned:
BUT, when I run pulse and it suspends the device (or whatever), all the levels get down to 0 back again. When I raise it and run mplayer, it gets to 0 immediately. If I raise it gets to 0 when mplayer finishes and pulse writes 'protocol-native.c: Connection died.'. It never raises automatically. And if I raise it during playback, nothing plays at all.
Yeah, I did read that via the lklm archive. It's very odd that the volumes change when pulse suspends the device... I could understand if it changed when it opens them again (it will look at the product of the mixers in the pipeline - e.g. Master+PCM - then work out the over all dB then rearrange the sliders so that the same dB is ultimately obtained, but perhaps via a different combination of mixer positions (e.g. it will use all of Master first and only then adjust PCM). Overall the volume itself should remain at the same dB tho'.
I'm no expert at the kernel side, but can't see much in the code that would cause this.
However, from Jiri's alsa-info, this looks a bit suspicious:
Simple mixer control 'Master',0 Capabilities: pvolume pvolume-joined pswitch pswitch-joined penum Playback channels: Mono Limits: Playback 0 - 64 Mono: Playback 40 [62%] [1620.40dB] [on]
1620.40dB?? Really?
Is perhaps the TLV fix for min-is-mute conflicting with a db range fix?
Well, it doesn't conflict but the old alsa-lib just takes the value as is -- i.e. the mute high bit is evaluated as a normal value. So, obviously it passes a wrong value for the old alsa-lib.
Right. This actually probably explains things thinking about it...
Because the range is incorrectly reflected without the alsa-lib patch. PA tries to set the volume to a "sensible" dB value.
This value would likely cause Master to be set to 0 (seeing as 1620.40dB is 40, $sensible_dB is likely mapped to 0). When the device hits 0, the kernel patch causes this to be properly reflected as "mute" (or -infdB?) and thus PA notices this and sets both Master and PCM to 0 for that reason.
That might not be exactly what's going on, but it's probably some similar variant thereof.
The above result is likely because alsa-info was generated with the unpatched alsa-lib. Jiri, could you regenerate alsa-info output with the fixed alsa-lib packages? With the fixed alsa-lib, the dB value should be given correctly.
I'm surprised that the updated alsa-lib did not fix this problem. We're now pushing out both the kernel and userspace fix, so I'll see if anyone is affected by this in the same way as Jiri.
Jiri, when you tested the userspace updated package did you remember to restart PA? If not then the test will not have worked as expected (the fact that both your subsequent alsa-info's have sensible dB values for Master suggests that the userspace fix is installed). Also when Takashi asked for updated alsa-info script above, he meant to do it with both the kernel and userspace patches applied.
Anyway, judging from the fact above (giving a really wrong value), we will have to revert the commit...
Yes, sadly that seems so. Any bright idea on how to fix this in a less invasive (i.e. backwards compatible) way?
Cheers
Col
Jiri Slaby wrote:
On 10/21/2010 10:05 AM, Takashi Iwai wrote:
commit de8c85f7840e5e29629de95f5af24297fb325e0b ALSA: HDA: Sigmatel: work around incorrect master muting
Reverting this one helps.
This one introduced even more wrong volume information on some codecs. Pleasy try this patch on top:
--- a/sound/pci/hda/patch_sigmatel.c +++ b/sound/pci/hda/patch_sigmatel.c @@ -32,6 +32,7 @@ #include <sound/core.h> #include <sound/asoundef.h> #include <sound/jack.h> +#include <sound/tlv.h> #include "hda_codec.h" #include "hda_local.h" #include "hda_beep.h" @@ -1145,7 +1146,7 @@ static int stac92xx_build_controls(struct hda_codec *codec) /* correct volume offset */ vmaster_tlv[2] += vmaster_tlv[3] * spec->volume_offset; /* minimum value is actually mute */ - vmaster_tlv[3] |= 0x1000; + vmaster_tlv[3] |= TLV_DB_SCALE_MUTE; err = snd_hda_add_vmaster(codec, "Master Playback Volume", vmaster_tlv, slave_vols); if (err < 0)
On 10/22/2010 01:31 PM, Clemens Ladisch wrote:
Jiri Slaby wrote:
On 10/21/2010 10:05 AM, Takashi Iwai wrote:
commit de8c85f7840e5e29629de95f5af24297fb325e0b ALSA: HDA: Sigmatel: work around incorrect master muting
Reverting this one helps.
This one introduced even more wrong volume information on some codecs. Pleasy try this patch on top:
Yup, works for me.
--- a/sound/pci/hda/patch_sigmatel.c +++ b/sound/pci/hda/patch_sigmatel.c @@ -32,6 +32,7 @@ #include <sound/core.h> #include <sound/asoundef.h> #include <sound/jack.h> +#include <sound/tlv.h> #include "hda_codec.h" #include "hda_local.h" #include "hda_beep.h" @@ -1145,7 +1146,7 @@ static int stac92xx_build_controls(struct hda_codec *codec) /* correct volume offset */ vmaster_tlv[2] += vmaster_tlv[3] * spec->volume_offset; /* minimum value is actually mute */
vmaster_tlv[3] |= 0x1000;
vmaster_tlv[3] |= TLV_DB_SCALE_MUTE;
thanks,
At Fri, 22 Oct 2010 13:31:53 +0200, Clemens Ladisch wrote:
Jiri Slaby wrote:
On 10/21/2010 10:05 AM, Takashi Iwai wrote:
commit de8c85f7840e5e29629de95f5af24297fb325e0b ALSA: HDA: Sigmatel: work around incorrect master muting
Reverting this one helps.
This one introduced even more wrong volume information on some codecs. Pleasy try this patch on top:
Argh! There is always a reason why we should define a constant. I applied the fix now.
This explains why the old patch worked on Colin's machine. His codec chip is different (STAC9200?), and it doesn't go in this code path but has a static Master volume creation.
thanks,
Takashi
--- a/sound/pci/hda/patch_sigmatel.c +++ b/sound/pci/hda/patch_sigmatel.c @@ -32,6 +32,7 @@ #include <sound/core.h> #include <sound/asoundef.h> #include <sound/jack.h> +#include <sound/tlv.h> #include "hda_codec.h" #include "hda_local.h" #include "hda_beep.h" @@ -1145,7 +1146,7 @@ static int stac92xx_build_controls(struct hda_codec *codec) /* correct volume offset */ vmaster_tlv[2] += vmaster_tlv[3] * spec->volume_offset; /* minimum value is actually mute */
vmaster_tlv[3] |= 0x1000;
vmaster_tlv[3] |= TLV_DB_SCALE_MUTE;
'Twas brillig, and Takashi Iwai at 22/10/10 15:03 did gyre and gimble:
At Fri, 22 Oct 2010 13:31:53 +0200, Clemens Ladisch wrote:
Jiri Slaby wrote:
On 10/21/2010 10:05 AM, Takashi Iwai wrote:
commit de8c85f7840e5e29629de95f5af24297fb325e0b ALSA: HDA: Sigmatel: work around incorrect master muting
Reverting this one helps.
This one introduced even more wrong volume information on some codecs. Pleasy try this patch on top:
Argh! There is always a reason why we should define a constant. I applied the fix now.
This explains why the old patch worked on Colin's machine. His codec chip is different (STAC9200?), and it doesn't go in this code path but has a static Master volume creation.
Yup I have a STAC9200 so that explains it... silly me as I did see this line and figured "the value will be right" rather than questioning it.
Anyway, glad this has been found and there is now (presumably) no need for a revert :)
Col
On Thu, 21 Oct 2010 09:57:16 +0200, Jiri Slaby said:
On 10/21/2010 09:49 AM, Takashi Iwai wrote:
At Thu, 21 Oct 2010 09:41:08 +0200, Jiri Slaby wrote:
alsa-info: http://www.alsa-project.org/db/?f=a7a09703bcc8c43386c87a984e513ce35fc91ca4
I see the Front volume is set to zero. Try to raise it.
I set all the values to ~ 70 and then tried with pure alsa. It basically works.
BUT, when I run pulse and it suspends the device (or whatever), all the levels get down to 0 back again. When I raise it and run mplayer, it gets to 0 immediately. If I raise it gets to 0 when mplayer finishes and pulse writes 'protocol-native.c: Connection died.'. It never raises automatically. And if I raise it during playback, nothing plays at all.
Seeing the same thing on a Dell Latitude E6500, so Jiri isn't hallucinating.
Didn't we have some flustercluck a while back that gave pulseaudio similar indigestion? Oh, here it is, it was an fsnotify botch, of all things.
commit 2069601b3f0ea38170d4b509b89f3ca0a373bdc1 Author: Linus Torvalds torvalds@linux-foundation.org Date: Thu Aug 12 14:23:04 2010 -0700
Revert "fsnotify: store struct file not struct path"
This reverts commit 3bcf3860a4ff9bbc522820b4b765e65e4deceb3e (and the accompanying commit c1e5c954020e "vfs/fsnotify: fsnotify_close can delay the final work in fput" that was a horribly ugly hack to make it work at all).
Did we manage to revert the revert, or re-break this code? I haven't looked at this at all in detail.
On 10/21/2010 05:22 PM, Valdis.Kletnieks@vt.edu wrote:
Didn't we have some flustercluck a while back that gave pulseaudio similar indigestion? Oh, here it is, it was an fsnotify botch, of all things.
commit 2069601b3f0ea38170d4b509b89f3ca0a373bdc1 Author: Linus Torvalds torvalds@linux-foundation.org Date: Thu Aug 12 14:23:04 2010 -0700
Revert "fsnotify: store struct file not struct path"
Yes, I was attacked by that in the past, but I doubt that's it now. Pulse was unable to start -- the second open of the snd device failed which doesn't seem to happen now.
Going to switch hda intel from Y to M and play with that (revert the patches at first).
regards,
participants (5)
-
Clemens Ladisch -
Colin Guthrie -
Jiri Slaby -
Takashi Iwai -
Valdis.Kletnieks＠vt.edu