HDA: no sound [was: mmotm 2010-10-20-15-01 uploaded]

HDA: no sound [was: mmotm 2010-10-20-15-01 uploaded]

[Jiri Slaby]

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

Re: HDA: no sound [was: mmotm 2010-10-20-15-01 uploaded]

[Takashi Iwai]

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

Re: HDA: no sound [was: mmotm 2010-10-20-15-01 uploaded]

[Jiri Slaby]

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

Re: HDA: no sound [was: mmotm 2010-10-20-15-01 uploaded]

[Takashi Iwai]

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

Re: HDA: no sound [was: mmotm 2010-10-20-15-01 uploaded]

[Jiri Slaby]

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

Re: HDA: no sound [was: mmotm 2010-10-20-15-01 uploaded]

[Takashi Iwai]

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

Re: HDA: no sound [was: mmotm 2010-10-20-15-01 uploaded]

[Jiri Slaby]

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

-- 
js

Re: HDA: no sound [was: mmotm 2010-10-20-15-01 uploaded]

[Takashi Iwai]

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

Re: HDA: no sound [was: mmotm 2010-10-20-15-01 uploaded]

[Takashi Iwai]

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

Re: HDA: no sound [was: mmotm 2010-10-20-15-01 uploaded]

[Valdis.Kletnieks]

[-- Attachment #1.1: Type: text/plain, Size: 1754 bytes --]

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?



[-- Attachment #1.2: Type: application/pgp-signature, Size: 227 bytes --]

[-- Attachment #2: Type: text/plain, Size: 160 bytes --]

_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: HDA: no sound [was: mmotm 2010-10-20-15-01 uploaded]

[Takashi Iwai]

[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 {

Re: HDA: no sound [was: mmotm 2010-10-20-15-01 uploaded]

[Valdis.Kletnieks]

[-- Attachment #1.1: Type: text/plain, Size: 780 bytes --]

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


[-- Attachment #1.2: Type: application/pgp-signature, Size: 227 bytes --]

[-- Attachment #2: Type: text/plain, Size: 160 bytes --]

_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: HDA: no sound [was: mmotm 2010-10-20-15-01 uploaded]

[Takashi Iwai]

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

Re: HDA: no sound [was: mmotm 2010-10-20-15-01 uploaded]

[Jiri Slaby]

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

Re: HDA: no sound [was: mmotm 2010-10-20-15-01 uploaded]

[Colin Guthrie]

'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


-- 

Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/

Day Job:
  Tribalogic Limited [http://www.tribalogic.net/]
Open Source:
  Mageia Contributor [http://www.mageia.org/]
  PulseAudio Hacker [http://www.pulseaudio.org/]
  Trac Hacker [http://trac.edgewall.org/]

Re: HDA: no sound [was: mmotm 2010-10-20-15-01 uploaded]

[Takashi Iwai]

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

Re: HDA: no sound [was: mmotm 2010-10-20-15-01 uploaded]

[Jiri Slaby]

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

Re: HDA: no sound [was: mmotm 2010-10-20-15-01 uploaded]

[Takashi Iwai]

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

Re: HDA: no sound [was: mmotm 2010-10-20-15-01 uploaded]

[Jiri Slaby]

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

Re: HDA: no sound [was: mmotm 2010-10-20-15-01 uploaded]

[Takashi Iwai]

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

Re: HDA: no sound [was: mmotm 2010-10-20-15-01 uploaded]

[Jiri Slaby]

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

Re: HDA: no sound [was: mmotm 2010-10-20-15-01 uploaded]

[Colin Guthrie]

'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


-- 

Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/

Day Job:
  Tribalogic Limited [http://www.tribalogic.net/]
Open Source:
  Mageia Contributor [http://www.mageia.org/]
  PulseAudio Hacker [http://www.pulseaudio.org/]
  Trac Hacker [http://trac.edgewall.org/]

Re: HDA: no sound [was: mmotm 2010-10-20-15-01 uploaded]

[Clemens Ladisch]

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)

Re: HDA: no sound [was: mmotm 2010-10-20-15-01 uploaded]

[Jiri Slaby]

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;
>  		err = snd_hda_add_vmaster(codec, "Master Playback Volume",
>  					  vmaster_tlv, slave_vols);
>  		if (err < 0)
> 

thanks,
-- 
js

Re: HDA: no sound [was: mmotm 2010-10-20-15-01 uploaded]

[Takashi Iwai]

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;
>  		err = snd_hda_add_vmaster(codec, "Master Playback Volume",
>  					  vmaster_tlv, slave_vols);
>  		if (err < 0)
> 

Re: HDA: no sound [was: mmotm 2010-10-20-15-01 uploaded]

[Colin Guthrie]

'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

-- 

Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/

Day Job:
  Tribalogic Limited [http://www.tribalogic.net/]
Open Source:
  Mageia Contributor [http://www.mageia.org/]
  PulseAudio Hacker [http://www.pulseaudio.org/]
  Trac Hacker [http://trac.edgewall.org/]

Re: HDA: no sound [was: mmotm 2010-10-20-15-01 uploaded]

[Valdis.Kletnieks]

[-- Attachment #1.1: Type: text/plain, Size: 1550 bytes --]

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.

[-- Attachment #1.2: Type: application/pgp-signature, Size: 227 bytes --]

[-- Attachment #2: Type: text/plain, Size: 160 bytes --]

_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: HDA: no sound [was: mmotm 2010-10-20-15-01 uploaded]

[Jiri Slaby]

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