[alsa-devel] Major reworks on patch_via.c (TESTERS WANTED)
Hi,
as there have many problems reported for VIA codecs, I started looking at the driver code, and decided to rework on it.
The current development is found in sound git tree topic/via-cleanup branch: git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound-2.6.git
You can pull into the latest Linus tree from topic/via-cleanup branch: # this is the vanilla tree % cd linux-2.6 % git pull \ git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound-2.6.git \ topic/via-cleanup
A good thing is that a fair amount of code reduction is done there:
% git diff HEAD..topic/via-cleanup --stat sound/pci/hda/patch_via.c sound/pci/hda/patch_via.c | 5892 +++++++++++---------------------------------- 1 files changed, 1453 insertions(+), 4439 deletions(-)
But, the driver isn't tested with real machines, yet. That is, I need testers with real machines.
Could VIA machine owners take a look at these commits and test it if possible? Especially, I'd like to know whether the headphone auto-mute works in this form or not.
FWIW, the branch was merged to sound-unstable tree, so you can build from alsa-driver-unstable snapshot tarball if you'd like to build external modules without the kernel tree and git-merge. ftp://ftp.kernel.org/pub/linux/kernel/people/tiwai/snapshot/alsa-driver-unstable-snapshot.tar.gz
Also, if anyone has alsa-info.sh outputs of VIA codecs, please let me know. It'd be very helpful for debugging, since I can check it via hda-emu with alsa-info.sh output. For now, I have the files of only VT1702, VT1708S, VT1718S, VT1828S and VT2020 codecs. The alsa-info.sh outputs of other VIA codecs would be greatly appreciated.
thanks,
Takashi
At Mon, 20 Jun 2011 17:06:51 +0200, Takashi Iwai wrote:
Hi,
as there have many problems reported for VIA codecs, I started looking at the driver code, and decided to rework on it.
The current development is found in sound git tree topic/via-cleanup branch: git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound-2.6.git
BTW, this changes the logic of detecting the HP-independent stream and smart51 pins. So, beware possible regressions or behavior changes regarding them. At least, the handling of the side/HP shared channel is missing for now.
thanks,
Takashi
On 2011-06-20 17:06, Takashi Iwai wrote:
Hi,
as there have many problems reported for VIA codecs, I started looking at the driver code, and decided to rework on it.
Excellent initiative, thanks!
The current development is found in sound git tree topic/via-cleanup branch: git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound-2.6.git
You can pull into the latest Linus tree from topic/via-cleanup branch: # this is the vanilla tree % cd linux-2.6 % git pull \ git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound-2.6.git \ topic/via-cleanup
The tree as of today, is now also available for easy testing for Ubuntu users: Just download and install http://people.canonical.com/~diwic/temp/alsa-hda-dkms-viacleanup_0.1_all.deb (works at least on Ubuntu 10.10 and 11.04), reboot and test.
But, the driver isn't tested with real machines, yet. That is, I need testers with real machines.
Could VIA machine owners take a look at these commits and test it if possible? Especially, I'd like to know whether the headphone auto-mute works in this form or not.
I have tested the new driver code on a machine here, and automute does work. There is however no enable/disable automute yet, as Realtek has. There are no input jack devices either (i e those we're debating in the other thread).
On the input side I notice a minor thing: "Front Mic Playback Volume" has an unneccessary index on it. Well, the Front mic is actually an internal mic, but that's BIOS lying to us, I guess.
Otherwise it seems to work fine here, so well done! :-)
Also, if anyone has alsa-info.sh outputs of VIA codecs, please let me know. It'd be very helpful for debugging, since I can check it via hda-emu with alsa-info.sh output. For now, I have the files of only VT1702, VT1708S, VT1718S, VT1828S and VT2020 codecs. The alsa-info.sh outputs of other VIA codecs would be greatly appreciated.
Alsa-info for the machine I have here will follow shortly.
At Tue, 21 Jun 2011 12:01:16 +0200, David Henningsson wrote:
On 2011-06-20 17:06, Takashi Iwai wrote:
Hi,
as there have many problems reported for VIA codecs, I started looking at the driver code, and decided to rework on it.
Excellent initiative, thanks!
The current development is found in sound git tree topic/via-cleanup branch: git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound-2.6.git
You can pull into the latest Linus tree from topic/via-cleanup branch: # this is the vanilla tree % cd linux-2.6 % git pull \ git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound-2.6.git \ topic/via-cleanup
The tree as of today, is now also available for easy testing for Ubuntu users: Just download and install http://people.canonical.com/~diwic/temp/alsa-hda-dkms-viacleanup_0.1_all.deb (works at least on Ubuntu 10.10 and 11.04), reboot and test.
Thanks!
But, the driver isn't tested with real machines, yet. That is, I need testers with real machines.
Could VIA machine owners take a look at these commits and test it if possible? Especially, I'd like to know whether the headphone auto-mute works in this form or not.
I have tested the new driver code on a machine here, and automute does work. There is however no enable/disable automute yet, as Realtek has.
Right. This will be for future.
There are no input jack devices either (i e those we're debating in the other thread).
I haven't tracked this fully yet; can anyone give a short summary and alsa-info.sh output of the affected system?
On the input side I notice a minor thing: "Front Mic Playback Volume" has an unneccessary index on it. Well, the Front mic is actually an internal mic, but that's BIOS lying to us, I guess.
Fixed now in topic/via-cleanup branch. Also the smart51 detection and some output-path initializations were fixed.
Otherwise it seems to work fine here, so well done! :-)
Also, if anyone has alsa-info.sh outputs of VIA codecs, please let me know. It'd be very helpful for debugging, since I can check it via hda-emu with alsa-info.sh output. For now, I have the files of only VT1702, VT1708S, VT1718S, VT1828S and VT2020 codecs. The alsa-info.sh outputs of other VIA codecs would be greatly appreciated.
Alsa-info for the machine I have here will follow shortly.
Thanks, that's appreciated.
Takashi
On 2011-06-21 13:01, Takashi Iwai wrote:
There are no input jack devices either (i e those we're debating in the other thread).
I haven't tracked this fully yet; can anyone give a short summary and alsa-info.sh output of the affected system?
I mean, there are no calls to snd_hda_input_jack_* from patch_via.c yet.
You should have received alsa-info in a private email by now.
On the input side I notice a minor thing: "Front Mic Playback Volume" has an unneccessary index on it. Well, the Front mic is actually an internal mic, but that's BIOS lying to us, I guess.
Fixed now in topic/via-cleanup branch. Also the smart51 detection and some output-path initializations were fixed.
Btw, I have not tested the smart51 / independent HP stuff.
At Tue, 21 Jun 2011 13:38:12 +0200, David Henningsson wrote:
On 2011-06-21 13:01, Takashi Iwai wrote:
There are no input jack devices either (i e those we're debating in the other thread).
I haven't tracked this fully yet; can anyone give a short summary and alsa-info.sh output of the affected system?
I mean, there are no calls to snd_hda_input_jack_* from patch_via.c yet.
Ah, I understand. Yeah, it's also missing.
You should have received alsa-info in a private email by now.
Yes, I got it. Thanks.
On the input side I notice a minor thing: "Front Mic Playback Volume" has an unneccessary index on it. Well, the Front mic is actually an internal mic, but that's BIOS lying to us, I guess.
Fixed now in topic/via-cleanup branch. Also the smart51 detection and some output-path initializations were fixed.
Btw, I have not tested the smart51 / independent HP stuff.
I guess smart51 should work now, but not sure about independent HP. I'll check hda-emu with your info.
thanks,
Takashi
Am Montag, 20. Juni 2011, 17:06:51 schrieb Takashi Iwai:
Hi,
as there have many problems reported for VIA codecs, I started looking at the driver code, and decided to rework on it.
The current development is found in sound git tree topic/via-cleanup branch: git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound-2.6.git
You can pull into the latest Linus tree from topic/via-cleanup branch: # this is the vanilla tree % cd linux-2.6 % git pull \ git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound-2.6.git \ topic/via-cleanup
A good thing is that a fair amount of code reduction is done there:
% git diff HEAD..topic/via-cleanup --stat sound/pci/hda/patch_via.c sound/pci/hda/patch_via.c | 5892 +++++++++++---------------------------------- 1 files changed, 1453 insertions(+), 4439 deletions(-)
But, the driver isn't tested with real machines, yet. That is, I need testers with real machines.
Could VIA machine owners take a look at these commits and test it if possible? Especially, I'd like to know whether the headphone auto-mute works in this form or not.
I will have a look at this. On a related note, I am experiencing a bug regarding SPDIF output as described here: https://bugtrack.alsa-project.org/alsa-bug/view.php?id=4330 If this could be fixed within this rework, it would be greatly appreciated.
FWIW, the branch was merged to sound-unstable tree, so you can build from alsa-driver-unstable snapshot tarball if you'd like to build external modules without the kernel tree and git-merge.
ftp://ftp.kernel.org/pub/linux/kernel/people/tiwai/snapshot/alsa-driver-un stable-snapshot.tar.gz
Also, if anyone has alsa-info.sh outputs of VIA codecs, please let me know. It'd be very helpful for debugging, since I can check it via hda-emu with alsa-info.sh output. For now, I have the files of only VT1702, VT1708S, VT1718S, VT1828S and VT2020 codecs. The alsa-info.sh outputs of other VIA codecs would be greatly appreciated.
You can find the info-alsa.sh output for my VIA VT1708B 8-Ch at http://www.alsa-project.org/db/?f=05281895eb77de2a22257e27fb2ecab1a959cb92
thanks,
Takashi
-- Jan Binder
At Wed, 22 Jun 2011 10:02:25 +0200, Jan Binder wrote:
Am Montag, 20. Juni 2011, 17:06:51 schrieb Takashi Iwai:
Hi,
as there have many problems reported for VIA codecs, I started looking at the driver code, and decided to rework on it.
The current development is found in sound git tree topic/via-cleanup branch: git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound-2.6.git
You can pull into the latest Linus tree from topic/via-cleanup branch: # this is the vanilla tree % cd linux-2.6 % git pull \ git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound-2.6.git \ topic/via-cleanup
A good thing is that a fair amount of code reduction is done there:
% git diff HEAD..topic/via-cleanup --stat sound/pci/hda/patch_via.c sound/pci/hda/patch_via.c | 5892 +++++++++++---------------------------------- 1 files changed, 1453 insertions(+), 4439 deletions(-)
But, the driver isn't tested with real machines, yet. That is, I need testers with real machines.
Could VIA machine owners take a look at these commits and test it if possible? Especially, I'd like to know whether the headphone auto-mute works in this form or not.
I will have a look at this. On a related note, I am experiencing a bug regarding SPDIF output as described here: https://bugtrack.alsa-project.org/alsa-bug/view.php?id=4330 If this could be fixed within this rework, it would be greatly appreciated.
The SPDIF should work now. At least, hda-emu shows the devices.
FWIW, the branch was merged to sound-unstable tree, so you can build from alsa-driver-unstable snapshot tarball if you'd like to build external modules without the kernel tree and git-merge.
ftp://ftp.kernel.org/pub/linux/kernel/people/tiwai/snapshot/alsa-driver-un stable-snapshot.tar.gz
Also, if anyone has alsa-info.sh outputs of VIA codecs, please let me know. It'd be very helpful for debugging, since I can check it via hda-emu with alsa-info.sh output. For now, I have the files of only VT1702, VT1708S, VT1718S, VT1828S and VT2020 codecs. The alsa-info.sh outputs of other VIA codecs would be greatly appreciated.
You can find the info-alsa.sh output for my VIA VT1708B 8-Ch at http://www.alsa-project.org/db/?f=05281895eb77de2a22257e27fb2ecab1a959cb92
Great, thanks.
Takashi
At Mon, 20 Jun 2011 17:06:51 +0200, Takashi Iwai wrote:
Hi,
as there have many problems reported for VIA codecs, I started looking at the driver code, and decided to rework on it.
The current development is found in sound git tree topic/via-cleanup branch: git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound-2.6.git
You can pull into the latest Linus tree from topic/via-cleanup branch: # this is the vanilla tree % cd linux-2.6 % git pull \ git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound-2.6.git \ topic/via-cleanup
A good thing is that a fair amount of code reduction is done there:
% git diff HEAD..topic/via-cleanup --stat sound/pci/hda/patch_via.c sound/pci/hda/patch_via.c | 5892 +++++++++++---------------------------------- 1 files changed, 1453 insertions(+), 4439 deletions(-)
But, the driver isn't tested with real machines, yet. That is, I need testers with real machines.
Could VIA machine owners take a look at these commits and test it if possible? Especially, I'd like to know whether the headphone auto-mute works in this form or not.
FWIW, the branch was merged to sound-unstable tree, so you can build from alsa-driver-unstable snapshot tarball if you'd like to build external modules without the kernel tree and git-merge. ftp://ftp.kernel.org/pub/linux/kernel/people/tiwai/snapshot/alsa-driver-unstable-snapshot.tar.gz
Also, if anyone has alsa-info.sh outputs of VIA codecs, please let me know. It'd be very helpful for debugging, since I can check it via hda-emu with alsa-info.sh output. For now, I have the files of only VT1702, VT1708S, VT1718S, VT1828S and VT2020 codecs. The alsa-info.sh outputs of other VIA codecs would be greatly appreciated.
I implemented the dynamic ADC switching, mainly for VT1702 machines with the digital-mic connection like Gateway or Packard-Bell laptops.
When you have such a machine, i.e. an internal-mic input that doesn't work as default properly, give it a try.
What I can implement more in a short time frame would be: - The automatic input switching for int-/ext-mics on laptop - Auto-mute Mode enum like in Realtek codec driver
Also, the rewrite of set_widgets_power_state() would be nice. We can use the parsed input/output-paths for determining whether each widget can be turned down or not.
In anyways, any positive / negative feedbacks or tests would be appreciated. When no big problem is found, I'm going to merge the new code in the next week or next-next week.
(And yes, I'm still gathering alsa-info.sh outputs of VIA codecs; please contribute them if you have!)
thanks,
Takashi
2011/6/22 Takashi Iwai tiwai@suse.de:
At Mon, 20 Jun 2011 17:06:51 +0200, Takashi Iwai wrote:
Hi,
as there have many problems reported for VIA codecs, I started looking at the driver code, and decided to rework on it. [...]
I've installed and tested (from tarballs) both snapshot alsa-driver-20110630 and latest version (alsa-driver-snapshot.tar.gz) - up to commit e5e14681404ec27a422d635284bf564dabde3f81 by Lydia Wang, I think.
I've found problems with both. That's a quite huge change in the implementation from older code, so I need to study it more in depth to understand it better... At the moment I can only describe the problems and give my first impressions on them.
First of all, I can't get sound from the front playback (rear line-out). It would seem there's no problem opening the pcm and setting the stream; If I switch Independent HP mode off, I can listen to anything from my front audio panel (though with the old implementation I could switch it on and off repeatedly and ensure that sound came only from front dac (0x8), now the imux is 'blocked' as busy while playing and it would seem the same stream is sent to hp dac as well, even if its corresponding audio selector switches to front dac - 0x8 - so hp shouldn't get sound by 0xb when in redirected mode; perhaps I should add a few printk calls to snd_hda_multi_out_analog_prepare() or snd_hda_codec_setup_stream() to see what happens for nid 0x8, though I think it works, and maybe I can confirm it indirectly).
Could there be the need to update cached values somewhere in the code? Perhaps where certain nids are un-muted? I had a similar problem (with the old implementation) while trying to create a pair or input muxs to enable/disable the AA-path and avoid getting noisy feedback from my headset mic (such as hearing my breath). For my codec (and a few others - AFAICT, all flavours of VT1718S, all flavours of VT2002P and VT1812) it was a matter of muting/un-muting the input from 0x21 (stereo mixer) to each mixer widget sending output to my green jacks; however, trying to send a direct verb to those widgets I got some problems I solved by calling snd_hda_codec_amp_stereo(), which updates cached values as well (I had sent a mail with code slices to the list, but it might have gone lost, because I cannot find a link in the archives, just in case anyone wished to give it a look). Is there a chance that a few calls to snd_hda_codec_write are not enough alone, in this new implementation of the driver? Though it should be relevant only if retrieving correct values for volumes is important for correct handling of a stream setup (that is, if any decision is took basing on results of a read operation on volumes), otherwise there could be some error in nids' path parsing.
Second: Independent HP mode doesn't work as well - tested with aplay -Dhw:0,2,0, since now a separate pcm device is created for headphones. However, this is easy to fix, since it's just a matter of nid mismatching in set_widgets_power_state_vt1718S():
...
if (spec->hp_independent_mode) { /* PW4 (28h), MW3 (1bh), MUX1(34h), AOW4 (ch) */ parm = AC_PWRST_D3; set_pin_power_state(codec, 0x28, &parm); snd_hda_codec_write(codec, 0x1b, 0, AC_VERB_SET_POWER_STATE, parm); snd_hda_codec_write(codec, 0x34, 0, AC_VERB_SET_POWER_STATE, parm); - snd_hda_codec_write(codec, 0xc, 0, + snd_hda_codec_write(codec, spec->hp_dac_nid, 0, AC_VERB_SET_POWER_STATE, parm); } }
By the way, in old code I had made a few changes to this function basing on following considerations - which could no more apply, so I'm posting the code below just to compare notes:
- this codec (family) has two adc's that seem to be 'almost independent', meaning AIW1 (nid 0x11, coupled with MUX7, nid 0x1f), if not in use, could be in state D3 while AIW0 (nid 0x10, coupled with MUX6, nid 0x1e) is in D0, whereas the opposite should be avoided, since mic boost controls and digital (mic) seem to be bound to AIW0; moreover, MUX7 could be connected to stereo mixer, and this should be taken into account when setting state for 0x21;
- when in redirected mode, hp Pin Widget (nid 0x28) should get input only from front dac (nid 0x8) as selected by Audio Selector 0x34, thus hp dac (0x0c or 0x0b) could be set in D3, and, if nothing is connected to it (to 0x28) both Mixer 0x1b and MUX 0x34 could be set in D3 independently from state of pin 0x24 (front).
static void set_widgets_power_state_vt1718S(struct hda_codec *codec) { struct via_spec *spec = codec->spec; unsigned int imux_is_smixer[ 2 ]; unsigned int parm, parm_mux[ 2 ] = { AC_PWRST_D3, AC_PWRST_D3 }; unsigned int imux_conn[2];
/* get connection for MUX 6/7 (1eh/1fh) */ imux_conn[ 0 ] = snd_hda_codec_read(codec, 0x1e, 0, AC_VERB_GET_CONNECT_SEL, 0x00); imux_conn[ 1 ] = snd_hda_codec_read(codec, 0x1f, 0, AC_VERB_GET_CONNECT_SEL, 0x00); /* MUX 6/7 (1eh/1fh) = stereo mixer ? */ imux_is_smixer[ 0 ] = ( imux_conn[ 0 ] == 5 ); imux_is_smixer[ 1 ] = ( imux_conn[ 1 ] == 5 );
/* inputs */ /* PW 5/6/7 (29h/2ah/2bh) */ parm = AC_PWRST_D3; set_pin_power_state(codec, 0x29, &parm); if( imux_conn[ 0 ] == 3 ) /* MUX6 (1eh) connected to 0x29 */ parm_mux[ 0 ] = parm; if( imux_conn[ 1 ] == 3 ) /* MUX7 (1fh) connected to 0x29 */ parm_mux[ 1 ] = parm;
parm = AC_PWRST_D3; set_pin_power_state(codec, 0x2a, &parm); if( imux_conn[ 0 ] == 2 ) /* MUX6 (1eh) connected to 0x2a */ parm_mux[ 0 ] = parm; if( imux_conn[ 1 ] == 2 ) /* MUX7 (1fh) connected to 0x2a */ parm_mux[ 1 ] = parm;
parm = AC_PWRST_D3; set_pin_power_state(codec, 0x2b, &parm); if( imux_conn[ 0 ] == 1 ) /* MUX6 (1eh) connected to 0x2b */ parm_mux[ 0 ] = parm; if( imux_conn[ 1 ] == 1 ) /* MUX7 (1fh) connected to 0x2b */ parm_mux[ 1 ] = parm;
/* MUX6 (1eh) = stereo mixer */ if( imux_is_smixer[ 0 ] ) parm_mux[ 0 ] = AC_PWRST_D0; /* MUX7 (1fh) = stereo mixer */ if( imux_is_smixer[ 1 ] ) parm_mux[ 1 ] = AC_PWRST_D0; /* this codec has switches for front/rear boost captures and digital mic binded to AIW0 (10h) */ /* therefore, if those are needed when using stuff connected to MUX7 (1fh), MUX6 must be on*/ if( parm_mux[ 1 ] == AC_PWRST_D0 ) parm_mux[ 0 ] = parm_mux[ 1 ];
/* MUX6/7 (1eh/1fh), AIW 0/1 (10h/11h) */ snd_hda_codec_write( codec, 0x1e, 0, AC_VERB_SET_POWER_STATE, parm_mux[ 0 ] ); snd_hda_codec_write( codec, 0x10, 0, AC_VERB_SET_POWER_STATE, parm_mux[ 0 ] ); snd_hda_codec_write( codec, 0x1f, 0, AC_VERB_SET_POWER_STATE, parm_mux[ 1 ] ); snd_hda_codec_write( codec, 0x11, 0, AC_VERB_SET_POWER_STATE, parm_mux[ 1 ] );
/* outputs */ /* PW3 (27h), MW2 (1ah), AOW3 (bh) */ parm = AC_PWRST_D3; set_pin_power_state(codec, 0x27, &parm); snd_hda_codec_write(codec, 0x1a, 0, AC_VERB_SET_POWER_STATE, parm); snd_hda_codec_write(codec, 0xb, 0, AC_VERB_SET_POWER_STATE, parm);
/* PW2 (26h), AOW2 (ah) */ parm = AC_PWRST_D3; set_pin_power_state(codec, 0x26, &parm); if (spec->smart51_enabled) set_pin_power_state(codec, 0x2b, &parm); snd_hda_codec_write(codec, 0xa, 0, AC_VERB_SET_POWER_STATE, parm);
/* PW0 (24h), AOW0 (8h) */ parm = AC_PWRST_D3; set_pin_power_state(codec, 0x24, &parm); if (!spec->hp_independent_mode){ /* check for redirected HP */ unsigned int parm_hp = AC_PWRST_D3; set_pin_power_state( codec, 0x28, &parm_hp ); snd_hda_codec_write( codec, 0x1b, 0, AC_VERB_SET_POWER_STATE, parm_hp ); snd_hda_codec_write( codec, 0x34, 0, AC_VERB_SET_POWER_STATE, parm_hp ); /* in redirected mode, hp_nid isn't in use */ snd_hda_codec_write( codec, spec->multiout.hp_nid, 0, AC_VERB_SET_POWER_STATE, AC_PWRST_D3 ); if( parm_hp == AC_PWRST_D0 ) parm = AC_PWRST_D0; } snd_hda_codec_write(codec, 0x8, 0, AC_VERB_SET_POWER_STATE, parm);
/* MW9 (21h), Mw2 (1ah), AOW0 (8h) */ /* don't understand above comment - may guess dependence on front dac, but am unsure... and can't see any dependence on MW 1ah */ snd_hda_codec_write( codec, 0x21, 0, AC_VERB_SET_POWER_STATE, imux_is_smixer[ 0 ] || imux_is_mixer[ 1 ] ? AC_PWRST_D0 : parm );
/* PW1 (25h), AOW1 (9h) */ parm = AC_PWRST_D3; set_pin_power_state(codec, 0x25, &parm); if (spec->smart51_enabled) set_pin_power_state(codec, 0x2a, &parm); snd_hda_codec_write(codec, 0x9, 0, AC_VERB_SET_POWER_STATE, parm);
if (spec->hp_independent_mode) { /* PW4 (28h), MW3 (1bh), MUX1(34h), AOW4 (ch) */ parm = AC_PWRST_D3; set_pin_power_state(codec, 0x28, &parm); snd_hda_codec_write(codec, 0x1b, 0, AC_VERB_SET_POWER_STATE, parm); snd_hda_codec_write(codec, 0x34, 0, AC_VERB_SET_POWER_STATE, parm); snd_hda_codec_write(codec, spec->multiout.hp_nid, 0, AC_VERB_SET_POWER_STATE, parm); } }
(if applicable to actual implementation, any occurrence of spec->multiout.hp_nid should be replaced with spec->hp_dac_nid - the above doesn't yet take care of the possible re-tasking of line-in as side, which I didn't try)
----
But let's come back to current state. There could be an initialization verb missing from array vt1718S_init_verbs and present in old vt1718S_volume_init_verbs, which is "almost" a vendor-specific verb, to un-mute the apparently non-existent (not seen by the driver) connection at index #5 for stereo mixer (0x21):
static const struct hda_verb vt1718S_init_verbs[] = { /* Enable MW0 adjust Gain 5 */ {0x1, 0xfb2, 0x10}, /* Enable Boost Volume backdoor */ {0x1, 0xf88, 0x8}, + /* Unmute front dac connection to stereo mixer */ + {0x21, AC_VERB_SET_AMP_GAIN_MUTE, AMP_IN_UNMUTE(5)},
{ } };
If I remember well what Lydia Wang told me in another thread, 0x21 is connected to a dac (should be the front dac), even if the connection isn't visible through the driver. Without that verb, if I set 'stereo mixer' as first input source and try to record some playback, I get only noise, with such initialization I can record an ongoing playback (eventually mixed with other sound, e.g. from my mic). Such a result tells me nid 0x8 (front dac, the only involved in my recording test) should work properly even if no sound gets to front line-out pin (0x24). A side effect of this, however, is that, depending on volumes settings, whatever widget getting input also by 0x21 (and if such connection isn't muted), will get sound by 0x8 while playing - e.g. I can hear, at a lower volume, a playback setup for the front dac from my headset even when Independent HP is set to ON; on the other hand, lowering volumes attenuates such, but playback may become unrecordable (due to volume being too low).
I'm attaching alsa-info.sh output for both the original version of this new implementation (latest version from tarballs, described at the beginning) and the modified version I'm using to both make Independent HP work and activate that "hidden" connection for stereo mixer. Though, it looks like they don't tell much about the problem with front audio from front pin (I've compiled drivers with verbose debug).
One notably thing is that the new (for codec VT1718S family) Master control misses a few slaves, mainly:
- as expectable, there's neither a "Side Playback Volume" nor a "Side Playback Switch", since there's no grey jack (to support 7.1 systems, my motherboard line-in (0x2a) should be re-tasked as output and get input from the now available 0xc, which is no more used by headphones)
- more noticeably, there's no "Headphone Playback Volume" control. There was one in old implementation, explicitly created by vt1718S_auto_create_hp_ctls(); within that function it was easy to bind that control to the actual hp_nid (replacing any occurrence of 0xc with spec->multiout.hp_nid in all relevant functions, the switch from 0xc to 0xb was complete), given that the only reason to test usability of dac at 0xb for headphone was, initially, to check whether 0xc could be freed for use with 0x2a as side (and ensure, or confirm, this codec family can handle as much as 10 channels - but to confirm it definitely an attempt to retask 0x2a should be made).
Moreover, looking at codec informations, now control "Independent HP" is attached to hp pin, altogether with control "Headphone Playback Switch". This should be somehow more consistent with those codecs not using an intermidiate selector to choose the nid to get sound from (perhaps the majority), so that such control always sticks in same (or corresponding) places. However, this way there is more 'distance' between such control and the 'real' nid it works on.
A final (minor) question/consideration on the code. I've noticed now .put helpers validate data gathered from userspace (typically, passed through ucontrol parameter), which is a good choice to protect against some bug external to the driver; however, if I'm not mistaken, via_mux_enum_put (and corresponding _get) could still be missing something: since any data in ucontrol->id is passed as is to snd_ctl_get_ioffidx, is there any chance that the result could be an invalid index? If that's possible, perhaps such value should be validated as well, comparing it to the max number of mux nids, eventually defined in a constant for easier maintenance, such as:
#define VIA_NUM_MUXS 3
then, in struct via_spec:
- hda_nid_t mux_nids[3]; + hda_nid_t mux_nids[ VIA_NUM_MUXS ]; hda_nid_t aa_mix_nid;
...
struct via_input inputs[AUTO_CFG_MAX_INS + 1]; - unsigned int cur_mux[3]; + unsigned int cur_mux[ VIA_NUM_MUXS ];
then, in via_mux_enum_put() (same for via_mux_enum_get)
either:
if( idx >= VIA_NUM_MUXS ) return -EINVAL;
or:
if( idx >= VIA_NUM_MUXS ) /* recovering from wrong value, assuming the last valid entry was the real target */ idx = VIA_NUM_MUXS -1;
(more applicable for via_mux_enum_get)
The latter strategy suggested by analogy with similar implementation of data correctness control in snd_hda_input_mux_put (previously used) and by comparison with other recovery attempts made in .put helpers, such as double negation of ucontrol->value.enumerated.item[0] in via_independent_hp_put and the single negation in via_pin_power_ctl_{get, put} to always get one of the two only possible values in that contexts (0 or 1). Perhaps the same should be done in via_smart51_put() as well, to 'normalize' *ucontrol->value.integer.value as boolean before assigning it to spec->smart51_enabled, maybe returning immediately if old and new values match against each other (as done in via_independent_hp_put and via_pin_power_ctl_put) -- Possibly, the same might apply to vt1716s_dmic_{get,put} helpers, but only if nid 0x26 had just two connections (I was considering it for the old code too, but I haven't been able to find any info about VT1716S).
Regards,
Alex
At Sat, 2 Jul 2011 18:00:27 +0200, alex dot baldacchino dot alsasub at gmail dot com wrote:
2011/6/22 Takashi Iwai tiwai@suse.de:
At Mon, 20 Jun 2011 17:06:51 +0200, Takashi Iwai wrote:
Hi,
as there have many problems reported for VIA codecs, I started looking at the driver code, and decided to rework on it. [...]
I've installed and tested (from tarballs) both snapshot alsa-driver-20110630 and latest version (alsa-driver-snapshot.tar.gz)
- up to commit e5e14681404ec27a422d635284bf564dabde3f81 by Lydia Wang,
I think.
I've found problems with both. That's a quite huge change in the implementation from older code, so I need to study it more in depth to understand it better... At the moment I can only describe the problems and give my first impressions on them.
First of all, I can't get sound from the front playback (rear line-out).
...
If I remember well what Lydia Wang told me in another thread, 0x21 is connected to a dac (should be the front dac), even if the connection isn't visible through the driver. Without that verb, if I set 'stereo mixer' as first input source and try to record some playback, I get only noise, with such initialization I can record an ongoing playback (eventually mixed with other sound, e.g. from my mic). Such a result tells me nid 0x8 (front dac, the only involved in my recording test) should work properly even if no sound gets to front line-out pin (0x24). A side effect of this, however, is that, depending on volumes settings, whatever widget getting input also by 0x21 (and if such connection isn't muted), will get sound by 0x8 while playing - e.g. I can hear, at a lower volume, a playback setup for the front dac from my headset even when Independent HP is set to ON; on the other hand, lowering volumes attenuates such, but playback may become unrecordable (due to volume being too low).
These should be fixed now by Lydia's patch. I updated sound git tree and snapshot tarball now. Please check it later.
One notably thing is that the new (for codec VT1718S family) Master control misses a few slaves, mainly:
- as expectable, there's neither a "Side Playback Volume" nor a "Side
Playback Switch", since there's no grey jack (to support 7.1 systems, my motherboard line-in (0x2a) should be re-tasked as output and get input from the now available 0xc, which is no more used by headphones)
- more noticeably, there's no "Headphone Playback Volume" control.
There was one in old implementation, explicitly created by vt1718S_auto_create_hp_ctls(); within that function it was easy to bind that control to the actual hp_nid (replacing any occurrence of 0xc with spec->multiout.hp_nid in all relevant functions, the switch from 0xc to 0xb was complete), given that the only reason to test usability of dac at 0xb for headphone was, initially, to check whether 0xc could be freed for use with 0x2a as side (and ensure, or confirm, this codec family can handle as much as 10 channels - but to confirm it definitely an attempt to retask 0x2a should be made).
Moreover, looking at codec informations, now control "Independent HP" is attached to hp pin, altogether with control "Headphone Playback Switch". This should be somehow more consistent with those codecs not using an intermidiate selector to choose the nid to get sound from (perhaps the majority), so that such control always sticks in same (or corresponding) places. However, this way there is more 'distance' between such control and the 'real' nid it works on.
Hm, I'll check this with your alsa-info.sh output.
A final (minor) question/consideration on the code. I've noticed now .put helpers validate data gathered from userspace (typically, passed through ucontrol parameter), which is a good choice to protect against some bug external to the driver; however, if I'm not mistaken, via_mux_enum_put (and corresponding _get) could still be missing something: since any data in ucontrol->id is passed as is to snd_ctl_get_ioffidx, is there any chance that the result could be an invalid index?
No, such an invalid id will be filtered out in the upper layer.
thanks,
Takashi
At Mon, 04 Jul 2011 14:55:31 +0200, Takashi Iwai wrote:
One notably thing is that the new (for codec VT1718S family) Master control misses a few slaves, mainly:
- as expectable, there's neither a "Side Playback Volume" nor a "Side
Playback Switch", since there's no grey jack (to support 7.1 systems, my motherboard line-in (0x2a) should be re-tasked as output and get input from the now available 0xc, which is no more used by headphones)
- more noticeably, there's no "Headphone Playback Volume" control.
There was one in old implementation, explicitly created by vt1718S_auto_create_hp_ctls(); within that function it was easy to bind that control to the actual hp_nid (replacing any occurrence of 0xc with spec->multiout.hp_nid in all relevant functions, the switch from 0xc to 0xb was complete), given that the only reason to test usability of dac at 0xb for headphone was, initially, to check whether 0xc could be freed for use with 0x2a as side (and ensure, or confirm, this codec family can handle as much as 10 channels - but to confirm it definitely an attempt to retask 0x2a should be made).
Moreover, looking at codec informations, now control "Independent HP" is attached to hp pin, altogether with control "Headphone Playback Switch". This should be somehow more consistent with those codecs not using an intermidiate selector to choose the nid to get sound from (perhaps the majority), so that such control always sticks in same (or corresponding) places. However, this way there is more 'distance' between such control and the 'real' nid it works on.
Hm, I'll check this with your alsa-info.sh output.
The missing headphone-volume control is fixed now with the commit 18bd2c44b9c7f0ee775e756dd59e12e0939f7ab9 ALSA: hda - Create HP-vol control properly for VIA codecs
For the retasking for a side-channel, I'm still considering what would be the best. Currently we have smart51 control while other driver has "Channel Mode" enum control. I think the latter can be used more generically for both smart51 and side-channel re-tasking.
Takashi
2011/7/4 Takashi Iwai tiwai@suse.de:
At Mon, 04 Jul 2011 14:55:31 +0200, Takashi Iwai wrote:
One notably thing is that the new (for codec VT1718S family) Master control misses a few slaves, mainly: ...
- more noticeably, there's no "Headphone Playback Volume" control.
There was one in old implementation, explicitly created by vt1718S_auto_create_hp_ctls(); within that function it was easy to bind that control to the actual hp_nid (replacing any occurrence of 0xc with spec->multiout.hp_nid in all relevant functions, the switch from 0xc to 0xb was complete), given that the only reason to test usability of dac at 0xb for headphone was, initially, to check whether 0xc could be freed for use with 0x2a as side (and ensure, or confirm, this codec family can handle as much as 10 channels - but to confirm it definitely an attempt to retask 0x2a should be made).
...
Hm, I'll check this with your alsa-info.sh output.
The missing headphone-volume control is fixed now with the commit 18bd2c44b9c7f0ee775e756dd59e12e0939f7ab9 ALSA: hda - Create HP-vol control properly for VIA codecs
For the retasking for a side-channel, I'm still considering what would be the best. Currently we have smart51 control while other driver has "Channel Mode" enum control. I think the latter can be used more generically for both smart51 and side-channel re-tasking.
Takashi
That can be a good choice (at first glance, I'd agree with that). If choosing to modify smart51 behavior to add side re-tasking, instead, perhaps the control name exposed to mixers should be changed, to avoid confusing an end user trying to set up a 7.1 system and finding only support for 5.1, apparently.
An alternative, for instance, could be using channels' switches directly and make any change/re-tasking transparent for the user. Such an implementation would require:
- missing controls (such as side volume/switch) to be created and (switches) attached to a proper jack pin (basing on common configurations, and/or on the number of missing jacks - that is, first fill dacs for existing jacks, than look if anything else can/must be re-tasked - and/or on what dac is connected with what input pin, etc.);
- custom .put callbacks to be created, e.g. checking if an independent jack does exist and is appropriate for that control (for instance looking at wcaps, defconfig, colour, etc. of passed-in kcontrol nid, or to values recorded in some struct for that nid), or if that's an input pin to be re-tasked, and making appropriate choices;
- some coordination with input switches and callbacks, so that when an input jack is re-tasked as output its corresponding input settings are registered, its input 'state' is switched to 'off' and its input controls are made inactive (input controls callbacks should handle the opposite case, that is re-tasking those jacks as input, resetting old values/states and deactivating corresponding output controls; deactivation could be, to say, 'virtual', on the same line as 'Independent HP' .put method, that is taking care of ongoing streaming and, possibly, ongoing recording, and returning -EBUYSY in such cases, both to avoid any possible race/conflict, and because playing with input/output settings and re-tasking while playing/recording, that is while corresponding jacks are no longer input/output jacks, doesn't make much sense).
Just a thought.
Regards,
Alex
2011/7/4 Takashi Iwai tiwai@suse.de:
At Sat, 2 Jul 2011 18:00:27 +0200, alex dot baldacchino dot alsasub at gmail dot com wrote:
2011/6/22 Takashi Iwai tiwai@suse.de:
At Mon, 20 Jun 2011 17:06:51 +0200, Takashi Iwai wrote:
Hi,
as there have many problems reported for VIA codecs, I started looking at the driver code, and decided to rework on it. [...]
I've installed and tested (from tarballs) both snapshot alsa-driver-20110630 and latest version (alsa-driver-snapshot.tar.gz)
- up to commit e5e14681404ec27a422d635284bf564dabde3f81 by Lydia Wang,
I think.
I've found problems with both. That's a quite huge change in the implementation from older code, so I need to study it more in depth to understand it better... At the moment I can only describe the problems and give my first impressions on them.
First of all, I can't get sound from the front playback (rear line-out).
...
These should be fixed now by Lydia's patch. I updated sound git tree and snapshot tarball now. Please check it later.
I've been far from my pc yesterday for some reasons, and haven't had got too much time today as well, but I've gathered latest version of patch_via.c from http://git.kernel.org/?p=linux/kernel/git/tiwai/sound-2.6.git;a=commit;h=bac... and made a few tests in different conditions, with following results:
Booting with both front and hp connected: - no sound from rear green jack (front pin); - louder and noisier recording of ongoing playback (gives me an idea of stereo mixer quality); - louder sound on hp regardless of independent mode being set on or off, but when nothing is connected to front pin (0x24) - of course, since nothing connected to 0x24 means parm == AC_PWRST_D3 and HP Independent mode ON means state of hp pin (0x28) to be disregarded, thus 0x8 is set to D3 by set_widgets_power_state_vt1718S():
/* PW0 (24h), AOW0 (8h) */ parm = AC_PWRST_D3; set_pin_power_state(codec, 0x24, &parm); if (!spec->hp_independent_mode) /* check for redirected HP */ set_pin_power_state(codec, 0x28, &parm); snd_hda_codec_write(codec, 0x8, 0, AC_VERB_SET_POWER_STATE, parm);
Booting with only front pin connected: - same as above for recording and sound out of hp pin; - now I get sound from front pin, thus it would seem that some automuting is triggered at boot-time (and only at boot-time and/or driver re-load after rmmod'ing - though not tested - since detaching/attaching connectors after boot-up/after drivers are loaded doesn't change such behaviour); such didn't happen in older implementation (before this rework) and, personally, I preferred that behavior; - using same stream settings as front when stream channels are less then line-outs (for exceeding line-outs) works as well.
Independent HP doesn't work, as before, problem (and fix) still being the same:
--- ./alsa-driver/alsa-kernel/pci/hda/patch_via.c.last 2011-07-05 16:25:35.844001455 +0200 +++ ./alsa-driver/alsa-kernel/pci/hda/patch_via.c 2011-07-05 16:25:23.652001521 +0200 @@ -2974,7 +2974,7 @@ static void set_widgets_power_state_vt17 AC_VERB_SET_POWER_STATE, parm); snd_hda_codec_write(codec, 0x34, 0, AC_VERB_SET_POWER_STATE, parm); - snd_hda_codec_write(codec, 0xc, 0, + snd_hda_codec_write(codec, spec->hp_dac_nid, 0, AC_VERB_SET_POWER_STATE, parm); } }
One notably thing is that the new (for codec VT1718S family) Master control misses a few slaves, mainly: ...
- more noticeably, there's no "Headphone Playback Volume" control.
...
Hm, I'll check this with your alsa-info.sh output.
Now "Headphone Playback Volume" is back, thanks.
A final (minor) question/consideration on the code. I've noticed now .put helpers validate data gathered from userspace (typically, passed through ucontrol parameter), which is a good choice to protect against some bug external to the driver; however, if I'm not mistaken, via_mux_enum_put (and corresponding _get) could still be missing something: since any data in ucontrol->id is passed as is to snd_ctl_get_ioffidx, is there any chance that the result could be an invalid index?
No, such an invalid id will be filtered out in the upper layer.
thanks,
Takashi
Thanks for your clarification.
Attaching alsa-info.sh output for my last test (with the above changes to make Independent HP work)
Regards,
Alex
Am Mittwoch, 22. Juni 2011, 16:28:36 schrieb Takashi Iwai:
At Mon, 20 Jun 2011 17:06:51 +0200,
Takashi Iwai wrote:
Hi,
as there have many problems reported for VIA codecs, I started looking at the driver code, and decided to rework on it. [snip]
After not being able to compile the kernel from git, I now compiled modules from today's snapshot (up to 7b5017f56c69ef88f92e6472ec2578708b892211).
I will describe what worked for me and what did not, as I lack the experience to point to details in the code.
* When enabling Dynamic Power-Control in alsamixer, I get no sound, except on the internal SPDIF output.
* Independent HP worked, when I could turn it on in alsamixer and correctly produced sound with aplay -Dhw:0,2,0 . I could not always reliably enable Independent HP in alsamixer, sometimes it would not change status ans aplay claimed that hw:0,2,0 was busy.
* Headphone automute (muting rear line out when headphones are plugged in, if I understand correctly) does not seem to work in any setting.
* I can only get SPDIF output from the internal connector on the mainboard (pin 0x20 if I interpret hda-analyzer correctly) and not from the SPDIF socket on the rear panel. It looks like this might be pin 0x21, which looks like an SPDIF Input in hda- analyzer, but the mainboard manual says that this should be an output.
* Output of alsa-info.sh is attached.
Regards, Jan
At Mon, 4 Jul 2011 21:37:46 +0200, Jan Binder wrote:
Am Mittwoch, 22. Juni 2011, 16:28:36 schrieb Takashi Iwai:
At Mon, 20 Jun 2011 17:06:51 +0200,
Takashi Iwai wrote:
Hi,
as there have many problems reported for VIA codecs, I started looking at the driver code, and decided to rework on it. [snip]
After not being able to compile the kernel from git, I now compiled modules from today's snapshot (up to 7b5017f56c69ef88f92e6472ec2578708b892211).
I will describe what worked for me and what did not, as I lack the experience to point to details in the code.
- When enabling Dynamic Power-Control in alsamixer, I get no sound, except on
the internal SPDIF output.
OK, this and the third item make me wonder whether the jack-detection works on your machine at all. Could you check it via hda-verb or whatever?
- Independent HP worked, when I could turn it on in alsamixer and correctly
produced sound with aplay -Dhw:0,2,0 . I could not always reliably enable Independent HP in alsamixer, sometimes it would not change status ans aplay claimed that hw:0,2,0 was busy.
This is intentional. The switching is racy, so it can't be changed safely when the multi-channel PCM is opened/used.
- Headphone automute (muting rear line out when headphones are plugged in, if
I understand correctly) does not seem to work in any setting.
See above.
- I can only get SPDIF output from the internal connector on the mainboard
(pin 0x20 if I interpret hda-analyzer correctly) and not from the SPDIF socket on the rear panel. It looks like this might be pin 0x21, which looks like an SPDIF Input in hda- analyzer, but the mainboard manual says that this should be an output.
You can change the pin 0x21 in user_pin_config sysfs file, then trigger reconfig sysfs file dynamically. See Documentation/sound/alsa/HD-Audio.txt file.
- Output of alsa-info.sh is attached.
Thanks, I'll check it later.
Takashi
2011/7/5 Takashi Iwai tiwai@suse.de:
At Mon, 4 Jul 2011 21:37:46 +0200, Jan Binder wrote:
- Independent HP worked, when I could turn it on in alsamixer and correctly
produced sound with aplay -Dhw:0,2,0 . I could not always reliably enable Independent HP in alsamixer, sometimes it would not change status ans aplay claimed that hw:0,2,0 was busy.
This is intentional. The switching is racy, so it can't be changed safely when the multi-channel PCM is opened/used.
- Headphone automute (muting rear line out when headphones are plugged in, if
I understand correctly) does not seem to work in any setting.
See above.
The second ADC can only be connected to Mic at Front Panel ,
It seem that this is a prefect candidate to create device 2 for this ADC instead of subdevice 1 so that user can use device 2 for the front panel hp and mic
Node 0x14 [Audio Input] wcaps 0x10051b: Stereo Amp-In Control: name="Capture Volume", index=1, device=0 ControlAmp: chs=3, dir=In, idx=0, ofs=0 Control: name="Capture Switch", index=1, device=0 ControlAmp: chs=3, dir=In, idx=0, ofs=0 Amp-In caps: ofs=0x00, nsteps=0x14, stepsize=0x06, mute=1 Amp-In vals: [0x00 0x00] Converter: stream=2, channel=0 SDI-Select: 0 PCM: rates [0x560]: 44100 48000 96000 192000 bits [0xa]: 16 24 formats [0x1]: PCM Power states: D0 D1 D2 D3 Power: setting=D0, actual=D0 Connection: 1 0x1e
Node 0x1e [Pin Complex] wcaps 0x400581: Stereo Pincap 0x00002334: IN OUT Detect Vref caps: HIZ 50 100 Pin Default 0x02a19038: [Jack] Mic at Ext Front Conn = 1/8, Color = Pink DefAssociation = 0x3, Sequence = 0x8 Pin-ctls: 0x21: IN VREF_50 Unsolicited: tag=20, enabled=1 Power states: D0 D1 D2 D3 Power: setting=D0, actual=D0 Connection: 1 0x27
APLAY
**** List of PLAYBACK Hardware Devices **** card 0: SB [HDA ATI SB], device 0: VT1708B 8-Ch Analog [VT1708B 8-Ch Analog] Subdevices: 1/1 Subdevice #0: subdevice #0 card 0: SB [HDA ATI SB], device 1: VT1708B 8-Ch Digital [VT1708B 8-Ch Digital] Subdevices: 1/1 Subdevice #0: subdevice #0 card 0: SB [HDA ATI SB], device 2: VT1708B 8-Ch HP [VT1708B 8-Ch HP] Subdevices: 1/1 Subdevice #0: subdevice #0
ARECORD
**** List of CAPTURE Hardware Devices **** card 0: SB [HDA ATI SB], device 0: VT1708B 8-Ch Analog [VT1708B 8-Ch Analog] Subdevices: 2/2 Subdevice #0: subdevice #0 Subdevice #1: subdevice #1
2011/7/5 Takashi Iwai tiwai@suse.de:
At Mon, 4 Jul 2011 21:37:46 +0200, Jan Binder wrote:
Am Mittwoch, 22. Juni 2011, 16:28:36 schrieb Takashi Iwai:
At Mon, 20 Jun 2011 17:06:51 +0200,
Takashi Iwai wrote:
Hi,
as there have many problems reported for VIA codecs, I started looking at the driver code, and decided to rework on it. [snip]
- Independent HP worked, when I could turn it on in alsamixer and correctly
produced sound with aplay -Dhw:0,2,0 . I could not always reliably enable Independent HP in alsamixer, sometimes it would not change status ans aplay claimed that hw:0,2,0 was busy.
This is intentional. The switching is racy, so it can't be changed safely when the multi-channel PCM is opened/used.
Is it alway racy or only for those codecs sharing the same DAC between hp and side channel and/or requiring same stream as front to be set up for hp nid as well (e.g. not being connected to the front dac in any manner, if there is any such a via codec)?
In old implementation via_independent_hp_put() explicitly cleaned up any ongoing stream for hp dac and updated side mute status; in my case (vt2020) I didn't noticed errors or problems turning independent mode on/off several times while playing - I might have been just lucky and never met races, or just my codec isn't one of the above cases (indeed, there's no dac shared by hp and side, and my hp pin can be connected directly to front dac and gets also input by the stereo mixer being connected to front dac; actually, I haven't been able to find any info about via codecs with hp pin not being connected to front dac one way or another, so I don't follow why setting up same stream as front for hp dac, when in redirected mode).
By the way, I can think of at least one use case where switching hp mode while playing could be useful/desirable: it might not be extremely frequent, but it might happen that somebody ask you to set a lower volume or to make no 'noise' at all, for a number of reasons, and one might choose to plug a headset in his/her case front audio panel, switch to redirected mode and turn off external speakers. With actual implementation, such would require to stop the playback completely (so that via_playback_multi_pcm_close() is called and spec->num_active_streams is decremented), to change mode, then to restart that playback: this could be annoying. Perhaps, such a scenario could be taken into account.
Takashi
Regards,
Alex
At Wed, 6 Jul 2011 02:58:09 +0200, alex dot baldacchino dot alsasub at gmail dot com wrote:
2011/7/5 Takashi Iwai tiwai@suse.de:
At Mon, 4 Jul 2011 21:37:46 +0200, Jan Binder wrote:
Am Mittwoch, 22. Juni 2011, 16:28:36 schrieb Takashi Iwai:
At Mon, 20 Jun 2011 17:06:51 +0200,
Takashi Iwai wrote:
Hi,
as there have many problems reported for VIA codecs, I started looking at the driver code, and decided to rework on it. [snip]
- Independent HP worked, when I could turn it on in alsamixer and correctly
produced sound with aplay -Dhw:0,2,0 . I could not always reliably enable Independent HP in alsamixer, sometimes it would not change status ans aplay claimed that hw:0,2,0 was busy.
This is intentional. The switching is racy, so it can't be changed safely when the multi-channel PCM is opened/used.
Is it alway racy or only for those codecs sharing the same DAC between hp and side channel and/or requiring same stream as front to be set up for hp nid as well (e.g. not being connected to the front dac in any manner, if there is any such a via codec)?
Right, it's because of shared DAC. If an individual DAC is available, the driver won't block.
In old implementation via_independent_hp_put() explicitly cleaned up any ongoing stream for hp dac and updated side mute status; in my case (vt2020) I didn't noticed errors or problems turning independent mode on/off several times while playing - I might have been just lucky and never met races, or just my codec isn't one of the above cases (indeed, there's no dac shared by hp and side, and my hp pin can be connected directly to front dac and gets also input by the stereo mixer being connected to front dac; actually, I haven't been able to find any info about via codecs with hp pin not being connected to front dac one way or another, so I don't follow why setting up same stream as front for hp dac, when in redirected mode).
By the way, I can think of at least one use case where switching hp mode while playing could be useful/desirable: it might not be extremely frequent, but it might happen that somebody ask you to set a lower volume or to make no 'noise' at all, for a number of reasons, and one might choose to plug a headset in his/her case front audio panel, switch to redirected mode and turn off external speakers. With actual implementation, such would require to stop the playback completely (so that via_playback_multi_pcm_close() is called and spec->num_active_streams is decremented), to change mode, then to restart that playback: this could be annoying. Perhaps, such a scenario could be taken into account.
Yes, the dynamic DAC stream change is also in my TODO list. I haven't implemented it yet because it needs some testing with real machines. But, judging from your experiences, it seems OK to do that.
Maybe I'll try to hack in the next week, but feel free to add by yourself before me (and send a patch).
thanks,
Takashi
participants (5)
-
alex dot baldacchino dot alsasub at gmail dot com -
David Henningsson -
Jan Binder -
Raymond Yau -
Takashi Iwai