[alsa-devel] [PATCH] Remove psuedo master from pci/hda/analog_patch.c . It does not function well!
Hi I noticed after installing 1.0.16rc-1 today that my Thinkpad T61 with AD1984 had a Master mixer now. Problem is it's not very good in that it 1) does not follow with PCM (the real master) volume well. It causes a volume disparity and does not follow or even boost PCM signal. So it just a bad mister. 2) it does not mute the volume (since PCM is the real master mixer you have to go to PCM to mute the volume!)
I have fixed a problem in Gstreamer so that Gnome (gnome volume mixer) does finally work correctly for the AD1984 which does not have a Master. When it looks for a master mixer it now will fallback to PCM as a master mixer (the code is upsteam too). You can find this here:
http://bugzilla.gnome.org/show_bug.cgi?id=506928
I have a feeling this is why this patch was put in. I have fixed the problem in Gnome, KDE has allways worked. just fine.
But I would honestly love it if this code was removed!!! If you need a Master can you rename PCM to master for the AD1984! I have attached a patch to remove this code .. because it is so does not function well!
Signed-off-by : Jerone Young jerone@gmail.com
diff -r 5dfc8324ae17 alsa-kernel/pci/hda/patch_analog.c --- a/alsa-kernel/pci/hda/patch_analog.c Fri Jan 25 00:12:14 2008 -0600 +++ b/alsa-kernel/pci/hda/patch_analog.c Fri Jan 25 01:04:13 2008 -0600 @@ -170,26 +170,6 @@ static int ad198x_build_controls(struct } if (spec->dig_in_nid) { err = snd_hda_create_spdif_in_ctls(codec, spec->dig_in_nid); - 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; }
At Fri, 25 Jan 2008 01:11:38 -0600, Jerone Young wrote:
Hi I noticed after installing 1.0.16rc-1 today that my Thinkpad T61 with AD1984 had a Master mixer now. Problem is it's not very good in that it
- does not follow with PCM (the real master) volume well. It causes a
volume disparity and does not follow or even boost PCM signal. So it just a bad mister.
Hm, the PCM volume should follow the master even in the current code. Doesn't the output volume change if you change the master volume (not mute)? Please check the AMP out value of the NID 0x04 in /proc/asound/card0/codec#*. This corresponds to the PCM volume. Compare the values between master=100% and master=50%.
- it does not mute the volume (since PCM is the real master mixer you
have to go to PCM to mute the volume!)
There is no PCM "switch" to mute. It's a known problem and the patch below should fix.
I have fixed a problem in Gstreamer so that Gnome (gnome volume mixer) does finally work correctly for the AD1984 which does not have a Master. When it looks for a master mixer it now will fallback to PCM as a master mixer (the code is upsteam too). You can find this here:
http://bugzilla.gnome.org/show_bug.cgi?id=506928
I have a feeling this is why this patch was put in. I have fixed the problem in Gnome, KDE has allways worked. just fine.
But I would honestly love it if this code was removed!!! If you need a Master can you rename PCM to master for the AD1984!
PCM volume is no real master, unfortunately. The analog loopbacks can be played regardless of PCM volume. That's why it wasn't named as master at the first place.
I have attached a patch to remove this code .. because it is so does not function well!
(Can you stop! writing!! with!!! too much exclamation marks please?)
It's nothing but a bug that I overlooked. Let's fix this more reasonablly.
thanks,
Takashi
---
diff -r 303f894ac2a8 pci/hda/patch_analog.c --- a/pci/hda/patch_analog.c Thu Jan 24 18:46:42 2008 +0100 +++ b/pci/hda/patch_analog.c Fri Jan 25 08:42:21 2008 +0100 @@ -138,6 +138,7 @@ static const char *ad_slave_vols[] = { "Side Playback Volume", "Headphone Playback Volume", "Mono Playback Volume", + "Speaker Playback Volume", NULL };
@@ -149,6 +150,7 @@ static const char *ad_slave_sws[] = { "Side Playback Switch", "Headphone Playback Switch", "Mono Playback Switch", + "Speaker Playback Switch", NULL };
Ok less explication this time ;-) .. it was a late night. I have found something interesting though.
I took some time and actually evaluated the behavior of the Windows Vista Driver by Analog Devices was done for the AD1984. They do not have a PCM mixer, instead each indivdual application has there own mixer (this is a windows feature), and when you manipulate the individual mixer it manipulates the audio of that application. But there is not a PCM mixer for all apps. Just a Master. Also they have IEC958 (SDPIF) seen as a second sound device. It appears that they made what we call PCM the Master.
Now looking at our driver, it appears we should be doing the same. I actually have a good example why. If I am running playback through IEC958 (SDPIF) and I do anything to the PCM mixer it has no effect on PCM audio coming from applications that are running through IEC958. Only when I go to the application (assuming the application has it's own mixer code .. we will say VLC is a good example), does the actual PCM for that application get effected. So if I mute the PCM mixer, PCM audio runs over IEC958 without being muted, it only mutes it for speaker and the headphones.
What I see here is what we label as PCM is actually just the Master volume for Speaker & Headphones. But does not actually manipulate the PCM audio.
So really PCM really should be made Master Playback as it really does not manipulate PCM audio but just the how it is played back through Speaker & Headphones.
On Jan 25, 2008 1:56 AM, Takashi Iwai tiwai@suse.de wrote:
At Fri, 25 Jan 2008 01:11:38 -0600, Jerone Young wrote:
Hi I noticed after installing 1.0.16rc-1 today that my Thinkpad T61 with AD1984 had a Master mixer now. Problem is it's not very good in that it
- does not follow with PCM (the real master) volume well. It causes a
volume disparity and does not follow or even boost PCM signal. So it just a bad mister.
Hm, the PCM volume should follow the master even in the current code. Doesn't the output volume change if you change the master volume (not mute)? Please check the AMP out value of the NID 0x04 in /proc/asound/card0/codec#*. This corresponds to the PCM volume. Compare the values between master=100% and master=50%.
- it does not mute the volume (since PCM is the real master mixer you
have to go to PCM to mute the volume!)
There is no PCM "switch" to mute. It's a known problem and the patch below should fix.
I have fixed a problem in Gstreamer so that Gnome (gnome volume mixer) does finally work correctly for the AD1984 which does not have a Master. When it looks for a master mixer it now will fallback to PCM as a master mixer (the code is upsteam too). You can find this here:
http://bugzilla.gnome.org/show_bug.cgi?id=506928
I have a feeling this is why this patch was put in. I have fixed the problem in Gnome, KDE has allways worked. just fine.
But I would honestly love it if this code was removed!!! If you need a Master can you rename PCM to master for the AD1984!
PCM volume is no real master, unfortunately. The analog loopbacks can be played regardless of PCM volume. That's why it wasn't named as master at the first place.
I have attached a patch to remove this code .. because it is so does not function well!
(Can you stop! writing!! with!!! too much exclamation marks please?)
It's nothing but a bug that I overlooked. Let's fix this more reasonablly.
thanks,
Takashi
diff -r 303f894ac2a8 pci/hda/patch_analog.c --- a/pci/hda/patch_analog.c Thu Jan 24 18:46:42 2008 +0100 +++ b/pci/hda/patch_analog.c Fri Jan 25 08:42:21 2008 +0100 @@ -138,6 +138,7 @@ static const char *ad_slave_vols[] = { "Side Playback Volume", "Headphone Playback Volume", "Mono Playback Volume",
"Speaker Playback Volume", NULL};
@@ -149,6 +150,7 @@ static const char *ad_slave_sws[] = { "Side Playback Switch", "Headphone Playback Switch", "Mono Playback Switch",
"Speaker Playback Switch", NULL};
At Fri, 25 Jan 2008 07:41:48 -0600, Jerone Young wrote:
Ok less explication this time ;-) .. it was a late night. I have found something interesting though.
Thanks ;)
I took some time and actually evaluated the behavior of the Windows Vista Driver by Analog Devices was done for the AD1984. They do not have a PCM mixer, instead each indivdual application has there own mixer (this is a windows feature), and when you manipulate the individual mixer it manipulates the audio of that application. But there is not a PCM mixer for all apps. Just a Master. Also they have IEC958 (SDPIF) seen as a second sound device. It appears that they made what we call PCM the Master.
Maybe Windows driver doesn't use the analog loopback feature inside the codec, but does everything on software.
Now looking at our driver, it appears we should be doing the same. I actually have a good example why. If I am running playback through IEC958 (SDPIF) and I do anything to the PCM mixer it has no effect on PCM audio coming from applications that are running through IEC958. Only when I go to the application (assuming the application has it's own mixer code .. we will say VLC is a good example), does the actual PCM for that application get effected. So if I mute the PCM mixer, PCM audio runs over IEC958 without being muted, it only mutes it for speaker and the headphones.
OK now I see the problem. IEC958 isn't assigned to the master volume/switch list indeed.
What I see here is what we label as PCM is actually just the Master volume for Speaker & Headphones. But does not actually manipulate the PCM audio.
Correct. It's because the SPDIF has an individual (a sort of) DAC. So, we need to adjust this as well.
So really PCM really should be made Master Playback as it really does not manipulate PCM audio but just the how it is played back through Speaker & Headphones.
A fix is easy, but this might cause another problem when a non-audio signal is sent.
Could you try the patch below with the latest HG tree? (Or, you can apply this after my previous patch to 1.0.16-rc1.) If the SPDIF volume/switch are changed together with the master successfully, then please test AC3 or DTS output if possible. I'd like to know whether it breaks now. If it still works, I'll happily apply the patch to the upstream tree.
Thanks,
Takashi
---
diff -r 19029da61288 pci/hda/patch_analog.c --- a/pci/hda/patch_analog.c Fri Jan 25 11:56:57 2008 +0100 +++ b/pci/hda/patch_analog.c Fri Jan 25 15:04:01 2008 +0100 @@ -139,6 +139,7 @@ static const char *ad_slave_vols[] = { "Headphone Playback Volume", "Mono Playback Volume", "Speaker Playback Volume", + "IEC958 Playback Volume", NULL };
@@ -151,6 +152,7 @@ static const char *ad_slave_sws[] = { "Headphone Playback Switch", "Mono Playback Switch", "Speaker Playback Switch", + "IEC958 Playback Volume", NULL };
@@ -3078,6 +3080,7 @@ static const char *ad1884_slave_vols[] = "Internal Mic Playback Volume", "Docking Mic Playback Volume" "Beep Playback Volume", + "IEC958 Playback Volume", NULL };
I tested both patches. They work and master volume works for both Speakers & IEC958. It can controll up and down volume.
Speakers now mute.
One issue though when you mute the Master it does not mute IEC958. It will mute the speakers but not the IEC958 PCM stream. I am not sure if this desired behavior?
Oh also AC3 passthrough still works fine (you really can't manipulate this audio). I streamed some Doubly 5.1 streams over and they worked fine.
Besides that one issue you should put those 2 patches upstream.
On Jan 25, 2008 8:08 AM, Takashi Iwai tiwai@suse.de wrote:
At Fri, 25 Jan 2008 07:41:48 -0600, Jerone Young wrote:
Ok less explication this time ;-) .. it was a late night. I have found something interesting though.
Thanks ;)
I took some time and actually evaluated the behavior of the Windows Vista Driver by Analog Devices was done for the AD1984. They do not have a PCM mixer, instead each indivdual application has there own mixer (this is a windows feature), and when you manipulate the individual mixer it manipulates the audio of that application. But there is not a PCM mixer for all apps. Just a Master. Also they have IEC958 (SDPIF) seen as a second sound device. It appears that they made what we call PCM the Master.
Maybe Windows driver doesn't use the analog loopback feature inside the codec, but does everything on software.
Now looking at our driver, it appears we should be doing the same. I actually have a good example why. If I am running playback through IEC958 (SDPIF) and I do anything to the PCM mixer it has no effect on PCM audio coming from applications that are running through IEC958. Only when I go to the application (assuming the application has it's own mixer code .. we will say VLC is a good example), does the actual PCM for that application get effected. So if I mute the PCM mixer, PCM audio runs over IEC958 without being muted, it only mutes it for speaker and the headphones.
OK now I see the problem. IEC958 isn't assigned to the master volume/switch list indeed.
What I see here is what we label as PCM is actually just the Master volume for Speaker & Headphones. But does not actually manipulate the PCM audio.
Correct. It's because the SPDIF has an individual (a sort of) DAC. So, we need to adjust this as well.
So really PCM really should be made Master Playback as it really does not manipulate PCM audio but just the how it is played back through Speaker & Headphones.
A fix is easy, but this might cause another problem when a non-audio signal is sent.
Could you try the patch below with the latest HG tree? (Or, you can apply this after my previous patch to 1.0.16-rc1.) If the SPDIF volume/switch are changed together with the master successfully, then please test AC3 or DTS output if possible. I'd like to know whether it breaks now. If it still works, I'll happily apply the patch to the upstream tree.
Thanks,
Takashi
diff -r 19029da61288 pci/hda/patch_analog.c --- a/pci/hda/patch_analog.c Fri Jan 25 11:56:57 2008 +0100 +++ b/pci/hda/patch_analog.c Fri Jan 25 15:04:01 2008 +0100 @@ -139,6 +139,7 @@ static const char *ad_slave_vols[] = { "Headphone Playback Volume", "Mono Playback Volume", "Speaker Playback Volume",
"IEC958 Playback Volume", NULL};
@@ -151,6 +152,7 @@ static const char *ad_slave_sws[] = { "Headphone Playback Switch", "Mono Playback Switch", "Speaker Playback Switch",
"IEC958 Playback Volume", NULL};
@@ -3078,6 +3080,7 @@ static const char *ad1884_slave_vols[] = "Internal Mic Playback Volume", "Docking Mic Playback Volume" "Beep Playback Volume",
"IEC958 Playback Volume", NULL};
At Fri, 25 Jan 2008 08:37:35 -0600, Jerone Young wrote:
I tested both patches. They work and master volume works for both Speakers & IEC958. It can controll up and down volume.
Speakers now mute.
One issue though when you mute the Master it does not mute IEC958. It will mute the speakers but not the IEC958 PCM stream. I am not sure if this desired behavior?
No, it should be also controlled by the master switch.
Could you check the below
% amixer cget name="IEC958 Playback Switch"
whether this element exists. Then,
% amixer cset name="IEC958 Playback Switch" off
to turn the SPDIF off.
Oh also AC3 passthrough still works fine (you really can't manipulate this audio). I streamed some Doubly 5.1 streams over and they worked fine.
That's great. Then the things become really eaiser :)
Besides that one issue you should put those 2 patches upstream.
The first patch is already on HG tree. The second patch will be pushed soon.
thanks,
Takashi
On Jan 25, 2008 8:08 AM, Takashi Iwai tiwai@suse.de wrote:
At Fri, 25 Jan 2008 07:41:48 -0600, Jerone Young wrote:
Ok less explication this time ;-) .. it was a late night. I have found something interesting though.
Thanks ;)
I took some time and actually evaluated the behavior of the Windows Vista Driver by Analog Devices was done for the AD1984. They do not have a PCM mixer, instead each indivdual application has there own mixer (this is a windows feature), and when you manipulate the individual mixer it manipulates the audio of that application. But there is not a PCM mixer for all apps. Just a Master. Also they have IEC958 (SDPIF) seen as a second sound device. It appears that they made what we call PCM the Master.
Maybe Windows driver doesn't use the analog loopback feature inside the codec, but does everything on software.
Now looking at our driver, it appears we should be doing the same. I actually have a good example why. If I am running playback through IEC958 (SDPIF) and I do anything to the PCM mixer it has no effect on PCM audio coming from applications that are running through IEC958. Only when I go to the application (assuming the application has it's own mixer code .. we will say VLC is a good example), does the actual PCM for that application get effected. So if I mute the PCM mixer, PCM audio runs over IEC958 without being muted, it only mutes it for speaker and the headphones.
OK now I see the problem. IEC958 isn't assigned to the master volume/switch list indeed.
What I see here is what we label as PCM is actually just the Master volume for Speaker & Headphones. But does not actually manipulate the PCM audio.
Correct. It's because the SPDIF has an individual (a sort of) DAC. So, we need to adjust this as well.
So really PCM really should be made Master Playback as it really does not manipulate PCM audio but just the how it is played back through Speaker & Headphones.
A fix is easy, but this might cause another problem when a non-audio signal is sent.
Could you try the patch below with the latest HG tree? (Or, you can apply this after my previous patch to 1.0.16-rc1.) If the SPDIF volume/switch are changed together with the master successfully, then please test AC3 or DTS output if possible. I'd like to know whether it breaks now. If it still works, I'll happily apply the patch to the upstream tree.
Thanks,
Takashi
diff -r 19029da61288 pci/hda/patch_analog.c --- a/pci/hda/patch_analog.c Fri Jan 25 11:56:57 2008 +0100 +++ b/pci/hda/patch_analog.c Fri Jan 25 15:04:01 2008 +0100 @@ -139,6 +139,7 @@ static const char *ad_slave_vols[] = { "Headphone Playback Volume", "Mono Playback Volume", "Speaker Playback Volume",
"IEC958 Playback Volume", NULL};
@@ -151,6 +152,7 @@ static const char *ad_slave_sws[] = { "Headphone Playback Switch", "Mono Playback Switch", "Speaker Playback Switch",
"IEC958 Playback Volume", NULL};
@@ -3078,6 +3080,7 @@ static const char *ad1884_slave_vols[] = "Internal Mic Playback Volume", "Docking Mic Playback Volume" "Beep Playback Volume",
"IEC958 Playback Volume", NULL};
On Jan 25, 2008 9:02 AM, Takashi Iwai tiwai@suse.de wrote:
At Fri, 25 Jan 2008 08:37:35 -0600, Jerone Young wrote:
I tested both patches. They work and master volume works for both Speakers & IEC958. It can controll up and down volume.
Speakers now mute.
One issue though when you mute the Master it does not mute IEC958. It will mute the speakers but not the IEC958 PCM stream. I am not sure if this desired behavior?
No, it should be also controlled by the master switch.
Could you check the below
% amixer cget name="IEC958 Playback Switch"
It does exists
whether this element exists. Then,
% amixer cset name="IEC958 Playback Switch" offto turn the SPDIF off.
Yeap that worked. Using the command muted the IEC958.
So we see the it can be muted. But it's not cutting the stream when the virtual master mutes. Only the PCM stream gets cut, IEC958 stays unmuted.
Oh also AC3 passthrough still works fine (you really can't manipulate this audio). I streamed some Doubly 5.1 streams over and they worked fine.
That's great. Then the things become really eaiser :)
Besides that one issue you should put those 2 patches upstream.
The first patch is already on HG tree. The second patch will be pushed soon.
thanks,
Takashi
On Jan 25, 2008 8:08 AM, Takashi Iwai tiwai@suse.de wrote:
At Fri, 25 Jan 2008 07:41:48 -0600, Jerone Young wrote:
Ok less explication this time ;-) .. it was a late night. I have found something interesting though.
Thanks ;)
I took some time and actually evaluated the behavior of the Windows Vista Driver by Analog Devices was done for the AD1984. They do not have a PCM mixer, instead each indivdual application has there own mixer (this is a windows feature), and when you manipulate the individual mixer it manipulates the audio of that application. But there is not a PCM mixer for all apps. Just a Master. Also they have IEC958 (SDPIF) seen as a second sound device. It appears that they made what we call PCM the Master.
Maybe Windows driver doesn't use the analog loopback feature inside the codec, but does everything on software.
Now looking at our driver, it appears we should be doing the same. I actually have a good example why. If I am running playback through IEC958 (SDPIF) and I do anything to the PCM mixer it has no effect on PCM audio coming from applications that are running through IEC958. Only when I go to the application (assuming the application has it's own mixer code .. we will say VLC is a good example), does the actual PCM for that application get effected. So if I mute the PCM mixer, PCM audio runs over IEC958 without being muted, it only mutes it for speaker and the headphones.
OK now I see the problem. IEC958 isn't assigned to the master volume/switch list indeed.
What I see here is what we label as PCM is actually just the Master volume for Speaker & Headphones. But does not actually manipulate the PCM audio.
Correct. It's because the SPDIF has an individual (a sort of) DAC. So, we need to adjust this as well.
So really PCM really should be made Master Playback as it really does not manipulate PCM audio but just the how it is played back through Speaker & Headphones.
A fix is easy, but this might cause another problem when a non-audio signal is sent.
Could you try the patch below with the latest HG tree? (Or, you can apply this after my previous patch to 1.0.16-rc1.) If the SPDIF volume/switch are changed together with the master successfully, then please test AC3 or DTS output if possible. I'd like to know whether it breaks now. If it still works, I'll happily apply the patch to the upstream tree.
Thanks,
Takashi
diff -r 19029da61288 pci/hda/patch_analog.c --- a/pci/hda/patch_analog.c Fri Jan 25 11:56:57 2008 +0100 +++ b/pci/hda/patch_analog.c Fri Jan 25 15:04:01 2008 +0100 @@ -139,6 +139,7 @@ static const char *ad_slave_vols[] = { "Headphone Playback Volume", "Mono Playback Volume", "Speaker Playback Volume",
"IEC958 Playback Volume", NULL};
@@ -151,6 +152,7 @@ static const char *ad_slave_sws[] = { "Headphone Playback Switch", "Mono Playback Switch", "Speaker Playback Switch",
"IEC958 Playback Volume", NULL};
@@ -3078,6 +3080,7 @@ static const char *ad1884_slave_vols[] = "Internal Mic Playback Volume", "Docking Mic Playback Volume" "Beep Playback Volume",
"IEC958 Playback Volume", NULL};
I figured out the problem! Your patch is using "IEC958 Playback Volume" in ad_slave_sws[] & NOT "IEC958 Playback Switch". Simple cut & paste error (happens to me too). Testing with that fixed it works Here a fix on top of the patch you posted:
Signed-off-by: Jerone Young jerone@gmail.com diff -r acb7106d4779 alsa-kernel/pci/hda/patch_analog.c --- a/alsa-kernel/pci/hda/patch_analog.c Fri Jan 25 20:14:12 2008 -0600 +++ b/alsa-kernel/pci/hda/patch_analog.c Fri Jan 25 20:26:56 2008 -0600 @@ -152,7 +152,7 @@ static const char *ad_slave_sws[] = { "Headphone Playback Switch", "Mono Playback Switch", "Speaker Playback Switch", - "IEC958 Playback Volume", + "IEC958 Playback Switch", NULL };
On Jan 25, 2008 9:02 AM, Takashi Iwai tiwai@suse.de wrote:
At Fri, 25 Jan 2008 08:37:35 -0600, Jerone Young wrote:
I tested both patches. They work and master volume works for both Speakers & IEC958. It can controll up and down volume.
Speakers now mute.
One issue though when you mute the Master it does not mute IEC958. It will mute the speakers but not the IEC958 PCM stream. I am not sure if this desired behavior?
No, it should be also controlled by the master switch.
Could you check the below
% amixer cget name="IEC958 Playback Switch"whether this element exists. Then,
% amixer cset name="IEC958 Playback Switch" offto turn the SPDIF off.
Oh also AC3 passthrough still works fine (you really can't manipulate this audio). I streamed some Doubly 5.1 streams over and they worked fine.
That's great. Then the things become really eaiser :)
Besides that one issue you should put those 2 patches upstream.
The first patch is already on HG tree. The second patch will be pushed soon.
thanks,
Takashi
On Jan 25, 2008 8:08 AM, Takashi Iwai tiwai@suse.de wrote:
At Fri, 25 Jan 2008 07:41:48 -0600, Jerone Young wrote:
Ok less explication this time ;-) .. it was a late night. I have found something interesting though.
Thanks ;)
I took some time and actually evaluated the behavior of the Windows Vista Driver by Analog Devices was done for the AD1984. They do not have a PCM mixer, instead each indivdual application has there own mixer (this is a windows feature), and when you manipulate the individual mixer it manipulates the audio of that application. But there is not a PCM mixer for all apps. Just a Master. Also they have IEC958 (SDPIF) seen as a second sound device. It appears that they made what we call PCM the Master.
Maybe Windows driver doesn't use the analog loopback feature inside the codec, but does everything on software.
Now looking at our driver, it appears we should be doing the same. I actually have a good example why. If I am running playback through IEC958 (SDPIF) and I do anything to the PCM mixer it has no effect on PCM audio coming from applications that are running through IEC958. Only when I go to the application (assuming the application has it's own mixer code .. we will say VLC is a good example), does the actual PCM for that application get effected. So if I mute the PCM mixer, PCM audio runs over IEC958 without being muted, it only mutes it for speaker and the headphones.
OK now I see the problem. IEC958 isn't assigned to the master volume/switch list indeed.
What I see here is what we label as PCM is actually just the Master volume for Speaker & Headphones. But does not actually manipulate the PCM audio.
Correct. It's because the SPDIF has an individual (a sort of) DAC. So, we need to adjust this as well.
So really PCM really should be made Master Playback as it really does not manipulate PCM audio but just the how it is played back through Speaker & Headphones.
A fix is easy, but this might cause another problem when a non-audio signal is sent.
Could you try the patch below with the latest HG tree? (Or, you can apply this after my previous patch to 1.0.16-rc1.) If the SPDIF volume/switch are changed together with the master successfully, then please test AC3 or DTS output if possible. I'd like to know whether it breaks now. If it still works, I'll happily apply the patch to the upstream tree.
Thanks,
Takashi
diff -r 19029da61288 pci/hda/patch_analog.c --- a/pci/hda/patch_analog.c Fri Jan 25 11:56:57 2008 +0100 +++ b/pci/hda/patch_analog.c Fri Jan 25 15:04:01 2008 +0100 @@ -139,6 +139,7 @@ static const char *ad_slave_vols[] = { "Headphone Playback Volume", "Mono Playback Volume", "Speaker Playback Volume",
"IEC958 Playback Volume", NULL};
@@ -151,6 +152,7 @@ static const char *ad_slave_sws[] = { "Headphone Playback Switch", "Mono Playback Switch", "Speaker Playback Switch",
"IEC958 Playback Volume", NULL};
@@ -3078,6 +3080,7 @@ static const char *ad1884_slave_vols[] = "Internal Mic Playback Volume", "Docking Mic Playback Volume" "Beep Playback Volume",
"IEC958 Playback Volume", NULL};
At Fri, 25 Jan 2008 20:32:14 -0600, Jerone Young wrote:
I figured out the problem! Your patch is using "IEC958 Playback Volume" in ad_slave_sws[] & NOT "IEC958 Playback Switch". Simple cut & paste error (happens to me too). Testing with that fixed it works Here a fix on top of the patch you posted:
Signed-off-by: Jerone Young jerone@gmail.com
Doh! Thanks for spotting out. The fixed patch is now on HG tree.
Takashi
participants (2)
-
Jerone Young -
Takashi Iwai