[alsa-devel] 1.0.15: volume levels drift on HDA with STAC92XX codec
We have two reports now of unstable volume levels:
https://bugzilla.redhat.com/show_bug.cgi?id=361051 https://bugzilla.redhat.com/show_bug.cgi?id=354981
This is with kernel 2.6.23 plus the two ALSA merge patches from 2.6.23-rc1.
On Thursday 01 November 2007 19:47:39 Chuck Ebbert wrote:
We have two reports now of unstable volume levels:
https://bugzilla.redhat.com/show_bug.cgi?id=361051 https://bugzilla.redhat.com/show_bug.cgi?id=354981
This is with kernel 2.6.23 plus the two ALSA merge patches from 2.6.23-rc1. _______________________________________________ Alsa-devel mailing list Alsa-devel@alsa-project.org http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
Probably this isn't a software bug. Probably this chip country to datasheet doesn't have usable "Master Volume" (volume knob) control.
The master volume control wasn't present before, I added support for it, using data-sheets. I need to know what exactly sigmatel codec was used in both cases.
Best regards, Maxim Levitsky
At Thu, 1 Nov 2007 20:17:30 +0200, Maxim Levitsky wrote:
On Thursday 01 November 2007 19:47:39 Chuck Ebbert wrote:
We have two reports now of unstable volume levels:
https://bugzilla.redhat.com/show_bug.cgi?id=361051 https://bugzilla.redhat.com/show_bug.cgi?id=354981
This is with kernel 2.6.23 plus the two ALSA merge patches from 2.6.23-rc1. _______________________________________________ Alsa-devel mailing list Alsa-devel@alsa-project.org http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
Probably this isn't a software bug. Probably this chip country to datasheet doesn't have usable "Master Volume" (volume knob) control.
The master volume control wasn't present before, I added support for it, using data-sheets. I need to know what exactly sigmatel codec was used in both cases.
Yes, the latter case seems with STAC9205 but the former one (361051) isn't clear. Please check /proc/asound/card0/codec#* entries.
thanks,
Takashi
On Monday 05 November 2007 13:40:48 Takashi Iwai wrote:
At Thu, 1 Nov 2007 20:17:30 +0200, Maxim Levitsky wrote:
On Thursday 01 November 2007 19:47:39 Chuck Ebbert wrote:
We have two reports now of unstable volume levels:
https://bugzilla.redhat.com/show_bug.cgi?id=361051 https://bugzilla.redhat.com/show_bug.cgi?id=354981
This is with kernel 2.6.23 plus the two ALSA merge patches from 2.6.23-rc1. _______________________________________________ Alsa-devel mailing list Alsa-devel@alsa-project.org http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
Probably this isn't a software bug. Probably this chip country to datasheet doesn't have usable "Master Volume" (volume knob) control.
The master volume control wasn't present before, I added support for it, using data-sheets. I need to know what exactly sigmatel codec was used in both cases.
Yes, the latter case seems with STAC9205 but the former one (361051) isn't clear. Please check /proc/asound/card0/codec#* entries.
thanks,
Takashi
The former is also STAC9205/04/ since it is the only one with analog loopback and two ADCs
I have question, I talked with the reporter of 354981, and I don't know why but his amixer gives very strange results:
[root@itse68482 ~]# cat amixer-contents-kernel-2.6.23.2-36 numid=0,iface=MIXER,name='Master Playback Switch' ; type=BOOLEAN,access=rw------,values=1 : values=on numid=0,iface=MIXER,name='Master Playback Volume' ; type=INTEGER,access=rw------,values=2,min=0,max=65536,step=1 : values=65536,65536 numid=0,iface=MIXER,name='Capture Switch' ; type=BOOLEAN,access=rw------,values=1 : values=on numid=0,iface=MIXER,name='Capture Volume' ; type=INTEGER,access=rw------,values=2,min=0,max=65536,step=1 : values=34953,34953
How can that be?
According to his lspci, he doesn't have a second sound card.
Any ideas?
Besides that it seems that VolumeKnob is physically broken on STAC9205s, Can anybody here with STAC9205/STAC9204/STAC9254/STAC9255 test it?
And last question, about STAC9254/STAC9255 There is no datasheet for that chip on the web, is this just STAC9205 + modem?
Best regards, Maxim Levitsky
At Mon, 5 Nov 2007 16:53:23 +0200, Maxim Levitsky wrote:
On Monday 05 November 2007 13:40:48 Takashi Iwai wrote:
At Thu, 1 Nov 2007 20:17:30 +0200, Maxim Levitsky wrote:
On Thursday 01 November 2007 19:47:39 Chuck Ebbert wrote:
We have two reports now of unstable volume levels:
https://bugzilla.redhat.com/show_bug.cgi?id=361051 https://bugzilla.redhat.com/show_bug.cgi?id=354981
This is with kernel 2.6.23 plus the two ALSA merge patches from 2.6.23-rc1. _______________________________________________ Alsa-devel mailing list Alsa-devel@alsa-project.org http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
Probably this isn't a software bug. Probably this chip country to datasheet doesn't have usable "Master Volume" (volume knob) control.
The master volume control wasn't present before, I added support for it, using data-sheets. I need to know what exactly sigmatel codec was used in both cases.
Yes, the latter case seems with STAC9205 but the former one (361051) isn't clear. Please check /proc/asound/card0/codec#* entries.
thanks,
Takashi
The former is also STAC9205/04/ since it is the only one with analog loopback and two ADCs
I have question, I talked with the reporter of 354981, and I don't know why but his amixer gives very strange results:
[root@itse68482 ~]# cat amixer-contents-kernel-2.6.23.2-36 numid=0,iface=MIXER,name='Master Playback Switch' ; type=BOOLEAN,access=rw------,values=1 : values=on numid=0,iface=MIXER,name='Master Playback Volume' ; type=INTEGER,access=rw------,values=2,min=0,max=65536,step=1 : values=65536,65536 numid=0,iface=MIXER,name='Capture Switch' ; type=BOOLEAN,access=rw------,values=1 : values=on numid=0,iface=MIXER,name='Capture Volume' ; type=INTEGER,access=rw------,values=2,min=0,max=65536,step=1 : values=34953,34953
How can that be?
Is the codec accessed properly? This looks like the error at reading amp capability of these NIDS and returned -1. The volume attributes are extracted from the amp caps. But if so, usually relevant kernel messages appear...
Takashi
On Monday 05 November 2007 14:09:30 Takashi Iwai wrote:
At Mon, 5 Nov 2007 16:53:23 +0200, Maxim Levitsky wrote:
On Monday 05 November 2007 13:40:48 Takashi Iwai wrote:
At Thu, 1 Nov 2007 20:17:30 +0200, Maxim Levitsky wrote:
On Thursday 01 November 2007 19:47:39 Chuck Ebbert wrote:
We have two reports now of unstable volume levels:
https://bugzilla.redhat.com/show_bug.cgi?id=361051 https://bugzilla.redhat.com/show_bug.cgi?id=354981
This is with kernel 2.6.23 plus the two ALSA merge patches from 2.6.23-rc1. _______________________________________________ Alsa-devel mailing list Alsa-devel@alsa-project.org http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
Probably this isn't a software bug. Probably this chip country to datasheet doesn't have usable "Master Volume" (volume knob) control.
The master volume control wasn't present before, I added support for it, using data-sheets. I need to know what exactly sigmatel codec was used in both cases.
Yes, the latter case seems with STAC9205 but the former one (361051) isn't clear. Please check /proc/asound/card0/codec#* entries.
thanks,
Takashi
The former is also STAC9205/04/ since it is the only one with analog loopback and two ADCs
I have question, I talked with the reporter of 354981, and I don't know why but his amixer gives very strange results:
[root@itse68482 ~]# cat amixer-contents-kernel-2.6.23.2-36 numid=0,iface=MIXER,name='Master Playback Switch' ; type=BOOLEAN,access=rw------,values=1 : values=on numid=0,iface=MIXER,name='Master Playback Volume' ; type=INTEGER,access=rw------,values=2,min=0,max=65536,step=1 : values=65536,65536 numid=0,iface=MIXER,name='Capture Switch' ; type=BOOLEAN,access=rw------,values=1 : values=on numid=0,iface=MIXER,name='Capture Volume' ; type=INTEGER,access=rw------,values=2,min=0,max=65536,step=1 : values=34953,34953
How can that be?
Is the codec accessed properly? This looks like the error at reading amp capability of these NIDS and returned -1. The volume attributes are extracted from the amp caps. But if so, usually relevant kernel messages appear...
Takashi
Probably,
only this one: hda_intel: azx_get_response timeout, switching to polling mode: last cmd=0x00bf1c00
But he told me that he has both 'Master' and 'Front' in gnome-volume-control but there are no signs of 'Front' in amixer.
Espen Stefansen, can you send the dmesg after you run the amixer. Do you have by chance a second sound card plugged when you have the amixer run? Can you run alsamixer, and tell me what controls you see there on both 'Playback' and 'Capture' tabs: (Press 'Tab' to switch between 'Playback' and 'Capture' controls.
Best regards, Maxim Levitsky
At Mon, 5 Nov 2007 17:32:32 +0200, Maxim Levitsky wrote:
On Monday 05 November 2007 14:09:30 Takashi Iwai wrote:
At Mon, 5 Nov 2007 16:53:23 +0200, Maxim Levitsky wrote:
On Monday 05 November 2007 13:40:48 Takashi Iwai wrote:
At Thu, 1 Nov 2007 20:17:30 +0200, Maxim Levitsky wrote:
On Thursday 01 November 2007 19:47:39 Chuck Ebbert wrote:
We have two reports now of unstable volume levels:
https://bugzilla.redhat.com/show_bug.cgi?id=361051 https://bugzilla.redhat.com/show_bug.cgi?id=354981
This is with kernel 2.6.23 plus the two ALSA merge patches from 2.6.23-rc1. _______________________________________________ Alsa-devel mailing list Alsa-devel@alsa-project.org http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
Probably this isn't a software bug. Probably this chip country to datasheet doesn't have usable "Master Volume" (volume knob) control.
The master volume control wasn't present before, I added support for it, using data-sheets. I need to know what exactly sigmatel codec was used in both cases.
Yes, the latter case seems with STAC9205 but the former one (361051) isn't clear. Please check /proc/asound/card0/codec#* entries.
thanks,
Takashi
The former is also STAC9205/04/ since it is the only one with analog loopback and two ADCs
I have question, I talked with the reporter of 354981, and I don't know why but his amixer gives very strange results:
[root@itse68482 ~]# cat amixer-contents-kernel-2.6.23.2-36 numid=0,iface=MIXER,name='Master Playback Switch' ; type=BOOLEAN,access=rw------,values=1 : values=on numid=0,iface=MIXER,name='Master Playback Volume' ; type=INTEGER,access=rw------,values=2,min=0,max=65536,step=1 : values=65536,65536 numid=0,iface=MIXER,name='Capture Switch' ; type=BOOLEAN,access=rw------,values=1 : values=on numid=0,iface=MIXER,name='Capture Volume' ; type=INTEGER,access=rw------,values=2,min=0,max=65536,step=1 : values=34953,34953
How can that be?
Is the codec accessed properly? This looks like the error at reading amp capability of these NIDS and returned -1. The volume attributes are extracted from the amp caps. But if so, usually relevant kernel messages appear...
Takashi
Probably,
only this one: hda_intel: azx_get_response timeout, switching to polling mode: last cmd=0x00bf1c00
But he told me that he has both 'Master' and 'Front' in gnome-volume-control but there are no signs of 'Front' in amixer.
You'd have better (raw) representation via "alsactl -f somefile store" than amixer. amixer does some abstraction and confuses sometimes :)
Takashi
On Monday 05 November 2007 13:40:48 Takashi Iwai wrote:
At Thu, 1 Nov 2007 20:17:30 +0200, Maxim Levitsky wrote:
On Thursday 01 November 2007 19:47:39 Chuck Ebbert wrote:
We have two reports now of unstable volume levels:
https://bugzilla.redhat.com/show_bug.cgi?id=361051 https://bugzilla.redhat.com/show_bug.cgi?id=354981
This is with kernel 2.6.23 plus the two ALSA merge patches from 2.6.23-rc1. _______________________________________________ Alsa-devel mailing list Alsa-devel@alsa-project.org http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
Probably this isn't a software bug. Probably this chip country to datasheet doesn't have usable
"Master
Volume" (volume knob) control.
The master volume control wasn't present before, I added support
for
it, using data-sheets. I need to know what exactly sigmatel codec was used in both cases.
Yes, the latter case seems with STAC9205 but the former one (361051) isn't clear. Please check /proc/asound/card0/codec#* entries.
thanks,
Takashi
The former is also STAC9205/04/ since it is the only one with analog loopback and two ADCs
I have question, I talked with the reporter of 354981, and I don't
know
why but his amixer gives very strange results:
[root@itse68482 ~]# cat amixer-contents-kernel-2.6.23.2-36 numid=0,iface=MIXER,name='Master Playback Switch' ; type=BOOLEAN,access=rw------,values=1 : values=on numid=0,iface=MIXER,name='Master Playback Volume' ; type=INTEGER,access=rw------,values=2,min=0,max=65536,step=1 : values=65536,65536 numid=0,iface=MIXER,name='Capture Switch' ; type=BOOLEAN,access=rw------,values=1 : values=on numid=0,iface=MIXER,name='Capture Volume' ; type=INTEGER,access=rw------,values=2,min=0,max=65536,step=1 : values=34953,34953
How can that be?
According to his lspci, he doesn't have a second sound card.
Any ideas?
Besides that it seems that VolumeKnob is physically broken on
STAC9205s,
Can anybody here with STAC9205/STAC9204/STAC9254/STAC9255 test it?
And last question, about STAC9254/STAC9255 There is no datasheet for that chip on the web, is this just STAC9205
+
modem?
Best regards, Maxim Levitsky _______________________________________________ Alsa-devel mailing list Alsa-devel@alsa-project.org http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
[Tellman, Steven]
The STAC9254/55 lines are not available anymore. Yes, they were basically 9204/5 + Modem.
- Steven
On Monday 05 November 2007 18:39:39 Tellman, Steven wrote:
On Monday 05 November 2007 13:40:48 Takashi Iwai wrote:
At Thu, 1 Nov 2007 20:17:30 +0200, Maxim Levitsky wrote:
On Thursday 01 November 2007 19:47:39 Chuck Ebbert wrote:
We have two reports now of unstable volume levels:
https://bugzilla.redhat.com/show_bug.cgi?id=361051 https://bugzilla.redhat.com/show_bug.cgi?id=354981
This is with kernel 2.6.23 plus the two ALSA merge patches from 2.6.23-rc1. _______________________________________________ Alsa-devel mailing list Alsa-devel@alsa-project.org http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
Probably this isn't a software bug. Probably this chip country to datasheet doesn't have usable
"Master
Volume" (volume knob) control.
The master volume control wasn't present before, I added support
for
it, using data-sheets. I need to know what exactly sigmatel codec was used in both cases.
Yes, the latter case seems with STAC9205 but the former one (361051) isn't clear. Please check /proc/asound/card0/codec#* entries.
thanks,
Takashi
The former is also STAC9205/04/ since it is the only one with analog loopback and two ADCs
I have question, I talked with the reporter of 354981, and I don't
know
why but his amixer gives very strange results:
[root@itse68482 ~]# cat amixer-contents-kernel-2.6.23.2-36 numid=0,iface=MIXER,name='Master Playback Switch' ; type=BOOLEAN,access=rw------,values=1 : values=on numid=0,iface=MIXER,name='Master Playback Volume' ; type=INTEGER,access=rw------,values=2,min=0,max=65536,step=1 : values=65536,65536 numid=0,iface=MIXER,name='Capture Switch' ; type=BOOLEAN,access=rw------,values=1 : values=on numid=0,iface=MIXER,name='Capture Volume' ; type=INTEGER,access=rw------,values=2,min=0,max=65536,step=1 : values=34953,34953
How can that be?
According to his lspci, he doesn't have a second sound card.
Any ideas?
Besides that it seems that VolumeKnob is physically broken on
STAC9205s,
Can anybody here with STAC9205/STAC9204/STAC9254/STAC9255 test it?
And last question, about STAC9254/STAC9255 There is no datasheet for that chip on the web, is this just STAC9205
modem?
Best regards, Maxim Levitsky _______________________________________________ Alsa-devel mailing list Alsa-devel@alsa-project.org http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
[Tellman, Steven]
The STAC9254/55 lines are not available anymore. Yes, they were basically 9204/5 + Modem.
- Steven
Hi,
Thanks a lot,
Just one more question, are data-sheets for STAC9872 aviable? I don't even see a page describing those chips on IDT website. Furthermore, recently IDT sent a patch for STAC92HD71BXX, thus I want to ask whenever datasheets for it will be available.
Best regards, Maxim Levitsky
-----Original Message----- From: Maxim Levitsky [mailto:maximlevitsky@gmail.com] Sent: Monday, November 05, 2007 11:09 AM To: Tellman, Steven Cc: Takashi Iwai; alsa-devel@alsa-project.org; Chuck Ebbert; mranostay@embeddedalley.com Subject: Re: [alsa-devel] 1.0.15: volume levels drift on HDA with STAC92XXcodec
On Monday 05 November 2007 18:39:39 Tellman, Steven wrote:
On Monday 05 November 2007 13:40:48 Takashi Iwai wrote:
At Thu, 1 Nov 2007 20:17:30 +0200, Maxim Levitsky wrote:
On Thursday 01 November 2007 19:47:39 Chuck Ebbert wrote:
We have two reports now of unstable volume levels:
https://bugzilla.redhat.com/show_bug.cgi?id=361051 https://bugzilla.redhat.com/show_bug.cgi?id=354981
This is with kernel 2.6.23 plus the two ALSA merge patches
from
2.6.23-rc1. _______________________________________________ Alsa-devel mailing list Alsa-devel@alsa-project.org http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
Probably this isn't a software bug. Probably this chip country to datasheet doesn't have usable
"Master
Volume" (volume knob) control.
The master volume control wasn't present before, I added
support
for
it, using data-sheets. I need to know what exactly sigmatel codec was used in both
cases.
Yes, the latter case seems with STAC9205 but the former one
(361051)
isn't clear. Please check /proc/asound/card0/codec#* entries.
thanks,
Takashi
The former is also STAC9205/04/ since it is the only one with
analog
loopback and two ADCs
I have question, I talked with the reporter of 354981, and I don't
know
why but his amixer gives very strange results:
[root@itse68482 ~]# cat amixer-contents-kernel-2.6.23.2-36 numid=0,iface=MIXER,name='Master Playback Switch' ; type=BOOLEAN,access=rw------,values=1 : values=on numid=0,iface=MIXER,name='Master Playback Volume' ; type=INTEGER,access=rw------,values=2,min=0,max=65536,step=1 : values=65536,65536 numid=0,iface=MIXER,name='Capture Switch' ; type=BOOLEAN,access=rw------,values=1 : values=on numid=0,iface=MIXER,name='Capture Volume' ; type=INTEGER,access=rw------,values=2,min=0,max=65536,step=1 : values=34953,34953
How can that be?
According to his lspci, he doesn't have a second sound card.
Any ideas?
Besides that it seems that VolumeKnob is physically broken on
STAC9205s,
Can anybody here with STAC9205/STAC9204/STAC9254/STAC9255 test it?
And last question, about STAC9254/STAC9255 There is no datasheet for that chip on the web, is this just
STAC9205
modem?
Best regards, Maxim Levitsky _______________________________________________ Alsa-devel mailing list Alsa-devel@alsa-project.org http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
[Tellman, Steven]
The STAC9254/55 lines are not available anymore. Yes, they were basically 9204/5 + Modem.
- Steven
Hi,
Thanks a lot,
Just one more question, are data-sheets for STAC9872 aviable? I don't even see a page describing those chips on IDT website.
No, datasheets are not available.
Furthermore, recently IDT sent a patch for STAC92HD71BXX, thus I want to ask whenever datasheets for it will be available.
Datasheets are available on IDT.com
http://www.idt.com/?catID=18442398
Best regards, Maxim Levitsky
On Monday 05 November 2007 19:33:44 Tellman, Steven wrote:
-----Original Message-----
...
Hi,
Thanks a lot,
Just one more question, are data-sheets for STAC9872 aviable? I don't even see a page describing those chips on IDT website.
No, datasheets are not available.
Furthermore, recently IDT sent a patch for STAC92HD71BXX, thus I want to ask whenever datasheets for it will be available.
Datasheets are available on IDT.com
I assumed that IDT will no longer publish the datasheets, But now it looks like this isn't true. Big thanks!
I assume that STAC9872 is some sort of OEM version for Sony Vaio laptops, is this true? Are those simular to other STACs? (like in 9254/55 case)
Best regards, Maxim Levitsky
-----Original Message----- From: Maxim Levitsky [mailto:maximlevitsky@gmail.com] Sent: Monday, November 05, 2007 12:59 PM To: Tellman, Steven Cc: Takashi Iwai; alsa-devel@alsa-project.org; Chuck Ebbert; mranostay@embeddedalley.com Subject: Re: [alsa-devel] 1.0.15: volume levels drift on HDA with STAC92XXcodec
On Monday 05 November 2007 19:33:44 Tellman, Steven wrote:
-----Original Message-----
....
Hi,
Thanks a lot,
Just one more question, are data-sheets for STAC9872 aviable? I don't even see a page describing those chips on IDT website.
No, datasheets are not available.
Furthermore, recently IDT sent a patch for STAC92HD71BXX, thus I want to ask whenever datasheets for it will be available.
Datasheets are available on IDT.com
I assumed that IDT will no longer publish the datasheets, But now it looks like this isn't true. Big thanks!
I assume that STAC9872 is some sort of OEM version for Sony Vaio
laptops,
is this true? Are those simular to other STACs? (like in 9254/55 case)
Sorry, I cannot comment on that part.
Best regards, Maxim Levitsky
At Thu, 1 Nov 2007 20:17:30 +0200, Maxim Levitsky wrote:
On Thursday 01 November 2007 19:47:39 Chuck Ebbert wrote:
We have two reports now of unstable volume levels:
https://bugzilla.redhat.com/show_bug.cgi?id=361051 https://bugzilla.redhat.com/show_bug.cgi?id=354981
This is with kernel 2.6.23 plus the two ALSA merge patches from 2.6.23-rc1. _______________________________________________ Alsa-devel mailing list Alsa-devel@alsa-project.org http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
Probably this isn't a software bug. Probably this chip country to datasheet doesn't have usable "Master Volume" (volume knob) control.
I got a bug report that the same symptom appears also with STAC9221. http://bugzilla.kernel.org/show_bug.cgi?id=9374
Maybe we need add whitelist / blacklist for this feature?
On which codec/machine is this feature confirmed to work?
thanks,
Takashi
On Friday 16 November 2007 17:02, Takashi Iwai wrote:
At Thu, 1 Nov 2007 20:17:30 +0200,
Maxim Levitsky wrote:
On Thursday 01 November 2007 19:47:39 Chuck Ebbert wrote:
We have two reports now of unstable volume levels:
https://bugzilla.redhat.com/show_bug.cgi?id=361051 https://bugzilla.redhat.com/show_bug.cgi?id=354981
This is with kernel 2.6.23 plus the two ALSA merge patches from 2.6.23-rc1. _______________________________________________ Alsa-devel mailing list Alsa-devel@alsa-project.org http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
Probably this isn't a software bug. Probably this chip country to datasheet doesn't have usable "Master Volume" (volume knob) control.
I got a bug report that the same symptom appears also with STAC9221.
http://bugzilla.kernel.org/show_bug.cgi?id=9374
Maybe we need add whitelist / blacklist for this feature?
On which codec/machine is this feature confirmed to work?
thanks,
Takashi
Hi,
Yes, it seems that volume knob has troubles.
I have it with STAC9227. Obivosly it works
I know a user that first complained about some problems, but then he found that everything works ok, probably including the volknob.
He has STAC9274, and we had a long disscussion about new features I intruduced, He said that everything is OK. I ask him explictly about that.
Now remember the report about conflict between my 'Master Volume' and already existing one?
This was a STAC922x, and the autor said that now his mulimedia keys can again control the volume (Probably this indicates that volumekknob is working)
Thus we have 4 groups of STACS:
1 - STAC9250 - lot of troubles - (I would be very happpy to hear from anybody here that has it)
2- STAC9221/2 - I thought that it works, but not anymore 3- STAC9227/8/9 - I have it, so I hope that it works 4- STAC927x - very simular to above, and one user that tells that it works.
I suggest to wait a bit more to see the scale of this bug (After all it isn't that big bug, it is just a feature :-) that isn't working)
The datasheets mention briefly that an external volume control can be connected to the chip. Maybe it affects the volumeknob. If this is the case, then probably we ether need to detect it, or drop the whole thing. (Those external pins probably are just connected to the groung or somethibg like that so no real external volumeknob is present, but they still mess the internal VolumeKnob)
Blacklist can help, but it is probably too much for that feature, since the VolumeKnob doesn't add anything very special, and can be emulated with SoftVol plugin, like it is done now.
There are several solutions:
1) Rename it to say 'VolumeKnob", so the users that have it broken won't notice , but still driver will expose all controls of hardware. 2) Make a module param that will enable/disable it 3) Remove it completly, OK, but probably the #1 is better
All depends on whenever this is a specific stac model bug Like I thought STAC9205, or this is the 'external volume' problem.
If this is just STAC9205 and STAC9221 then we can make a module param, and make it enabled by default for STAC9227/8/9 STAC927x, but make it disabled for STAC9205 and STAC9221
If not, then it is better to remove it/remame to VolumeKnob
Best regards, Maxim Levitsky
On 11/16/2007 10:50 AM, Maxim Levitsky wrote:
On Friday 16 November 2007 17:02, Takashi Iwai wrote:
At Thu, 1 Nov 2007 20:17:30 +0200,
Maxim Levitsky wrote:
On Thursday 01 November 2007 19:47:39 Chuck Ebbert wrote:
We have two reports now of unstable volume levels:
https://bugzilla.redhat.com/show_bug.cgi?id=361051 https://bugzilla.redhat.com/show_bug.cgi?id=354981
This is with kernel 2.6.23 plus the two ALSA merge patches from 2.6.23-rc1. _______________________________________________ Alsa-devel mailing list Alsa-devel@alsa-project.org http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
Probably this isn't a software bug. Probably this chip country to datasheet doesn't have usable "Master Volume" (volume knob) control.
I got a bug report that the same symptom appears also with STAC9221.
http://bugzilla.kernel.org/show_bug.cgi?id=9374
Maybe we need add whitelist / blacklist for this feature?
On which codec/machine is this feature confirmed to work?
thanks,
Takashi
Hi,
Yes, it seems that volume knob has troubles.
I have it with STAC9227. Obivosly it works
I know a user that first complained about some problems, but then he found that everything works ok, probably including the volknob.
He has STAC9274, and we had a long disscussion about new features I intruduced, He said that everything is OK. I ask him explictly about that.
Now remember the report about conflict between my 'Master Volume' and already existing one?
This was a STAC922x, and the autor said that now his mulimedia keys can again control the volume (Probably this indicates that volumekknob is working)
Thus we have 4 groups of STACS:
1 - STAC9250 - lot of troubles - (I would be very happpy to hear from anybody here that has it)
2- STAC9221/2 - I thought that it works, but not anymore 3- STAC9227/8/9 - I have it, so I hope that it works 4- STAC927x - very simular to above, and one user that tells that it works.
I suggest to wait a bit more to see the scale of this bug (After all it isn't that big bug, it is just a feature :-) that isn't working)
The datasheets mention briefly that an external volume control can be connected to the chip. Maybe it affects the volumeknob. If this is the case, then probably we ether need to detect it, or drop the whole thing. (Those external pins probably are just connected to the groung or somethibg like that so no real external volumeknob is present, but they still mess the internal VolumeKnob)
Blacklist can help, but it is probably too much for that feature, since the VolumeKnob doesn't add anything very special, and can be emulated with SoftVol plugin, like it is done now.
There are several solutions:
- Rename it to say 'VolumeKnob", so the users that have it broken won't
notice , but still driver will expose all controls of hardware. 2) Make a module param that will enable/disable it 3) Remove it completly, OK, but probably the #1 is better
All depends on whenever this is a specific stac model bug Like I thought STAC9205, or this is the 'external volume' problem.
If this is just STAC9205 and STAC9221 then we can make a module param, and make it enabled by default for STAC9227/8/9 STAC927x, but make it disabled for STAC9205 and STAC9221
If not, then it is better to remove it/remame to VolumeKnob
I reverted the change in Fedora 8 and it fixed things:
http://cvs.fedora.redhat.com/viewcvs/*checkout*/rpms/kernel/F-8/linux-2.6-al...
At Fri, 16 Nov 2007 17:50:09 +0200, Maxim Levitsky wrote:
On Friday 16 November 2007 17:02, Takashi Iwai wrote:
At Thu, 1 Nov 2007 20:17:30 +0200,
Maxim Levitsky wrote:
On Thursday 01 November 2007 19:47:39 Chuck Ebbert wrote:
We have two reports now of unstable volume levels:
https://bugzilla.redhat.com/show_bug.cgi?id=361051 https://bugzilla.redhat.com/show_bug.cgi?id=354981
This is with kernel 2.6.23 plus the two ALSA merge patches from 2.6.23-rc1. _______________________________________________ Alsa-devel mailing list Alsa-devel@alsa-project.org http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
Probably this isn't a software bug. Probably this chip country to datasheet doesn't have usable "Master Volume" (volume knob) control.
I got a bug report that the same symptom appears also with STAC9221.
http://bugzilla.kernel.org/show_bug.cgi?id=9374
Maybe we need add whitelist / blacklist for this feature?
On which codec/machine is this feature confirmed to work?
thanks,
Takashi
Hi,
Yes, it seems that volume knob has troubles.
I have it with STAC9227. Obivosly it works
I know a user that first complained about some problems, but then he found that everything works ok, probably including the volknob.
He has STAC9274, and we had a long disscussion about new features I intruduced, He said that everything is OK. I ask him explictly about that.
Now remember the report about conflict between my 'Master Volume' and already existing one?
This was a STAC922x, and the autor said that now his mulimedia keys can again control the volume (Probably this indicates that volumekknob is working)
Thus we have 4 groups of STACS:
1 - STAC9250 - lot of troubles - (I would be very happpy to hear from anybody here that has it)
2- STAC9221/2 - I thought that it works, but not anymore 3- STAC9227/8/9 - I have it, so I hope that it works 4- STAC927x - very simular to above, and one user that tells that it works.
I suggest to wait a bit more to see the scale of this bug (After all it isn't that big bug, it is just a feature :-) that isn't working)
The datasheets mention briefly that an external volume control can be connected to the chip. Maybe it affects the volumeknob. If this is the case, then probably we ether need to detect it, or drop the whole thing. (Those external pins probably are just connected to the groung or somethibg like that so no real external volumeknob is present, but they still mess the internal VolumeKnob)
Blacklist can help, but it is probably too much for that feature, since the VolumeKnob doesn't add anything very special, and can be emulated with SoftVol plugin, like it is done now.
There are several solutions:
- Rename it to say 'VolumeKnob", so the users that have it broken won't
notice , but still driver will expose all controls of hardware.
But even a different name control may have a similar effect. After all, it's exposed as a mixer element, and the mixer app may choose it as well.
- Make a module param that will enable/disable it
I don't like to add a codec-specific module option, so far.
- Remove it completly, OK, but probably the #1 is better
I think the safest way at this moment is to revert that once. Then we'll have a stable state as on 2.6.23.
On my local tree, there is a patch to add a virtual "Master" control to bind all volume controls. It's a driver-side implementation (no softvol plugin). So, when this patch is merged, we'll have a master control for STAC, anyway.
All depends on whenever this is a specific stac model bug Like I thought STAC9205, or this is the 'external volume' problem.
Or, it might be the conflict (a kind of race) between the software vol knob change and the hardware vol knob change. If so, it can explain why one STAC9221 works and another STAC9221 doesn't.
If this is just STAC9205 and STAC9221 then we can make a module param, and make it enabled by default for STAC9227/8/9 STAC927x, but make it disabled for STAC9205 and STAC9221
I got a bug report (from Linus himself) that once the driver with 9227 didn't work during 2.6.24-rc1 update. And magically started again working during bisecting. I couldn't spot the culprit (the volknob value looked OK), but my suspect is the volknob, judging from the situation.
If not, then it is better to remove it/remame to VolumeKnob
Agreed. I'd like to take a safer way if you don't insist...
Takashi
On Saturday 17 November 2007 12:10, Takashi Iwai wrote:
At Fri, 16 Nov 2007 17:50:09 +0200,
Maxim Levitsky wrote:
On Friday 16 November 2007 17:02, Takashi Iwai wrote:
At Thu, 1 Nov 2007 20:17:30 +0200,
Maxim Levitsky wrote:
On Thursday 01 November 2007 19:47:39 Chuck Ebbert wrote:
We have two reports now of unstable volume levels:
https://bugzilla.redhat.com/show_bug.cgi?id=361051 https://bugzilla.redhat.com/show_bug.cgi?id=354981
This is with kernel 2.6.23 plus the two ALSA merge patches from 2.6.23-rc1. _______________________________________________ Alsa-devel mailing list Alsa-devel@alsa-project.org http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
Probably this isn't a software bug. Probably this chip country to datasheet doesn't have usable "Master Volume" (volume knob) control.
I got a bug report that the same symptom appears also with STAC9221.
http://bugzilla.kernel.org/show_bug.cgi?id=9374
Maybe we need add whitelist / blacklist for this feature?
On which codec/machine is this feature confirmed to work?
thanks,
Takashi
Hi,
Yes, it seems that volume knob has troubles.
I have it with STAC9227. Obivosly it works
I know a user that first complained about some problems, but then he found that everything works ok, probably including the volknob.
He has STAC9274, and we had a long disscussion about new features I intruduced, He said that everything is OK. I ask him explictly about that.
Now remember the report about conflict between my 'Master Volume' and already existing one?
This was a STAC922x, and the autor said that now his mulimedia keys can again control the volume (Probably this indicates that volumekknob is working)
Thus we have 4 groups of STACS:
1 - STAC9250 - lot of troubles - (I would be very happpy to hear from anybody here that has it)
2- STAC9221/2 - I thought that it works, but not anymore 3- STAC9227/8/9 - I have it, so I hope that it works 4- STAC927x - very simular to above, and one user that tells that it works.
I suggest to wait a bit more to see the scale of this bug (After all it isn't that big bug, it is just a feature :-) that isn't working)
The datasheets mention briefly that an external volume control can be connected to the chip. Maybe it affects the volumeknob. If this is the case, then probably we ether need to detect it, or drop the whole thing. (Those external pins probably are just connected to the groung or somethibg like that so no real external volumeknob is present, but they still mess the internal VolumeKnob)
Blacklist can help, but it is probably too much for that feature, since the VolumeKnob doesn't add anything very special, and can be emulated with SoftVol plugin, like it is done now.
There are several solutions:
- Rename it to say 'VolumeKnob", so the users that have it broken won't
notice , but still driver will expose all controls of hardware.
But even a different name control may have a similar effect. After all, it's exposed as a mixer element, and the mixer app may choose it as well.
- Make a module param that will enable/disable it
I don't like to add a codec-specific module option, so far.
- Remove it completly, OK, but probably the #1 is better
I think the safest way at this moment is to revert that once. Then we'll have a stable state as on 2.6.23.
On my local tree, there is a patch to add a virtual "Master" control to bind all volume controls. It's a driver-side implementation (no softvol plugin). So, when this patch is merged, we'll have a master control for STAC, anyway.
All depends on whenever this is a specific stac model bug Like I thought STAC9205, or this is the 'external volume' problem.
Or, it might be the conflict (a kind of race) between the software vol knob change and the hardware vol knob change. If so, it can explain why one STAC9221 works and another STAC9221 doesn't.
Thats exactly what I have said, but this is only a guess, I didn't see a statetment about that in datasheet.
If this is just STAC9205 and STAC9221 then we can make a module param, and make it enabled by default for STAC9227/8/9 STAC927x, but make it disabled for STAC9205 and STAC9221
I got a bug report (from Linus himself) that once the driver with 9227 didn't work during 2.6.24-rc1 update. And magically started again working during bisecting. I couldn't spot the culprit (the volknob value looked OK), but my suspect is the volknob, judging from the situation.
You mean it was connected to instable volume too? If that is true, and due to the fact that I have STAC9227, probably it is a conflict with hardware volume.
If not, then it is better to remove it/remame to VolumeKnob
Agreed. I'd like to take a safer way if you don't insist...
Great, it is probably the best to have a virtual master volume. Just one question, it will be probably enabled for devices that don't have a master volume (or have it broken like the STAC), right?, And when you expect it to be merged?
So I agree completly, revert it, and lets forget about that VolumeKnob. Sorry for the trouble :-)
Best regards, Maxim Levitsky
Takashi
At Sat, 17 Nov 2007 12:36:32 +0200, Maxim Levitsky wrote:
On Saturday 17 November 2007 12:10, Takashi Iwai wrote:
At Fri, 16 Nov 2007 17:50:09 +0200,
Maxim Levitsky wrote:
On Friday 16 November 2007 17:02, Takashi Iwai wrote:
At Thu, 1 Nov 2007 20:17:30 +0200,
Maxim Levitsky wrote:
On Thursday 01 November 2007 19:47:39 Chuck Ebbert wrote:
We have two reports now of unstable volume levels:
https://bugzilla.redhat.com/show_bug.cgi?id=361051 https://bugzilla.redhat.com/show_bug.cgi?id=354981
This is with kernel 2.6.23 plus the two ALSA merge patches from 2.6.23-rc1. _______________________________________________ Alsa-devel mailing list Alsa-devel@alsa-project.org http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
Probably this isn't a software bug. Probably this chip country to datasheet doesn't have usable "Master Volume" (volume knob) control.
I got a bug report that the same symptom appears also with STAC9221.
http://bugzilla.kernel.org/show_bug.cgi?id=9374
Maybe we need add whitelist / blacklist for this feature?
On which codec/machine is this feature confirmed to work?
thanks,
Takashi
Hi,
Yes, it seems that volume knob has troubles.
I have it with STAC9227. Obivosly it works
I know a user that first complained about some problems, but then he found that everything works ok, probably including the volknob.
He has STAC9274, and we had a long disscussion about new features I intruduced, He said that everything is OK. I ask him explictly about that.
Now remember the report about conflict between my 'Master Volume' and already existing one?
This was a STAC922x, and the autor said that now his mulimedia keys can again control the volume (Probably this indicates that volumekknob is working)
Thus we have 4 groups of STACS:
1 - STAC9250 - lot of troubles - (I would be very happpy to hear from anybody here that has it)
2- STAC9221/2 - I thought that it works, but not anymore 3- STAC9227/8/9 - I have it, so I hope that it works 4- STAC927x - very simular to above, and one user that tells that it works.
I suggest to wait a bit more to see the scale of this bug (After all it isn't that big bug, it is just a feature :-) that isn't working)
The datasheets mention briefly that an external volume control can be connected to the chip. Maybe it affects the volumeknob. If this is the case, then probably we ether need to detect it, or drop the whole thing. (Those external pins probably are just connected to the groung or somethibg like that so no real external volumeknob is present, but they still mess the internal VolumeKnob)
Blacklist can help, but it is probably too much for that feature, since the VolumeKnob doesn't add anything very special, and can be emulated with SoftVol plugin, like it is done now.
There are several solutions:
- Rename it to say 'VolumeKnob", so the users that have it broken won't
notice , but still driver will expose all controls of hardware.
But even a different name control may have a similar effect. After all, it's exposed as a mixer element, and the mixer app may choose it as well.
- Make a module param that will enable/disable it
I don't like to add a codec-specific module option, so far.
- Remove it completly, OK, but probably the #1 is better
I think the safest way at this moment is to revert that once. Then we'll have a stable state as on 2.6.23.
On my local tree, there is a patch to add a virtual "Master" control to bind all volume controls. It's a driver-side implementation (no softvol plugin). So, when this patch is merged, we'll have a master control for STAC, anyway.
All depends on whenever this is a specific stac model bug Like I thought STAC9205, or this is the 'external volume' problem.
Or, it might be the conflict (a kind of race) between the software vol knob change and the hardware vol knob change. If so, it can explain why one STAC9221 works and another STAC9221 doesn't.
Thats exactly what I have said, but this is only a guess, I didn't see a statetment about that in datasheet.
If this is just STAC9205 and STAC9221 then we can make a module param, and make it enabled by default for STAC9227/8/9 STAC927x, but make it disabled for STAC9205 and STAC9221
I got a bug report (from Linus himself) that once the driver with 9227 didn't work during 2.6.24-rc1 update. And magically started again working during bisecting. I couldn't spot the culprit (the volknob value looked OK), but my suspect is the volknob, judging from the situation.
You mean it was connected to instable volume too? If that is true, and due to the fact that I have STAC9227, probably it is a conflict with hardware volume.
I'm not 100% sure about it but just a wild guess. The volume knob and the analog loopback were only changes that may affect, and from the nature of the problem, the volknob looks more suspicious.
If not, then it is better to remove it/remame to VolumeKnob
Agreed. I'd like to take a safer way if you don't insist...
Great, it is probably the best to have a virtual master volume. Just one question, it will be probably enabled for devices that don't have a master volume (or have it broken like the STAC), right?, And when you expect it to be merged?
Hopefully will be posted in this week after a small brush up.
So I agree completly, revert it, and lets forget about that VolumeKnob. Sorry for the trouble :-)
OK, now reverted on HG tree. This should be really go to 2.6.24... Jaroslav, could you take any action please?
thanks,
Takashi
At Mon, 19 Nov 2007 12:13:28 +0100, I wrote:
If not, then it is better to remove it/remame to VolumeKnob
Agreed. I'd like to take a safer way if you don't insist...
Great, it is probably the best to have a virtual master volume. Just one question, it will be probably enabled for devices that don't have a master volume (or have it broken like the STAC), right?, And when you expect it to be merged?
Hopefully will be posted in this week after a small brush up.
OK, here is a series of the patch I promised.
The first one is the patch to add virtual master controls.
===
[PATCH] Add virtual master control
This patch adds the routines to create virtual master controls. A virtual master control can have multiple slave controls that are supposed to be identical type. The master volume will add the master attenuation and the master switch will add the master mute switch.
---
diff -r 56fbe685f99d core/Kconfig --- a/core/Kconfig Fri Nov 23 15:41:44 2007 +0100 +++ b/core/Kconfig Fri Nov 23 18:13:37 2007 +0100 @@ -15,6 +15,9 @@ config SND_RAWMIDI config SND_RAWMIDI tristate depends on SND + +config SND_VMASTER + bool
config SND_SEQUENCER tristate "Sequencer support" diff -r 56fbe685f99d core/Makefile --- a/core/Makefile Fri Nov 23 15:41:44 2007 +0100 +++ b/core/Makefile Fri Nov 23 18:13:37 2007 +0100 @@ -6,6 +6,7 @@ snd-y := sound.o init.o memory.o inf snd-y := sound.o init.o memory.o info.o control.o misc.o device.o snd-$(CONFIG_ISA_DMA_API) += isadma.o snd-$(CONFIG_SND_OSSEMUL) += sound_oss.o info_oss.o +snd-$(CONFIG_SND_VMASTER) += vmaster.o
snd-pcm-objs := pcm.o pcm_native.o pcm_lib.o pcm_timer.o pcm_misc.o \ pcm_memory.o diff -r 56fbe685f99d core/vmaster.c --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/core/vmaster.c Fri Nov 23 18:13:37 2007 +0100 @@ -0,0 +1,323 @@ +/* + * Virtual master and slave controls + * + * Copyright (c) by Takashi Iwai tiwai@suse.de + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; either version 2 of the License, or + * (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA + * + */ + +#include <sound/driver.h> +#include <linux/slab.h> +#include <sound/core.h> +#include <sound/control.h> + +struct link_master { + struct list_head slaves; + int val; +}; + +struct link_slave { + struct list_head list; + struct link_master *master; + int type; + int count; + int min_val, max_val; + int vals[2]; + struct snd_kcontrol slave; +}; + +/* get the slave ctl info and save the initial values */ +static int slave_init(struct link_slave *slave) +{ + struct snd_ctl_elem_info *uinfo; + struct snd_ctl_elem_value *uctl; + int err, ch; + + uinfo = kmalloc(sizeof(*uinfo), GFP_KERNEL); + if (!uinfo) + return -ENOMEM; + uinfo->id = slave->slave.id; + err = slave->slave.info(&slave->slave, uinfo); + if (err < 0) { + kfree(uinfo); + return err; + } + slave->type = uinfo->type; + slave->count = uinfo->count; + if (slave->count > 2 || + (slave->type != SNDRV_CTL_ELEM_TYPE_INTEGER && + slave->type != SNDRV_CTL_ELEM_TYPE_BOOLEAN)) { + kfree(uinfo); + return -EINVAL; + } + slave->min_val = uinfo->value.integer.min; + slave->max_val = uinfo->value.integer.max; + kfree(uinfo); + + uctl = kmalloc(sizeof(*uctl), GFP_KERNEL); + if (!uctl) + return -ENOMEM; + uctl->id = slave->slave.id; + err = slave->slave.get(&slave->slave, uctl); + for (ch = 0; ch < slave->count; ch++) + slave->vals[ch] = uctl->value.integer.value[ch]; + kfree(uctl); + return 0; +} + +static int slave_get_val(struct link_slave *slave, + struct snd_ctl_elem_value *ucontrol) +{ + int ch; + + if (!slave->count) { + int err = slave_init(slave); + if (err < 0) + return err; + } + for (ch = 0; ch < slave->count; ch++) + ucontrol->value.integer.value[ch] = slave->vals[ch]; + return 0; +} + +static int slave_put_val(struct link_slave *slave, + struct snd_ctl_elem_value *ucontrol) +{ + int ch, vol; + + switch (slave->type) { + case SNDRV_CTL_ELEM_TYPE_BOOLEAN: + for (ch = 0; ch < slave->count; ch++) + ucontrol->value.integer.value[ch] &= + !!slave->master->val; + break; + case SNDRV_CTL_ELEM_TYPE_INTEGER: + for (ch = 0; ch < slave->count; ch++) { + /* max master volume is supposed to be 0 dB */ + vol = ucontrol->value.integer.value[ch]; + vol += slave->master->val - slave->max_val; + if (vol < slave->min_val) + vol = slave->min_val; + else if (vol > slave->max_val) + vol = slave->max_val; + ucontrol->value.integer.value[ch] = vol; + } + break; + } + return slave->slave.put(&slave->slave, ucontrol); +} + +/* + * ctl callbacks for slaves + */ +static int slave_info(struct snd_kcontrol *kcontrol, + struct snd_ctl_elem_info *uinfo) +{ + struct link_slave *slave = snd_kcontrol_chip(kcontrol); + return slave->slave.info(&slave->slave, uinfo); +} + +static int slave_get(struct snd_kcontrol *kcontrol, + struct snd_ctl_elem_value *ucontrol) +{ + struct link_slave *slave = snd_kcontrol_chip(kcontrol); + return slave_get_val(slave, ucontrol); +} + +static int slave_put(struct snd_kcontrol *kcontrol, + struct snd_ctl_elem_value *ucontrol) +{ + struct link_slave *slave = snd_kcontrol_chip(kcontrol); + int ch, changed = 0; + + if (!slave->count) { + int err = slave_init(slave); + if (err < 0) + return err; + } + for (ch = 0; ch < slave->count; ch++) { + if (slave->vals[ch] != ucontrol->value.integer.value[ch]) { + changed = 1; + slave->vals[ch] = ucontrol->value.integer.value[ch]; + } + } + if (!changed) + return 0; + return slave_put_val(slave, ucontrol); +} + +static int slave_tlv_cmd(struct snd_kcontrol *kcontrol, + int op_flag, unsigned int size, + unsigned int __user *tlv) +{ + struct link_slave *slave = snd_kcontrol_chip(kcontrol); + return slave->slave.tlv.c(&slave->slave, op_flag, size, tlv); +} + +static void slave_free(struct snd_kcontrol *kcontrol) +{ + struct link_slave *slave = snd_kcontrol_chip(kcontrol); + if (slave->slave.private_free) + slave->slave.private_free(&slave->slave); + if (slave->master) + list_del(&slave->list); + kfree(slave); +} + +/* + * add a slave control to the group with the given master control + * + * All slaves must be the same type (returning the same information + * via info callback). The fucntion doesn't check it, so it's your + * responsibility. + * + * Also, some additional limitations: + * - at most two channels + * - logarithmic volume control (dB level), no linear volume + * - master can only attenuate the volume, no gain + */ +int snd_ctl_add_slave(struct snd_kcontrol *master, struct snd_kcontrol *slave) +{ + struct link_master *master_link = snd_kcontrol_chip(master); + struct link_slave *srec; + + srec = kzalloc(sizeof(*srec) + + slave->count * sizeof(*slave->vd), GFP_KERNEL); + if (!srec) + return -ENOMEM; + srec->slave = *slave; + memcpy(srec->slave.vd, slave->vd, slave->count * sizeof(*slave->vd)); + srec->master = master_link; + + /* override callbacks */ + slave->info = slave_info; + slave->get = slave_get; + slave->put = slave_put; + if (slave->vd[0].access & SNDRV_CTL_ELEM_ACCESS_TLV_CALLBACK) + slave->tlv.c = slave_tlv_cmd; + slave->private_data = srec; + slave->private_free = slave_free; + + list_add_tail(&srec->list, &master_link->slaves); + return 0; +} + +EXPORT_SYMBOL(snd_ctl_add_slave); + +/* + * ctl callbacks for master controls + */ +static int master_info(struct snd_kcontrol *kcontrol, + struct snd_ctl_elem_info *uinfo) +{ + struct link_master *master = snd_kcontrol_chip(kcontrol); + struct link_slave *slave; + int ret; + + if (list_empty(&master->slaves)) + return -EINVAL; + slave = list_first_entry(&master->slaves, struct link_slave, list); + ret = slave->slave.info(&slave->slave, uinfo); + uinfo->count = 1; /* override, always mono */ + return ret; +} + +static int master_get(struct snd_kcontrol *kcontrol, + struct snd_ctl_elem_value *ucontrol) +{ + struct link_master *master = snd_kcontrol_chip(kcontrol); + ucontrol->value.integer.value[0] = master->val; + return 0; +} + +static int master_put(struct snd_kcontrol *kcontrol, + struct snd_ctl_elem_value *ucontrol) +{ + struct link_master *master = snd_kcontrol_chip(kcontrol); + struct link_slave *slave; + struct snd_ctl_elem_value *uval; + int old_val = master->val; + + if (ucontrol->value.integer.value[0] == old_val) + return 0; + + uval = kmalloc(sizeof(*uval), GFP_KERNEL); + if (!uval) + return -ENOMEM; + list_for_each_entry(slave, &master->slaves, list) { + master->val = old_val; + uval->id = slave->slave.id; + slave_get_val(slave, uval); + master->val = ucontrol->value.integer.value[0]; + slave_put_val(slave, uval); + } + kfree(uval); + return 1; +} + +static void master_free(struct snd_kcontrol *kcontrol) +{ + struct link_master *master = snd_kcontrol_chip(kcontrol); + struct link_slave *slave; + + list_for_each_entry(slave, &master->slaves, list) + slave->master = NULL; + kfree(master); +} + + +/* + * create a virtual master control with the given name + * + * So far, only a control with mono channel is supported + * (just for simplicity reason) + */ +struct snd_kcontrol *snd_ctl_make_virtual_master(char *name, + const unsigned int *tlv) +{ + struct link_master *master; + struct snd_kcontrol *kctl; + struct snd_kcontrol_new knew; + + memset(&knew, 0, sizeof(knew)); + knew.iface = SNDRV_CTL_ELEM_IFACE_MIXER; + knew.name = name; + knew.info = master_info; + + master = kzalloc(sizeof(*master), GFP_KERNEL); + if (!master) + return NULL; + INIT_LIST_HEAD(&master->slaves); + + kctl = snd_ctl_new1(&knew, master); + if (!kctl) { + kfree(master); + return NULL; + } + /* override some callbacks */ + kctl->info = master_info; + kctl->get = master_get; + kctl->put = master_put; + kctl->private_free = master_free; + + if (tlv) { + kctl->vd[0].access |= SNDRV_CTL_ELEM_ACCESS_TLV_READ; + kctl->tlv.p = tlv; + } + return kctl; +} + +EXPORT_SYMBOL(snd_ctl_make_virtual_master); diff -r 56fbe685f99d include/control.h --- a/include/control.h Fri Nov 23 15:41:44 2007 +0100 +++ b/include/control.h Fri Nov 23 18:13:37 2007 +0100 @@ -169,4 +169,12 @@ int snd_ctl_boolean_stereo_info(struct s int snd_ctl_boolean_stereo_info(struct snd_kcontrol *kcontrol, struct snd_ctl_elem_info *uinfo);
+/* + * virtual master control + */ +struct snd_kcontrol *snd_ctl_make_virtual_master(char *name, + const unsigned int *tlv); +int snd_ctl_add_slave(struct snd_kcontrol *master, struct snd_kcontrol *slave); + + #endif /* __SOUND_CONTROL_H */
[PATCH] Add virtual master controls HD-audio
Create virtual "Master" controls automatically when not exists on some known codecs.
---
diff -r 861c951ac951 pci/Kconfig --- a/pci/Kconfig Tue Sep 18 15:48:16 2007 +0200 +++ b/pci/Kconfig Tue Sep 18 15:48:29 2007 +0200 @@ -512,6 +512,7 @@ config SND_HDA_CODEC_REALTEK config SND_HDA_CODEC_REALTEK bool "Build Realtek HD-audio codec support" depends on SND_HDA_INTEL + select SND_VMASTER default y help Say Y here to include Realtek HD-audio codec support in @@ -520,6 +521,7 @@ config SND_HDA_CODEC_ANALOG config SND_HDA_CODEC_ANALOG bool "Build Analog Device HD-audio codec support" depends on SND_HDA_INTEL + select SND_VMASTER default y help Say Y here to include Analog Device HD-audio codec support in @@ -528,6 +530,7 @@ config SND_HDA_CODEC_SIGMATEL config SND_HDA_CODEC_SIGMATEL bool "Build IDT/Sigmatel HD-audio codec support" depends on SND_HDA_INTEL + select SND_VMASTER default y help Say Y here to include IDT (Sigmatel) HD-audio codec support in diff -r 861c951ac951 pci/hda/hda_codec.c --- a/pci/hda/hda_codec.c Tue Sep 18 15:48:16 2007 +0200 +++ b/pci/hda/hda_codec.c Tue Sep 18 15:48:29 2007 +0200 @@ -1016,6 +1016,68 @@ int snd_hda_mixer_amp_tlv(struct snd_kco return -EFAULT; return 0; } + +#ifdef CONFIG_SND_VMASTER +/* + * set (static) TLV for virtual master volume; recalculated as max 0dB + */ +void snd_hda_set_vmaster_tlv(struct hda_codec *codec, hda_nid_t nid, int dir, + unsigned int *tlv) +{ + u32 caps; + int nums, step; + + caps = query_amp_caps(codec, nid, dir); + nums = (caps & AC_AMPCAP_NUM_STEPS) >> AC_AMPCAP_NUM_STEPS_SHIFT; + step = (caps & AC_AMPCAP_STEP_SIZE) >> AC_AMPCAP_STEP_SIZE_SHIFT; + step = (step + 1) * 25; + tlv[0] = SNDRV_CTL_TLVT_DB_SCALE; + tlv[1] = 2 * sizeof(unsigned int); + tlv[2] = -nums * step; + tlv[3] = step; +} + +/* find a mixer control element with the given name */ +struct snd_kcontrol *snd_hda_find_mixer_ctl(struct hda_codec *codec, + const char *name) +{ + struct snd_ctl_elem_id id; + memset(&id, 0, sizeof(id)); + id.iface = SNDRV_CTL_ELEM_IFACE_MIXER; + strcpy(id.name, name); + return snd_ctl_find_id(codec->bus->card, &id); +} + +/* create a virtual master control and add slaves */ +int snd_hda_add_vmaster(struct hda_codec *codec, char *name, + unsigned int *tlv, const char **slaves) +{ + struct snd_kcontrol *kctl; + const char **s; + int err; + + kctl = snd_ctl_make_virtual_master(name, tlv); + if (!kctl) + return -ENOMEM; + err = snd_ctl_add(codec->bus->card, kctl); + if (err < 0) + return err; + + for (s = slaves; *s; s++) { + struct snd_kcontrol *sctl; + + sctl = snd_hda_find_mixer_ctl(codec, *s); + if (!sctl) { + snd_printdd("Cannot find slave %s, skipped\n", *s); + continue; + } + err = snd_ctl_add_slave(kctl, sctl); + if (err < 0) + return err; + } + return 0; +} +#endif /* CONFIG_SND_VMASTER */
/* switch */ int snd_hda_mixer_amp_switch_info(struct snd_kcontrol *kcontrol, diff -r 861c951ac951 pci/hda/hda_local.h --- a/pci/hda/hda_local.h Tue Sep 18 15:48:16 2007 +0200 +++ b/pci/hda/hda_local.h Tue Sep 18 15:48:29 2007 +0200 @@ -90,6 +90,13 @@ void snd_hda_codec_resume_amp(struct hda void snd_hda_codec_resume_amp(struct hda_codec *codec); #endif
+void snd_hda_set_vmaster_tlv(struct hda_codec *codec, hda_nid_t nid, int dir, + unsigned int *tlv); +struct snd_kcontrol *snd_hda_find_mixer_ctl(struct hda_codec *codec, + const char *name); +int snd_hda_add_vmaster(struct hda_codec *codec, char *name, + unsigned int *tlv, const char **slaves); + /* amp value bits */ #define HDA_AMP_MUTE 0x80 #define HDA_AMP_UNMUTE 0x00 diff -r 861c951ac951 pci/hda/patch_analog.c --- a/pci/hda/patch_analog.c Tue Sep 18 15:48:16 2007 +0200 +++ b/pci/hda/patch_analog.c Tue Sep 18 15:48:29 2007 +0200 @@ -79,6 +79,11 @@ struct ad198x_spec { #ifdef CONFIG_SND_HDA_POWER_SAVE struct hda_loopback_check loopback; #endif + /* for virtual master */ + hda_nid_t vmaster_nid; + u32 vmaster_tlv[4]; + const char **slave_vols; + const char **slave_sws; };
/* @@ -125,6 +130,28 @@ static int ad198x_init(struct hda_codec snd_hda_sequence_write(codec, spec->init_verbs[i]); return 0; } + +static const char *ad_slave_vols[] = { + "Front Playback Volume", + "Surround Playback Volume", + "Center Playback Volume", + "LFE Playback Volume", + "Side Playback Volume", + "Headphone Playback Volume", + "Mono Playback Volume", + NULL +}; + +static const char *ad_slave_sws[] = { + "Front Playback Switch", + "Surround Playback Switch", + "Center Playback Switch", + "LFE Playback Switch", + "Side Playback Switch", + "Headphone Playback Switch", + "Mono Playback Switch", + NULL +};
static int ad198x_build_controls(struct hda_codec *codec) { @@ -147,6 +174,27 @@ static int ad198x_build_controls(struct if (err < 0) return err; } + + /* if we have no master control, let's create it */ + if (!snd_hda_find_mixer_ctl(codec, "Master Playback Volume")) { + snd_hda_set_vmaster_tlv(codec, spec->vmaster_nid, + HDA_OUTPUT, spec->vmaster_tlv); + err = snd_hda_add_vmaster(codec, "Master Playback Volume", + spec->vmaster_tlv, + (spec->slave_vols ? + spec->slave_vols : ad_slave_vols)); + if (err < 0) + return err; + } + if (!snd_hda_find_mixer_ctl(codec, "Master Playback Switch")) { + err = snd_hda_add_vmaster(codec, "Master Playback Switch", + NULL, + (spec->slave_sws ? + spec->slave_sws : ad_slave_sws)); + if (err < 0) + return err; + } + return 0; }
@@ -897,6 +945,7 @@ static int patch_ad1986a(struct hda_code #ifdef CONFIG_SND_HDA_POWER_SAVE spec->loopback.amplist = ad1986a_loopbacks; #endif + spec->vmaster_nid = 0x1b;
codec->patch_ops = ad198x_patch_ops;
@@ -1129,6 +1178,7 @@ static int patch_ad1983(struct hda_codec #ifdef CONFIG_SND_HDA_POWER_SAVE spec->loopback.amplist = ad1983_loopbacks; #endif + spec->vmaster_nid = 0x05;
codec->patch_ops = ad198x_patch_ops;
@@ -1525,6 +1575,7 @@ static int patch_ad1981(struct hda_codec #ifdef CONFIG_SND_HDA_POWER_SAVE spec->loopback.amplist = ad1981_loopbacks; #endif + spec->vmaster_nid = 0x05;
codec->patch_ops = ad198x_patch_ops;
@@ -2834,6 +2885,7 @@ static int patch_ad1988(struct hda_codec #ifdef CONFIG_SND_HDA_POWER_SAVE spec->loopback.amplist = ad1988_loopbacks; #endif + spec->vmaster_nid = 0x04;
return 0; } @@ -3000,6 +3052,19 @@ static struct hda_amp_list ad1884_loopba }; #endif
+static const char *ad1884_slave_vols[] = { + "PCM Playback Volume", + "Mic Playback Volume", + "Mono Playback Volume", + "Front Mic Playback Volume", + "Mic Playback Volume", + "CD Playback Volume", + "Internal Mic Playback Volume", + "Docking Mic Playback Volume" + "Beep Playback Volume", + NULL +}; + static int patch_ad1884(struct hda_codec *codec) { struct ad198x_spec *spec; @@ -3027,6 +3092,9 @@ static int patch_ad1884(struct hda_codec #ifdef CONFIG_SND_HDA_POWER_SAVE spec->loopback.amplist = ad1884_loopbacks; #endif + spec->vmaster_nid = 0x04; + /* we need to cover all playback volumes */ + spec->slave_vols = ad1884_slave_vols;
codec->patch_ops = ad198x_patch_ops;
@@ -3459,6 +3527,7 @@ static int patch_ad1882(struct hda_codec #ifdef CONFIG_SND_HDA_POWER_SAVE spec->loopback.amplist = ad1882_loopbacks; #endif + spec->vmaster_nid = 0x04;
codec->patch_ops = ad198x_patch_ops;
diff -r 861c951ac951 pci/hda/patch_realtek.c --- a/pci/hda/patch_realtek.c Tue Sep 18 15:48:16 2007 +0200 +++ b/pci/hda/patch_realtek.c Tue Sep 18 15:48:29 2007 +0200 @@ -247,6 +247,9 @@ struct alc_spec { unsigned int sense_updated: 1; unsigned int jack_present: 1;
+ /* for virtual master */ + hda_nid_t vmaster_nid; + u32 vmaster_tlv[4]; #ifdef CONFIG_SND_HDA_POWER_SAVE struct hda_loopback_check loopback; #endif @@ -1098,8 +1101,8 @@ static struct snd_kcontrol_new alc880_f1 static struct snd_kcontrol_new alc880_f1734_mixer[] = { HDA_CODEC_VOLUME("Headphone Playback Volume", 0x0c, 0x0, HDA_OUTPUT), HDA_BIND_MUTE("Headphone Playback Switch", 0x0c, 2, HDA_INPUT), - HDA_CODEC_VOLUME("Internal Speaker Playback Volume", 0x0d, 0x0, HDA_OUTPUT), - HDA_BIND_MUTE("Internal Speaker Playback Switch", 0x0d, 2, HDA_INPUT), + HDA_CODEC_VOLUME("Speaker Playback Volume", 0x0d, 0x0, HDA_OUTPUT), + HDA_BIND_MUTE("Speaker Playback Switch", 0x0d, 2, HDA_INPUT), HDA_CODEC_VOLUME("CD Playback Volume", 0x0b, 0x04, HDA_INPUT), HDA_CODEC_MUTE("CD Playback Switch", 0x0b, 0x04, HDA_INPUT), HDA_CODEC_VOLUME("Mic Playback Volume", 0x0b, 0x0, HDA_INPUT), @@ -1197,10 +1200,10 @@ static struct snd_kcontrol_new alc880_tc
/* Uniwill */ static struct snd_kcontrol_new alc880_uniwill_mixer[] = { - HDA_CODEC_VOLUME("HPhone Playback Volume", 0x0c, 0x0, HDA_OUTPUT), - HDA_BIND_MUTE("HPhone Playback Switch", 0x0c, 2, HDA_INPUT), - HDA_CODEC_VOLUME("iSpeaker Playback Volume", 0x0d, 0x0, HDA_OUTPUT), - HDA_BIND_MUTE("iSpeaker Playback Switch", 0x0d, 2, HDA_INPUT), + HDA_CODEC_VOLUME("Headphone Playback Volume", 0x0c, 0x0, HDA_OUTPUT), + HDA_BIND_MUTE("Headphone Playback Switch", 0x0c, 2, HDA_INPUT), + HDA_CODEC_VOLUME("Speaker Playback Volume", 0x0d, 0x0, HDA_OUTPUT), + HDA_BIND_MUTE("Speaker Playback Switch", 0x0d, 2, HDA_INPUT), HDA_CODEC_VOLUME_MONO("Center Playback Volume", 0x0e, 1, 0x0, HDA_OUTPUT), HDA_CODEC_VOLUME_MONO("LFE Playback Volume", 0x0e, 2, 0x0, HDA_OUTPUT), HDA_BIND_MUTE_MONO("Center Playback Switch", 0x0e, 1, 2, HDA_INPUT), @@ -1240,13 +1243,47 @@ static struct snd_kcontrol_new alc880_fu };
static struct snd_kcontrol_new alc880_uniwill_p53_mixer[] = { - HDA_CODEC_VOLUME("HPhone Playback Volume", 0x0c, 0x0, HDA_OUTPUT), - HDA_BIND_MUTE("HPhone Playback Switch", 0x0c, 2, HDA_INPUT), - HDA_CODEC_VOLUME("iSpeaker Playback Volume", 0x0d, 0x0, HDA_OUTPUT), - HDA_BIND_MUTE("iSpeaker Playback Switch", 0x0d, 2, HDA_INPUT), + HDA_CODEC_VOLUME("Headphone Playback Volume", 0x0c, 0x0, HDA_OUTPUT), + HDA_BIND_MUTE("Headphone Playback Switch", 0x0c, 2, HDA_INPUT), + HDA_CODEC_VOLUME("Speaker Playback Volume", 0x0d, 0x0, HDA_OUTPUT), + HDA_BIND_MUTE("Speaker Playback Switch", 0x0d, 2, HDA_INPUT), HDA_CODEC_VOLUME("Mic Playback Volume", 0x0b, 0x0, HDA_INPUT), HDA_CODEC_MUTE("Mic Playback Switch", 0x0b, 0x0, HDA_INPUT), { } /* end */ +}; + +/* + * virtual master controls + */ + +/* + * slave controls for virtual master + */ +static const char *alc_slave_vols[] = { + "Front Playback Volume", + "Surround Playback Volume", + "Center Playback Volume", + "LFE Playback Volume", + "Side Playback Volume", + "Headphone Playback Volume", + "Speaker Playback Volume", + "Mono Playback Volume", + "iSpeaker Playback Volume", + "Line-Out Playback Volume", + NULL, +}; + +static const char *alc_slave_sws[] = { + "Front Playback Switch", + "Surround Playback Switch", + "Center Playback Switch", + "LFE Playback Switch", + "Side Playback Switch", + "Headphone Playback Switch", + "Speaker Playback Switch", + "Mono Playback Switch", + "iSpeaker Playback Switch", + NULL, };
/* @@ -1275,6 +1312,23 @@ static int alc_build_controls(struct hda if (err < 0) return err; } + + /* if we have no master control, let's create it */ + if (!snd_hda_find_mixer_ctl(codec, "Master Playback Volume")) { + snd_hda_set_vmaster_tlv(codec, spec->vmaster_nid, + HDA_OUTPUT, spec->vmaster_tlv); + err = snd_hda_add_vmaster(codec, "Master Playback Volume", + spec->vmaster_tlv, alc_slave_vols); + if (err < 0) + return err; + } + if (!snd_hda_find_mixer_ctl(codec, "Master Playback Switch")) { + err = snd_hda_add_vmaster(codec, "Master Playback Switch", + NULL, alc_slave_sws); + if (err < 0) + return err; + } + return 0; }
@@ -1823,8 +1877,8 @@ static struct hda_channel_mode alc880_lg
static struct snd_kcontrol_new alc880_lg_mixer[] = { /* FIXME: it's not really "master" but front channels */ - HDA_CODEC_VOLUME("Master Playback Volume", 0x0f, 0x0, HDA_OUTPUT), - HDA_BIND_MUTE("Master Playback Switch", 0x0f, 2, HDA_INPUT), + HDA_CODEC_VOLUME("Front Playback Volume", 0x0f, 0x0, HDA_OUTPUT), + HDA_BIND_MUTE("Front Playback Switch", 0x0f, 2, HDA_INPUT), HDA_CODEC_VOLUME("Surround Playback Volume", 0x0c, 0x0, HDA_OUTPUT), HDA_BIND_MUTE("Surround Playback Switch", 0x0c, 2, HDA_INPUT), HDA_CODEC_VOLUME_MONO("Center Playback Volume", 0x0d, 1, 0x0, HDA_OUTPUT), @@ -3390,6 +3444,8 @@ static int patch_alc880(struct hda_codec spec->num_mixers++; } } + + spec->vmaster_nid = 0x0c;
codec->patch_ops = alc_patch_ops; if (board_config == ALC880_AUTO) @@ -4762,6 +4818,8 @@ static int patch_alc260(struct hda_codec spec->stream_digital_playback = &alc260_pcm_digital_playback; spec->stream_digital_capture = &alc260_pcm_digital_capture;
+ spec->vmaster_nid = 0x08; + codec->patch_ops = alc_patch_ops; if (board_config == ALC260_AUTO) spec->init_hook = alc260_auto_init; @@ -4962,15 +5020,15 @@ static struct snd_kcontrol_new alc882_ba };
static struct snd_kcontrol_new alc885_mbp3_mixer[] = { - HDA_CODEC_VOLUME("Master Volume", 0x0c, 0x00, HDA_OUTPUT), - HDA_BIND_MUTE ("Master Switch", 0x0c, 0x02, HDA_INPUT), - HDA_CODEC_MUTE ("Speaker Switch", 0x14, 0x00, HDA_OUTPUT), - HDA_CODEC_VOLUME("Line Out Volume", 0x0d,0x00, HDA_OUTPUT), - HDA_CODEC_VOLUME("Line In Playback Volume", 0x0b, 0x02, HDA_INPUT), - HDA_CODEC_MUTE ("Line In Playback Switch", 0x0b, 0x02, HDA_INPUT), + HDA_CODEC_VOLUME("Front Playback Volume", 0x0c, 0x00, HDA_OUTPUT), + HDA_BIND_MUTE ("Front Playback Switch", 0x0c, 0x02, HDA_INPUT), + HDA_CODEC_MUTE ("Speaker Playback Switch", 0x14, 0x00, HDA_OUTPUT), + HDA_CODEC_VOLUME("Line-Out Playback Volume", 0x0d, 0x00, HDA_OUTPUT), + HDA_CODEC_VOLUME("Line Playback Volume", 0x0b, 0x02, HDA_INPUT), + HDA_CODEC_MUTE ("Line Playback Switch", 0x0b, 0x02, HDA_INPUT), HDA_CODEC_VOLUME("Mic Playback Volume", 0x0b, 0x00, HDA_INPUT), HDA_CODEC_MUTE ("Mic Playback Switch", 0x0b, 0x00, HDA_INPUT), - HDA_CODEC_VOLUME("Line In Boost", 0x1a, 0x00, HDA_INPUT), + HDA_CODEC_VOLUME("Line Boost", 0x1a, 0x00, HDA_INPUT), HDA_CODEC_VOLUME("Mic Boost", 0x18, 0x00, HDA_INPUT), { } /* end */ }; @@ -5971,6 +6029,8 @@ static int patch_alc882(struct hda_codec spec->num_mixers++; } } + + spec->vmaster_nid = 0x0c;
codec->patch_ops = alc_patch_ops; if (board_config == ALC882_AUTO) @@ -7446,6 +7506,8 @@ static int patch_alc883(struct hda_codec spec->adc_nids = alc883_adc_nids; spec->num_adc_nids = ARRAY_SIZE(alc883_adc_nids); } + + spec->vmaster_nid = 0x0c;
codec->patch_ops = alc_patch_ops; if (board_config == ALC883_AUTO) @@ -8566,6 +8628,8 @@ static int patch_alc262(struct hda_codec } }
+ spec->vmaster_nid = 0x0c; + codec->patch_ops = alc_patch_ops; if (board_config == ALC262_AUTO) spec->init_hook = alc262_auto_init; @@ -9240,6 +9304,9 @@ static int patch_alc268(struct hda_codec } } } + + spec->vmaster_nid = 0x02; + codec->patch_ops = alc_patch_ops; if (board_config == ALC268_AUTO) spec->init_hook = alc268_auto_init; @@ -10394,6 +10461,8 @@ static int patch_alc861(struct hda_codec spec->stream_digital_playback = &alc861_pcm_digital_playback; spec->stream_digital_capture = &alc861_pcm_digital_capture;
+ spec->vmaster_nid = 0x03; + codec->patch_ops = alc_patch_ops; if (board_config == ALC861_AUTO) spec->init_hook = alc861_auto_init; @@ -11370,6 +11439,8 @@ static int patch_alc861vd(struct hda_cod
spec->mixers[spec->num_mixers] = alc861vd_capture_mixer; spec->num_mixers++; + + spec->vmaster_nid = 0x02;
codec->patch_ops = alc_patch_ops;
@@ -12222,6 +12293,8 @@ static int patch_alc662(struct hda_codec spec->num_adc_nids = ARRAY_SIZE(alc662_adc_nids); }
+ spec->vmaster_nid = 0x02; + codec->patch_ops = alc_patch_ops; if (board_config == ALC662_AUTO) spec->init_hook = alc662_auto_init; diff -r 861c951ac951 pci/hda/patch_sigmatel.c --- a/pci/hda/patch_sigmatel.c Tue Sep 18 15:48:16 2007 +0200 +++ b/pci/hda/patch_sigmatel.c Tue Sep 18 15:48:29 2007 +0200 @@ -156,6 +156,9 @@ struct sigmatel_spec { struct snd_kcontrol_new *kctl_alloc; struct hda_input_mux private_dimux; struct hda_input_mux private_imux; + + /* virtual master */ + unsigned int vmaster_tlv[4]; };
static hda_nid_t stac9200_adc_nids[1] = { @@ -521,6 +524,34 @@ static struct snd_kcontrol_new stac927x_ { } /* end */ };
+static const char *slave_vols[] = { + "Front Playback Volume", + "Surround Playback Volume", + "Center Playback Volume", + "LFE Playback Volume", + "Side Playback Volume", + "Headphone Playback Volume", + "Headphone Playback Volume", + "Speaker Playback Volume", + "External Speaker Playback Volume", + "Speaker2 Playback Volume", + NULL +}; + +static const char *slave_sws[] = { + "Front Playback Switch", + "Surround Playback Switch", + "Center Playback Switch", + "LFE Playback Switch", + "Side Playback Switch", + "Headphone Playback Switch", + "Headphone Playback Switch", + "Speaker Playback Switch", + "External Speaker Playback Switch", + "Speaker2 Playback Switch", + NULL +}; + static int stac92xx_build_controls(struct hda_codec *codec) { struct sigmatel_spec *spec = codec->spec; @@ -547,6 +578,23 @@ static int stac92xx_build_controls(struc if (err < 0) return err; } + + /* if we have no master control, let's create it */ + if (!snd_hda_find_mixer_ctl(codec, "Master Playback Volume")) { + snd_hda_set_vmaster_tlv(codec, spec->multiout.dac_nids[0], + HDA_OUTPUT, spec->vmaster_tlv); + err = snd_hda_add_vmaster(codec, "Master Playback Volume", + spec->vmaster_tlv, slave_vols); + if (err < 0) + return err; + } + if (!snd_hda_find_mixer_ctl(codec, "Master Playback Switch")) { + err = snd_hda_add_vmaster(codec, "Master Playback Switch", + NULL, slave_sws); + if (err < 0) + return err; + } + return 0; }
[PATCH] AC97 virtual master control
This patch adds the virtual master control to AC97-related drivers. It's needed for surround outputs. At this moment, it's added when vmaster=1 option is given to either snd-intel8x0, snd-atiixp or snd-via82xx driver.
For automatic addition of vmaster control, we'll need to resolve the following
- whether the vmaster is really needed (most machines have only front output) - disable AD-mode on AD codecs (to back to the normal AC97 volume control mode)
---
diff -r 5c48888d1307 include/ac97_codec.h --- a/include/ac97_codec.h Tue Sep 18 15:48:30 2007 +0200 +++ b/include/ac97_codec.h Tue Sep 18 15:48:48 2007 +0200 @@ -595,6 +595,7 @@ struct ac97_quirk {
int snd_ac97_tune_hardware(struct snd_ac97 *ac97, struct ac97_quirk *quirk, const char *override); int snd_ac97_set_rate(struct snd_ac97 *ac97, int reg, unsigned int rate); +int snd_ac97_add_vmaster(struct snd_ac97 *ac97);
/* * PCM allocation diff -r 5c48888d1307 pci/Kconfig --- a/pci/Kconfig Tue Sep 18 15:48:30 2007 +0200 +++ b/pci/Kconfig Tue Sep 18 15:48:48 2007 +0200 @@ -59,6 +59,7 @@ config SND_ATIIXP tristate "ATI IXP AC97 Controller" depends on SND select SND_AC97_CODEC + select SND_VMASTER help Say Y here to include support for the integrated AC97 sound device on motherboards with ATI chipsets (ATI IXP 150/200/250/ @@ -664,6 +665,7 @@ config SND_INTEL8X0 tristate "Intel/SiS/nVidia/AMD/ALi AC97 Controller" depends on SND select SND_AC97_CODEC + select SND_VMASTER help Say Y here to include support for the integrated AC97 sound device on motherboards with Intel/SiS/nVidia/AMD chipsets, or @@ -835,6 +837,7 @@ config SND_VIA82XX depends on SND select SND_MPU401_UART select SND_AC97_CODEC + select SND_VMASTER help Say Y here to include support for the integrated AC97 sound device on motherboards with VIA chipsets. diff -r 5c48888d1307 pci/ac97/ac97_codec.c --- a/pci/ac97/ac97_codec.c Tue Sep 18 15:48:30 2007 +0200 +++ b/pci/ac97/ac97_codec.c Tue Sep 18 15:48:48 2007 +0200 @@ -2871,6 +2871,65 @@ int snd_ac97_tune_hardware(struct snd_ac
EXPORT_SYMBOL(snd_ac97_tune_hardware);
+#ifdef CONFIG_SND_VMASTER +/* + * create a virtual master control (if surround is supported) + */ +static const char *slave_items[] = { + "Front", "Surround", "Center", "LFE", "Side", "Headphone", "Mono", + NULL +}; + +static int add_vmaster(struct snd_ac97 *ac97, char *suffix, int has_tlv) +{ + struct snd_kcontrol *sctl; + struct snd_kcontrol *kctl; + const unsigned int *tlv = NULL; + char name[32]; + const char **s; + int err; + + sctl = ctl_find(ac97, "Surround", suffix); + if (!sctl) + return 0; /* no surrounds */ + if (has_tlv) + tlv = find_db_scale((sctl->private_value >> 16) & 0xff); + + if (snd_ac97_rename_ctl(ac97, "Master", "Front", suffix) < 0) + return 0; /* front already exists */ + snd_ac97_rename_ctl(ac97, "Master Mono", "Mono", suffix); + + sprintf(name, "Master %s", suffix); + kctl = snd_ctl_make_virtual_master(name, tlv); + if (!kctl) + return -ENOMEM; + + err = snd_ctl_add(ac97->bus->card, kctl); + if (err < 0) + return err; + for (s = slave_items; *s; s++) { + sctl = ctl_find(ac97, *s, suffix); + if (!sctl) + continue; + err = snd_ctl_add_slave(kctl, sctl); + if (err < 0) + return err; + } + return 0; +} + +int snd_ac97_add_vmaster(struct snd_ac97 *ac97) +{ + int err; + err = add_vmaster(ac97, "Playback Volume", 1); + if (err < 0) + return err; + return add_vmaster(ac97, "Playback Switch", 0); +} + +EXPORT_SYMBOL(snd_ac97_add_vmaster); +#endif + /* * INIT part */ diff -r 5c48888d1307 pci/atiixp.c --- a/pci/atiixp.c Tue Sep 18 15:48:30 2007 +0200 +++ b/pci/atiixp.c Tue Sep 18 15:48:48 2007 +0200 @@ -46,6 +46,7 @@ static char *ac97_quirk; static char *ac97_quirk; static int spdif_aclink = 1; static int ac97_codec = -1; +static int vmaster;
module_param(index, int, 0444); MODULE_PARM_DESC(index, "Index value for ATI IXP controller."); @@ -59,6 +60,8 @@ MODULE_PARM_DESC(ac97_codec, "Specify co MODULE_PARM_DESC(ac97_codec, "Specify codec instead of probing."); module_param(spdif_aclink, bool, 0444); MODULE_PARM_DESC(spdif_aclink, "S/PDIF over AC-link."); +module_param(vmaster, bool, 0444); +MODULE_PARM_DESC(vmaster, "Add a virtual master volume if needed.");
/* just for backward compatibility */ static int enable; @@ -1442,6 +1445,8 @@ static int __devinit snd_atiixp_mixer_ne }
snd_ac97_tune_hardware(chip->ac97[0], ac97_quirks, quirk_override); + if (vmaster) + snd_ac97_add_vmaster(chip->ac97[0]);
return 0; } diff -r 5c48888d1307 pci/intel8x0.c --- a/pci/intel8x0.c Tue Sep 18 15:48:30 2007 +0200 +++ b/pci/intel8x0.c Tue Sep 18 15:48:48 2007 +0200 @@ -72,6 +72,7 @@ static int buggy_irq = -1; /* auto-check static int buggy_irq = -1; /* auto-check */ static int xbox; static int spdif_aclink = -1; +static int vmaster;
module_param(index, int, 0444); MODULE_PARM_DESC(index, "Index value for Intel i8x0 soundcard."); @@ -89,6 +90,8 @@ MODULE_PARM_DESC(xbox, "Set to 1 for Xbo MODULE_PARM_DESC(xbox, "Set to 1 for Xbox, if you have problems with the AC'97 codec detection."); module_param(spdif_aclink, int, 0444); MODULE_PARM_DESC(spdif_aclink, "S/PDIF over AC-link."); +module_param(vmaster, bool, 0444); +MODULE_PARM_DESC(vmaster, "Add a virtual master volume if needed.");
/* just for backward compatibility */ static int enable; @@ -2149,6 +2152,8 @@ static int __devinit snd_intel8x0_mixer( } /* tune up the primary codec */ snd_ac97_tune_hardware(chip->ac97[0], ac97_quirks, quirk_override); + if (vmaster) + snd_ac97_add_vmaster(chip->ac97[0]); /* enable separate SDINs for ICH4 */ if (chip->device_type == DEVICE_INTEL_ICH4) pbus->isdin = 1; diff -r 5c48888d1307 pci/via82xx.c --- a/pci/via82xx.c Tue Sep 18 15:48:30 2007 +0200 +++ b/pci/via82xx.c Tue Sep 18 15:48:48 2007 +0200 @@ -86,6 +86,7 @@ static int ac97_clock = 48000; static int ac97_clock = 48000; static char *ac97_quirk; static int dxs_support; +static int vmaster;
module_param(index, int, 0444); MODULE_PARM_DESC(index, "Index value for VIA 82xx bridge."); @@ -103,6 +104,8 @@ MODULE_PARM_DESC(ac97_quirk, "AC'97 work MODULE_PARM_DESC(ac97_quirk, "AC'97 workaround for strange hardware."); module_param(dxs_support, int, 0444); MODULE_PARM_DESC(dxs_support, "Support for DXS channels (0 = auto, 1 = enable, 2 = disable, 3 = 48k only, 4 = no VRA, 5 = enable any sample rate)"); +module_param(vmaster, bool, 0444); +MODULE_PARM_DESC(vmaster, "Add a virtual master volume if needed.");
/* just for backward compatibility */ static int enable; @@ -1820,6 +1823,8 @@ static int __devinit snd_via82xx_mixer_n return err;
snd_ac97_tune_hardware(chip->ac97, ac97_quirks, quirk_override); + if (vmaster) + snd_ac97_add_vmaster(chip->ac97);
if (chip->chip_type != TYPE_VIA686) { /* use slot 10/11 */
And this patch is to alsa-driver to build vmaster feature.
Takashi
diff -r 06162eef8936 acore/vmaster.c --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/acore/vmaster.c Mon Oct 08 18:26:21 2007 +0200 @@ -0,0 +1,2 @@ +#define __NO_VERSION__ +#include "../alsa-kernel/core/vmaster.c"
On Fri, 23 Nov 2007, Takashi Iwai wrote:
At Mon, 19 Nov 2007 12:13:28 +0100, I wrote:
If not, then it is better to remove it/remame to VolumeKnob
Agreed. I'd like to take a safer way if you don't insist...
Great, it is probably the best to have a virtual master volume. Just one question, it will be probably enabled for devices that don't have a master volume (or have it broken like the STAC), right?, And when you expect it to be merged?
Hopefully will be posted in this week after a small brush up.
OK, here is a series of the patch I promised.
The first one is the patch to add virtual master controls.
===
[PATCH] Add virtual master control
This patch adds the routines to create virtual master controls. A virtual master control can have multiple slave controls that are supposed to be identical type. The master volume will add the master attenuation and the master switch will add the master mute switch.
I'm really not sure if I like to see such extensions in kernel. We have now user control elements and a small daemon written in C or python will do exactly same job and will be more flexible.
Jaroslav
----- Jaroslav Kysela perex@perex.cz Linux Kernel Sound Maintainer ALSA Project
On Friday 23 November 2007 20:36:32 Jaroslav Kysela wrote:
On Fri, 23 Nov 2007, Takashi Iwai wrote:
At Mon, 19 Nov 2007 12:13:28 +0100, I wrote:
If not, then it is better to remove it/remame to VolumeKnob
Agreed. I'd like to take a safer way if you don't insist...
Great, it is probably the best to have a virtual master volume. Just one question, it will be probably enabled for devices that don't have a master volume (or have it broken like the STAC), right?, And when you expect it to be merged?
Hopefully will be posted in this week after a small brush up.
OK, here is a series of the patch I promised.
The first one is the patch to add virtual master controls.
===
[PATCH] Add virtual master control
This patch adds the routines to create virtual master controls. A virtual master control can have multiple slave controls that are supposed to be identical type. The master volume will add the master attenuation and the master switch will add the master mute switch.
I'm really not sure if I like to see such extensions in kernel. We have now user control elements and a small daemon written in C or python will do exactly same job and will be more flexible.
Jaroslav
Hi,
Well, first big thanks for those patches.
Secondary I strongly disagree that the above can be implemented in userspace easily. Sure you can have a program that adjusts the volume of all outputs, and creates a virtual userspace control, but the change in volume of outputs will be visible to userspace. For example moving the master volume will move the front/surround/LFE/.... sliders, and it is no good.
What this patch does, it actually modifies the code for those 'slave' amps, so the master volume is taken in account.
I will test it now on my system.
I hope this gets merged, Best regards, Maxim Levitsky
At Fri, 23 Nov 2007 19:36:32 +0100 (CET), Jaroslav Kysela wrote:
On Fri, 23 Nov 2007, Takashi Iwai wrote:
At Mon, 19 Nov 2007 12:13:28 +0100, I wrote:
If not, then it is better to remove it/remame to VolumeKnob
Agreed. I'd like to take a safer way if you don't insist...
Great, it is probably the best to have a virtual master volume. Just one question, it will be probably enabled for devices that don't have a master volume (or have it broken like the STAC), right?, And when you expect it to be merged?
Hopefully will be posted in this week after a small brush up.
OK, here is a series of the patch I promised.
The first one is the patch to add virtual master controls.
===
[PATCH] Add virtual master control
This patch adds the routines to create virtual master controls. A virtual master control can have multiple slave controls that are supposed to be identical type. The master volume will add the master attenuation and the master switch will add the master mute switch.
I'm really not sure if I like to see such extensions in kernel. We have now user control elements and a small daemon written in C or python will do exactly same job and will be more flexible.
I've thought that a user-space solution would be appropriate, too. But, a requirement of a daemon is a very big disadvantage (I believe many people would dislike). A plugin-based solution is another idea, but it's also complex and hard to implement consistently (because many mixer apps open "hw" device as default).
What I suggested is the implementation of a quite trivial master control. Of course, it's not so flexible but it covers most of hardwares. So much flexibility isn't needed in reality. The convenience (for user and developer) is more important.
Takashi
On Sat, 24 Nov 2007 11:12:07 +0100 "Takashi Iwai" tiwai@suse.de wrote:
At Fri, 23 Nov 2007 19:36:32 +0100 (CET), Jaroslav Kysela wrote:
On Fri, 23 Nov 2007, Takashi Iwai wrote:
At Mon, 19 Nov 2007 12:13:28 +0100, I wrote:
OK, here is a series of the patch I promised.
The first one is the patch to add virtual master controls.
===
[PATCH] Add virtual master control
This patch adds the routines to create virtual master controls. A virtual master control can have multiple slave controls that are supposed to be identical type. The master volume will add the master attenuation and the master switch will add the master mute switch.
I'm really not sure if I like to see such extensions in kernel. We have now user control elements and a small daemon written in C or python will do exactly same job and will be more flexible.
could you flesh this out a teeny bit more? I am interested in this alternative, but my experiences of the last year with also dont make me feel super optimistic about it.
I've thought that a user-space solution would be appropriate, too. But, a requirement of a daemon is a very big disadvantage (I believe many people would dislike). A plugin-based solution is another idea, but it's also complex and hard to implement consistently (because many mixer apps open "hw" device as default).
What I suggested is the implementation of a quite trivial master control. Of course, it's not so flexible but it covers most of hardwares. So much flexibility isn't needed in reality. The convenience (for user and developer) is more important.
I strongly favor this approach. I am interested in learning more about Jaroslav's daemon idea, but at this time it would need to really pleasantly surprise me for me to feel like it would be a better idea.
FWIW, i would be strongly opposed to making it a plugin. While i am very impressed with the technology of the plugin architecture, it's need to have all sound apps linked with alsalib for it to work poses significant complexity for both developers and users.
just my $us 0.02;
johnu
Takashi _______________________________________________ Alsa-devel mailing list Alsa-devel@alsa-project.org http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
participants (6)
-
Chuck Ebbert -
Jaroslav Kysela -
John Utz -
Maxim Levitsky -
Takashi Iwai -
Tellman, Steven