[alsa-devel] Fix for Asus G75 notebook subwoofer
This code fixes surround path of asus G75; i'll drop here as a function to be called before codec initialization (I did it in static int patch_vt2002P() ) because I don't know how to detect the notebook and apply it only when needed (I'm new to alsa code).
/* Fixes for Asus G75 subwoofer pin 24 is marked as speaker by bios -- should mark as line pin 33 has a wrong connection to out-of-range nid #3e */ static int fix_asus_g75_subwoofer(struct hda_codec *codec) { /* right connection to pin widget #33 */ hda_nid_t conn[8] = {0x1c}; unsigned int conf; /* Fix connection of pin widget #33 on VT1802p * reported connection (33-1e) refers to non-existent widget #1e which in turn * reports a connection to #1c; we skip nonexistent 1e widget landing directly * on 1c one */ snd_hda_override_conn_list(codec, 0x33, 1, conn);
// pin 24 should be marked as line out pin (not speaker as in bios) // and as AC_JACK_PORT_COMPLEX connection to avoid to be taken by autoparser as a speaker conf = snd_hda_codec_get_pincfg(codec, 0x24); conf = conf & ~AC_DEFCFG_DEVICE; conf = (conf & ~AC_DEFCFG_PORT_CONN) | (AC_JACK_PORT_COMPLEX << AC_DEFCFG_PORT_CONN_SHIFT); snd_hda_codec_set_pincfg(codec, 0x24, conf); // pin 33 should be marked as line out pin (not speaker as in bios) // and as AC_JACK_PORT_COMPLEX, not AC_JACK_PORT_NONE as in bios conf = snd_hda_codec_get_pincfg(codec, 0x33); conf = conf & ~AC_DEFCFG_DEVICE; conf = (conf & ~AC_DEFCFG_PORT_CONN) | (AC_JACK_PORT_COMPLEX << AC_DEFCFG_PORT_CONN_SHIFT); snd_hda_codec_set_pincfg(codec, 0x33, conf);
return 0; }
I guess that the fix on NID #33 should be applied anyways on VT1802p, because by now it connects to a non-existing widget (well, it does exist but is not documented and out of NID range; it should be a stereo-to-mono mixer). BTW, also NID #34, which has 2 connections, has one of them to non-existing nid above; in my case it does no harm :
Widget #24 -- ANALOG STEREO PIN COMPLEX Input from widgets : 14 3e <-- widget 3e is out of range, but connects to 1c widget Connection type : JACK Device : LINE OUT Does NOT support unsolicited response Out amp present In amp NOT present
Ciao
Max
This code fixes surround path of asus G75; i'll drop here as a function
to be called
before codec initialization (I did it in static int patch_vt2002P() )
because I don't
know how to detect the notebook and apply it only when needed (I'm new to
alsa code).
/* Fixes for Asus G75 subwoofer pin 24 is marked as speaker by bios -- should mark as line pin 33 has a wrong connection to out-of-range nid #3e */
can you post the output of alsa-info.sh ?
http://git.kernel.org/?p=linux/kernel/git/tiwai/hda-emu.git;a=blob_plain;f=c...
9.337454] ALSA hda_codec.c:4877 autoconfig: line_outs=1 (0x24/0x0/0x0/0x0/0x0) type:speaker [ 9.337458] ALSA hda_codec.c:4881 speaker_outs=0 (0x0/0x0/0x0/0x0/0x0) [ 9.337460] ALSA hda_codec.c:4885 hp_outs=1 (0x25/0x0/0x0/0x0/0x0) [ 9.337462] ALSA hda_codec.c:4886 mono: mono_out=0x0 [ 9.337464] ALSA hda_codec.c:4889 dig-out=0x2d/0x0 [ 9.337465] ALSA hda_codec.c:4890 inputs: [ 9.337467] ALSA hda_codec.c:4894 Internal Mic=0x29 [ 9.337469] ALSA hda_codec.c:4894 Mic=0x2b
it is the auto parser put the speaker to autocfg->lineout
vt1802 also has connection to 0x3e in node 0x24 and 0x33
you cannot change the pin default from speaker of 0x24 to lineout if node 0x33 only support mono
should the auto parser put it into autocfg->mono_out?
Il 01/11/2012 09:11, Raymond Yau ha scritto:
can you post the output of alsa-info.sh ?
Where can I find the script ? I've not it on my machine
http://git.kernel.org/?p=linux/kernel/git/tiwai/hda-emu.git;a=blob_plain;f=c...
9.337454] ALSA hda_codec.c:4877 autoconfig: line_outs=1(0x24/0x0/0x0/0x0/0x0) type:speaker [ 9.337458] ALSA hda_codec.c:4881 speaker_outs=0 (0x0/0x0/0x0/0x0/0x0) [ 9.337460] ALSA hda_codec.c:4885 hp_outs=1 (0x25/0x0/0x0/0x0/0x0) [ 9.337462] ALSA hda_codec.c:4886 mono: mono_out=0x0 [ 9.337464] ALSA hda_codec.c:4889 dig-out=0x2d/0x0 [ 9.337465] ALSA hda_codec.c:4890 inputs: [ 9.337467] ALSA hda_codec.c:4894 Internal Mic=0x29 [ 9.337469] ALSA hda_codec.c:4894 Mic=0x2b
it is the auto parser put the speaker to autocfg->lineout
Yep, if you look at above, this one was exactly the output before my 2 patches; the only difference was line 24, marked as type=SPEAKER; no trace of mono pin 0x33. I guess the 0x33 is skipped because the parser don't find a path from it, as it have a connection to widget 0x3e with is out of range (widgets are reported to be from 0x08 to 0x0c). We could also patch the returned widget number to be 2 widgets more, even id 0x3d is NOT there.
vt1802 also has connection to 0x3e in node 0x24 and 0x33
The 0x3e is a stereo to mono mixer, connecting to 0x1c. As above, VT1802p reports to have widgets up to 0x3c.
you cannot change the pin default from speaker of 0x24 to lineout if node 0x33 only support mono
should the auto parser put it into autocfg->mono_out?
maybe.... I didn't try that one. With both patches the stuffs appears like a 4 channel one; the correct would be 2+1, but I didn't manage to get it right.
Anyways, I did all this without datasheet... I've tried to get it from VIA, with usual (null) results. Maybe the 2 exceeding widgets are reported there, I don't know.
Resuming, without patches, the auto_parser report for asus :
0x24 Line out, type speaker 0x25 Hp out 0x33 is missing
Forcing the connection from 0x33 to 0x1c (skipping so 0x3e) the pin 0x33 don't appear because bios marks it at none-connection. Forcing the connection to JACK, it puts as a mono speaker, so no sound from it either. Forcing to be a line out, sound only from it because then 0x24 takes the speaker place (marked as speaker in bios). Forcing both 0x24 and 0x33 to be line out gives 4 channel sound (with 2 rear channels output to 0x33 mono).
No idea on how to get the 2+1 behaviour, but at least now it sounds.
Max
can you post the output of alsa-info.sh ?
Where can I find the script ? I've not it on my machine
http://git.alsa-project.org/?p=alsa-driver.git;a=history;hb=refs/heads/build...
9.337454] ALSA hda_codec.c:4877 autoconfig: line_outs=1(0x24/0x0/0x0/0x0/0x0) type:speaker [ 9.337458] ALSA hda_codec.c:4881 speaker_outs=0
(0x0/0x0/0x0/0x0/0x0)
[ 9.337460] ALSA hda_codec.c:4885 hp_outs=1 (0x25/0x0/0x0/0x0/0x0) [ 9.337462] ALSA hda_codec.c:4886 mono: mono_out=0x0 [ 9.337464] ALSA hda_codec.c:4889 dig-out=0x2d/0x0 [ 9.337465] ALSA hda_codec.c:4890 inputs: [ 9.337467] ALSA hda_codec.c:4894 Internal Mic=0x29 [ 9.337469] ALSA hda_codec.c:4894 Mic=0x2b
it is the auto parser put the speaker to autocfg->lineout
http://git.kernel.org/?p=linux/kernel/git/tiwai/sound.git;a=commit;h=90da78b...
mono pin complex are usually [Fixed] Speaker instead of [Jack] Line Out
Yep, if you look at above, this one was exactly the output before my 2
patches; the only difference
was line 24, marked as type=SPEAKER; no trace of mono pin 0x33. I guess the 0x33 is skipped because the parser don't find a path from it,
as it have a connection to
widget 0x3e with is out of range (widgets are reported to be from 0x08 to
0x0c).
https://bugs.launchpad.net/ubuntu/+source/alsa-driver/+bug/1045981
Node 0x33 [Pin Complex] wcaps 0x40050c: Mono Amp-Out Amp-Out caps: ofs=0x00, nsteps=0x00, stepsize=0x00, mute=1 Amp-Out vals: [0x00] Pincap 0x00000010: OUT Pin Default 0x501701f0: [N/A] Speaker at Int N/A Conn = Analog, Color = Unknown DefAssociation = 0xf, Sequence = 0x0 Misc = NO_PRESENCE Pin-ctls: 0x00: Power states: D0 D1 D2 D3 EPSS Power: setting=D0, actual=D0 Connection: 1 0x3e
it is ignored by the auto parser because [N/A] instead of [Fixed]
We could also patch the returned widget number to be 2 widgets more, even
id 0x3d is NOT there.
The 0x3e is a stereo to mono mixer, connecting to 0x1c. As above, VT1802p reports to have widgets up to 0x3c.
do widge 0x3e has amp-out for subwoofer volume control ?
should the auto parser put it into autocfg->mono_out?
maybe.... I didn't try that one. With both patches the stuffs appears like a 4 channel one; the correct
would be 2+1, but
I didn't manage to get it right.
Node 0x2b [Pin Complex] wcaps 0x400481: Stereo Control: name="Mic Boost Volume", index=0, device=0 ControlAmp: chs=3, dir=In, idx=0, ofs=0 Control: name="Mic Jack", index=0, device=0 Pincap 0x00002324: IN Detect Vref caps: HIZ 50 100 Pin Default 0x01a1903e: [Jack] Mic at Ext Rear Conn = 1/8, Color = Pink DefAssociation = 0x3, Sequence = 0xe
as the mic jack cannot be retasked as output , No need to put hp in lineout
Resuming, without patches, the auto_parser report for asus :
0x24 Line out, type speaker 0x25 Hp out 0x33 is missing
Forcing the connection from 0x33 to 0x1c (skipping so 0x3e) the pin 0x33
don't appear
because bios marks it at none-connection. Forcing the connection to JACK, it puts as a mono speaker, so no sound
from it either.
Forcing to be a line out, sound only from it because then 0x24 takes the
speaker place (marked as speaker in bios).
Forcing both 0x24 and 0x33 to be line out gives 4 channel sound (with 2
rear channels output to 0x33 mono).
No idea on how to get the 2+1 behaviour, but at least now it sounds.
multiout.extra_out seem support multi stereo streams in snd_hda_multi_out_analog_prepare()
for (i = 0; i < ARRAY_SIZE(mout->extra_out_nid); i++) if (!mout->no_share_stream && mout->extra_out_nid[i]) snd_hda_codec_setup_stream(codec, mout->extra_out_nid[i], stream_tag, 0, format);
how to put those internal speakers into multiout->extra_out in via_auto_create_speaker_ctls() when the auto parser put the speaker into autocfg->lineout ?
only two volume controls at 0x08 and 0x09, there are three pin complexes 0x24, 0x25 and 0x33
Il 02/11/2012 02:44, Raymond Yau ha scritto:
it is ignored by the auto parser because [N/A] instead of [Fixed]
I guess it's ignored for 2 reasons :
1) N/Aconnection 2) Input from non-reported 0x3e widget
do widge 0x3e has amp-out for subwoofer volume control ?
Nope. The sound path I got finally are : 08/34/14/24/00 08/21/14/24/00 09/3c/1c/33/00 08/35/15/25/00 08/21/15/25/00
So, front on 0x08, shared with HP, and subwoofer on 0x09. Volumes are on 0x08 and 0x09 controls, afaik there are no more volume controls there.
should the auto parser put it into autocfg->mono_out?
maybe.... I didn't try that one. With both patches the stuffs appears like a 4 channel one; the correct
would be 2+1, but
I didn't manage to get it right.
Node 0x2b [Pin Complex] wcaps 0x400481: Stereo Control: name="Mic Boost Volume", index=0, device=0 ControlAmp: chs=3, dir=In, idx=0, ofs=0 Control: name="Mic Jack", index=0, device=0 Pincap 0x00002324: IN Detect Vref caps: HIZ 50 100 Pin Default 0x01a1903e: [Jack] Mic at Ext Rear Conn = 1/8, Color = Pink DefAssociation = 0x3, Sequence = 0xe
as the mic jack cannot be retasked as output , No need to put hp in lineout
I didn't retask the mic (0x2b)... just the 24 and 33.
multiout.extra_out seem support multi stereo streams in snd_hda_multi_out_analog_prepare()
for (i = 0; i < ARRAY_SIZE(mout->extra_out_nid); i++) if (!mout->no_share_stream && mout->extra_out_nid[i]) snd_hda_codec_setup_stream(codec, mout->extra_out_nid[i], stream_tag, 0, format);
how to put those internal speakers into multiout->extra_out in via_auto_create_speaker_ctls() when the auto parser put the speaker into autocfg->lineout ?
Don't know.... if I let 0x33 and/or 0x24 as speaker, they're put as speaker out but not taken in multiout paths.
only two volume controls at 0x08 and 0x09, there are three pin complexes 0x24, 0x25 and 0x33
As above, a volume control is shared between front (24) and HP (25) pins, I guess. Volumes are present just at DAC level, not pins.
Max
https://launchpadlibrarian.net/121871263/alsainfo.txt
do widge 0x3e has amp-out for subwoofer volume control ?
Nope. The sound path I got finally are : 08/34/14/24/00 08/21/14/24/00 09/3c/1c/33/00 08/35/15/25/00 08/21/15/25/00
So, front on 0x08, shared with HP, and subwoofer on 0x09. Volumes are on
0x08 and 0x09 controls,
afaik there are no more volume controls there.
how about the channel map ?
http://git.kernel.org/?p=linux/kernel/git/tiwai/sound.git;a=commitdiff;h=be8...
do your patched driver really work with pulseaudio 2.0 if there is no headphone playback volume controls ?
Simple mixer control 'Independent HP',0 Capabilities: enum Items: 'OFF' 'ON' Item0: 'OFF'
Simple mixer control 'Headphone',0 Capabilities: pvolume pswitch penum Playback channels: Front Left - Front Right Limits: Playback 0 - 42 Mono: Front Left: Playback 42 [100%] [0.00dB] [on] Front Right: Playback 42 [100%] [0.00dB] [on] Simple mixer control 'Speaker',0 Capabilities: pvolume pswitch penum Playback channels: Front Left - Front Right Limits: Playback 0 - 42 Mono: Front Left: Playback 42 [100%] [0.00dB] [on] Front Right: Playback 42 [100%] [0.00dB] [on]
if independent headphone is ON, two different audio stereo streams can play using device 0 (speaker) and device 2 (headphone)
dac 0x08 cannot be shared beween headphone 0x25 and speaker 0x24
do a notebook really need independent headphone ?
http://git.kernel.org/?p=linux/kernel/git/tiwai/sound.git;a=commitdiff;h=a2a...
0: PCH [HDA Intel PCH], device 0: VT1802 Analog [VT1802 Analog] Subdevices: 1/1 Subdevice #0: subdevice #0 card 0: PCH [HDA Intel PCH], device 1: VT1802 Digital [VT1802 Digital] Subdevices: 1/1 Subdevice #0: subdevice #0 card 0: PCH [HDA Intel PCH], device 2: VT1802 HP [VT1802 HP] Subdevices: 1/1 Subdevice #0: subdevice #0
Il 03/11/2012 01:37, Raymond Yau ha scritto:
https://launchpadlibrarian.net/121871263/alsainfo.txt
do your patched driver really work with pulseaudio 2.0 if there is no headphone playback volume controls ?
Yep... behaviour is following :
if NO headphone plugged in, I can choose between stereo and 4 channel surround. With pulse I can then balance left/right and front/rear channels, and set the overall sound volume. The output selector of pulseaudio shows just "analog output".
if headset is plugged in, output audio selector shows both "analog output" and "headphone output", but no matters what I select, output of front channelsgoes to HP, and rear channels are disabled. I guess the output selector switch should work, but it doesn't and audio goes always to HP when plugged.
if independent headphone is ON, two different audio stereo streams can play using device 0 (speaker) and device 2 (headphone)
Can't obviously have indep HP mode AND 2+1 channels, having just 2 volume controls. Maybe it would be possible to have indep HP mode when selecting stereo mode output, but I don't see much use for it.
dac 0x08 cannot be shared beween headphone 0x25 and speaker 0x24
do a notebook really need independent headphone ?
When I said "shared" I meant "alternative"; channel 8 is used for HP when plugged, for front speakers when unplugged; I can't hear both together, and I think it's correct behaviour, having just 2 volume widgets inside VT1802P. Plugged HP completely disables both subwoofer and front speakers; this should be selectable by pulse output selector, but it doesn't.... Bu I guess that one is another bug.
Max
do widge 0x3e has amp-out for subwoofer volume control ?
Nope. The sound path I got finally are : 08/34/14/24/00 08/21/14/24/00 09/3c/1c/33/00 08/35/15/25/00 08/21/15/25/00
So, front on 0x08, shared with HP, and subwoofer on 0x09. Volumes are on
0x08 and 0x09 controls,
afaik there are no more volume controls there.
the driver setup 0x33 (mono pin) for vt1802
http://git.kernel.org/?p=linux/kernel/git/tiwai/sound.git;a=commitdiff;h=118...
and some asus with vt1802 does not have any subwoofer
http://git.kernel.org/?p=linux/kernel/git/tiwai/sound.git;a=commitdiff;h=94c...
do notebook with vt1802 really need independent headphone ?
http://git.kernel.org/?p=linux/kernel/git/tiwai/sound. git;a=commitdiff;h=a2a870c82797e47884b2736e95e9d9 c89a51c219;hp=5c9a5615dedec19196b1217e864616 a2ce9e392a
should the auto parser put it into autocfg->mono_out?
maybe.... I didn't try that one. With both patches the stuffs appears like a 4 channel one; the correct
would be 2+1, but
I didn't manage to get it right.
The function should scan all paths from DACs to OUTS, but like it is just takes the first available DAC. The problem arises here :
if (dac) { spec->private_dac_nids[i] = dac; dac_num++; }
Which correctly adds DAC to used list, but doesn't update the total number of found DACs in spec->multiout.num_dacs; following calls to is_empty_dac() will always return true for already used DACs, making parse_output_path() return always the first one.
it is because
spec->multiout.num_dacs = cfg->line_outs + spec->smart51_nums;
so this may be the reason for the auto parser put internal speaker 0x24 into autocfg->lineout
are you sure that you need pulseaudio to upmix stereo to 4 channels since the driver use copy front mode for 2 channels playback when spec->multiout.num_dacs = 2
/* surrounds */ for (i = 1; i < mout->num_dacs; i++) { if (chs >= (i + 1) * 2) /* independent out */ snd_hda_codec_setup_stream(codec, nids[i], stream_tag, i * 2, format); else if (!mout->no_share_stream) /* copy front */ snd_hda_codec_setup_stream(codec, nids[i], stream_tag, 0, format); }
this mean that the channel map may has no relationship with the number of internal speakers of the notebook
multiout.extra_out seem support multi stereo streams in snd_hda_multi_out_analog_prepare()
for (i = 0; i < ARRAY_SIZE(mout->extra_out_nid); i++) if (!mout->no_share_stream && mout->extra_out_nid[i]) snd_hda_codec_setup_stream(codec,
mout->extra_out_nid[i],
stream_tag, 0,
format);
how to put those internal speakers into multiout->extra_out in via_auto_create_speaker_ctls() when the auto parser put the speaker into autocfg->lineout ?
Don't know.... if I let 0x33 and/or 0x24 as speaker, they're put as
speaker out but not taken
in multiout paths.
does this mean that spec->speaker_path and spec->speaker_mix_path are useless ?
I'm starting to feel lost.... anyways, I'll try to answer to some questions :
and some asus with vt1802 does not have any subwoofer
That's very possible, the patch should be applied only for selected machines... But I don't know how to do it.
http://git.kernel.org/?p=linux/kernel/git/tiwai/sound.git;a=commitdiff;h=94c...
do notebook with vt1802 really need independent headphone ?
IMHO, but that's just my opinion, an independent HP is quite useless for notebooks. AFAIK the unpatched driver maps a DAC to front speakers (0x08) and another for HP (0x09), so no DAC free for subwoofer. We could maybe mono mix the front channel and route it to subwoofer, but then you'd have no separate volume control for sub, which makes it useless.
http://git.kernel.org/?p=linux/kernel/git/tiwai/sound. git;a=commitdiff;h=a2a870c82797e47884b2736e95e9d9 c89a51c219;hp=5c9a5615dedec19196b1217e864616 a2ce9e392a
should the auto parser put it into autocfg->mono_out?
maybe.... I didn't try that one. With both patches the stuffs appears like a 4 channel one; the correct
would be 2+1, but
I didn't manage to get it right.
The function should scan all paths from DACs to OUTS, but like it is just takes the first available DAC. The problem arises here :
if (dac) { spec->private_dac_nids[i] = dac; dac_num++; }
Which correctly adds DAC to used list, but doesn't update the total number of found DACs in spec->multiout.num_dacs; following calls to is_empty_dac() will always return true for already used DACs, making parse_output_path() return always the first one.
it is because
spec->multiout.num_dacs = cfg->line_outs + spec->smart51_nums;
so this may be the reason for the auto parser put internal speaker 0x24 into autocfg->lineout
Those are two unrelated things. The code above is plain wrong (and my patch isn't correct either, but at least makes it working...); when populating DAC nids, the scanner forgets to update the number of found needs while scanning; I mean, in practice during the recursive scan the DACS are always free, so only the first one is returned.
The 0x24 is marked as speaker but is put on line out by auto_parser IF no true line outs are found. I didn't dig too deep inside it, but I guess that if it finds NO line outs (and asus G75 is the case...) it takes first speaker channel and puts on line streams. Not the best solution,IMHO.
does this mean that spec->speaker_path and spec->speaker_mix_path are useless ?
Dont't know, but being without separate volume controls, all must be controlled at dac level, I think... and having a speaker out without separate volume makes no sense. But I didn't dig much on it.
Max
http://git.kernel.org/?p=linux/kernel/git/tiwai/sound.git;a=commitdiff;h=94c...
do notebook with vt1802 really need independent headphone ?
IMHO, but that's just my opinion, an independent HP is quite useless for
notebooks.
/* Mono Out */ present = snd_hda_jack_detect(codec, 0x26);
parm = present ? AC_PWRST_D3 : AC_PWRST_D0; if (spec->codec_type == VT1802) { /* PW15 (33h), MW8(1ch), MUX8(3ch) */ update_power_state(codec, 0x33, parm); update_power_state(codec, 0x1c, parm); update_power_state(codec, 0x3c, parm);
http://git.kernel.org/?p=linux/kernel/git/tiwai/sound.git;a=commitdiff;h=118...
if you look carefully, you should notice that 0x26 is not any detectable pin complex in vt1802
Node 0x26 [Vendor Defined Widget] wcaps 0xf00000: Mono
At Wed, 31 Oct 2012 17:49:39 +0100, Massimo Del Fedele wrote:
This code fixes surround path of asus G75; i'll drop here as a function to be called before codec initialization (I did it in static int patch_vt2002P() ) because I don't know how to detect the notebook and apply it only when needed (I'm new to alsa code).
/* Fixes for Asus G75 subwoofer pin 24 is marked as speaker by bios -- should mark as line pin 33 has a wrong connection to out-of-range nid #3e */ static int fix_asus_g75_subwoofer(struct hda_codec *codec) { /* right connection to pin widget #33 */ hda_nid_t conn[8] = {0x1c}; unsigned int conf;
/* Fix connection of pin widget #33 on VT1802p * reported connection (33-1e) refers to non-existent widget #1e which in turn * reports a connection to #1c; we skip nonexistent 1e widget landing directly * on 1c one */ snd_hda_override_conn_list(codec, 0x33, 1, conn);
// pin 24 should be marked as line out pin (not speaker as in bios) // and as AC_JACK_PORT_COMPLEX connection to avoid to be taken by autoparser as a speaker conf = snd_hda_codec_get_pincfg(codec, 0x24); conf = conf & ~AC_DEFCFG_DEVICE; conf = (conf & ~AC_DEFCFG_PORT_CONN) | (AC_JACK_PORT_COMPLEX << AC_DEFCFG_PORT_CONN_SHIFT); snd_hda_codec_set_pincfg(codec, 0x24, conf);
// pin 33 should be marked as line out pin (not speaker as in bios) // and as AC_JACK_PORT_COMPLEX, not AC_JACK_PORT_NONE as in bios conf = snd_hda_codec_get_pincfg(codec, 0x33); conf = conf & ~AC_DEFCFG_DEVICE; conf = (conf & ~AC_DEFCFG_PORT_CONN) | (AC_JACK_PORT_COMPLEX << AC_DEFCFG_PORT_CONN_SHIFT); snd_hda_codec_set_pincfg(codec, 0x33, conf);
return 0; }
I guess that the fix on NID #33 should be applied anyways on VT1802p, because by now it connects to a non-existing widget (well, it does exist but is not documented and out of NID range; it should be a stereo-to-mono mixer).
You meant 0x3e instead of 0x1e in the comment above, right?
BTW, also NID #34, which has 2 connections, has one of them to non-existing nid above; in my case it does no harm :
Widget #24 -- ANALOG STEREO PIN COMPLEX Input from widgets : 14 3e <-- widget 3e is out of range, but connects to 1c widget Connection type : JACK Device : LINE OUT Does NOT support unsolicited response Out amp present In amp NOT present
Yes, these two connections could be fixed statically in the driver.
Other than that, the default pin configurations could be easily implemented via fixups. Take a look at patch_conexant.c.
In anyway, it'd be helpful if you can attach the alsa-info.sh output on your machine. Even better would be results before and after the patch.
thanks,
Takashi
Il 06/11/2012 09:36, Takashi Iwai ha scritto:
At Wed, 31 Oct 2012 17:49:39 +0100, Massimo Del Fedele wrote:
You meant 0x3e instead of 0x1e in the comment above, right?
Yep, sorry, it was 0x3e of course
Other than that, the default pin configurations could be easily implemented via fixups. Take a look at patch_conexant.c.
thank you, I'll look at it. Is it possible to "connect" the fixups to the asus g75 ?
In anyway, it'd be helpful if you can attach the alsa-info.sh output on your machine. Even better would be results before and after the patch.
The unpatched info is already on bug report :
https://bugs.launchpad.net/ubuntu/+source/alsa-driver/+bug/1045981 (comment #7)
I'll add the patched one now.
BTW, did you see the above patch (error in via_auto_fill_dac_nids) ? My patch isn't correct either (fails when the 'continue' path is taken) but it's better than now. I guess that code should be rewritten, it's quite weird in respect to dac numbering.
thanks,
Takashi
Thank you
Massimo
At Tue, 06 Nov 2012 09:57:31 +0100, Massimo Del Fedele wrote:
Il 06/11/2012 09:36, Takashi Iwai ha scritto:
At Wed, 31 Oct 2012 17:49:39 +0100, Massimo Del Fedele wrote:
You meant 0x3e instead of 0x1e in the comment above, right?
Yep, sorry, it was 0x3e of course
Other than that, the default pin configurations could be easily implemented via fixups. Take a look at patch_conexant.c.
thank you, I'll look at it. Is it possible to "connect" the fixups to the asus g75 ?
Yeah, it must be easy.
In anyway, it'd be helpful if you can attach the alsa-info.sh output on your machine. Even better would be results before and after the patch.
The unpatched info is already on bug report :
https://bugs.launchpad.net/ubuntu/+source/alsa-driver/+bug/1045981 (comment #7)
Could you attach to ML too?
I'll add the patched one now.
BTW, did you see the above patch (error in via_auto_fill_dac_nids) ? My patch isn't correct either (fails when the 'continue' path is taken) but it's better than now. I guess that code should be rewritten, it's quite weird in respect to dac numbering.
Could you elaborate a bit more?
Takashi
Il 06/11/2012 10:06, Takashi Iwai ha scritto:
Could you attach to ML too?
I tried, but they're too big
BTW, did you see the above patch (error in via_auto_fill_dac_nids) ? My patch isn't correct either (fails when the 'continue' path is taken) but it's better than now. I guess that code should be rewritten, it's quite weird in respect to dac numbering.
Could you elaborate a bit more?
Ok. here the original functions :
static bool is_empty_dac(struct hda_codec *codec, hda_nid_t dac) { struct via_spec *spec = codec->spec; int i;
for (i = 0; i < spec->multiout.num_dacs; i++) { <--- uses spec->multiout.num_dacs as used DAC count if (spec->multiout.dac_nids[i] == dac) return false; } if (spec->hp_dac_nid == dac) return false; return true; }
.....................
static bool __parse_output_path(struct hda_codec *codec, hda_nid_t nid, hda_nid_t target_dac, int with_aa_mix, struct nid_path *path, int depth) { struct via_spec *spec = codec->spec; hda_nid_t conn[8]; int i, nums;
if (nid == spec->aa_mix_nid) { if (!with_aa_mix) return false; with_aa_mix = 2; /* mark aa-mix is included */ }
nums = snd_hda_get_connections(codec, nid, conn, ARRAY_SIZE(conn)); for (i = 0; i < nums; i++) { if (get_wcaps_type(get_wcaps(codec, conn[i])) != AC_WID_AUD_OUT) continue; if (conn[i] == target_dac || is_empty_dac(codec, conn[i])) { <--- calls is_empty_dac, but spec->multiout.num_dacs not set here /* aa-mix is requested but not included? */ if (!(spec->aa_mix_nid && with_aa_mix == 1)) goto found; } } if (depth >= MAX_NID_PATH_DEPTH) return false; for (i = 0; i < nums; i++) { unsigned int type; type = get_wcaps_type(get_wcaps(codec, conn[i])); if (type == AC_WID_AUD_OUT) continue; if (__parse_output_path(codec, conn[i], target_dac, with_aa_mix, path, depth + 1)) goto found; } return false;
found: path->path[path->depth] = conn[i]; path->idx[path->depth] = i; if (nums > 1 && get_wcaps_type(get_wcaps(codec, nid)) != AC_WID_AUD_MIX) path->multi[path->depth] = 1; path->depth++; return true; }
....................
static int via_auto_fill_dac_nids(struct hda_codec *codec) { struct via_spec *spec = codec->spec; const struct auto_pin_cfg *cfg = &spec->autocfg; int i, dac_num; hda_nid_t nid;
spec->multiout.dac_nids = spec->private_dac_nids; dac_num = 0; for (i = 0; i < cfg->line_outs; i++) { hda_nid_t dac = 0; nid = cfg->line_out_pins[i]; if (!nid) continue; if (parse_output_path(codec, nid, 0, 0, &spec->out_path[i])) dac = spec->out_path[i].path[0]; if (!i && parse_output_path(codec, nid, dac, 1, &spec->out_mix_path)) dac = spec->out_mix_path.path[0]; if (dac) { spec->private_dac_nids[i] = dac; <---- should be, IMHO, spec->private_dac_nids[dac_num] instead dac_num++; } } if (!spec->out_path[0].depth && spec->out_mix_path.depth) { spec->out_path[0] = spec->out_mix_path; spec->out_mix_path.depth = 0; } spec->multiout.num_dacs = dac_num; <--- sets spec->multiout.num_dacs ONLY at end of search, do is_empty_dac always returns true during search return 0; }
Resuming ;
1) during scan, the spec->multiout.num_dacs is taken as the number of already used DACs, but this is updated jut at END of scan, so during scan the first DAC is always taken. 2) spec->private_dac_nids[i] = dac; should be spec->private_dac_nids[dac_num++] = dac; the 'continue' statement above can leave some holes of uninitializad data in spec->private_dac_nids. 3) spec->multiout.num_dacs sould be updated on EACH dac found, not just at end, otherwise you've got the problem at point 1
The patch I posted on former post is incomplete (don't solve the 'holes' due to continue statement), so it should be rewritten. If you mean, I can do it correctly on next days.
Ciao
Max
At Tue, 06 Nov 2012 15:18:58 +0100, Massimo Del Fedele wrote:
Il 06/11/2012 10:06, Takashi Iwai ha scritto:
Could you attach to ML too?
I tried, but they're too big
Did you compress it?
BTW, did you see the above patch (error in via_auto_fill_dac_nids) ? My patch isn't correct either (fails when the 'continue' path is taken) but it's better than now. I guess that code should be rewritten, it's quite weird in respect to dac numbering.
Could you elaborate a bit more?
Ok. here the original functions :
Hmm... could you give a "diff -up" output instead?
In anyway, mail me directly and add Cc to ML. This is the standard way to reach developers. People (including me) don't read ML often but check the inbox more frequently.
Takashi
Il 06/11/2012 15:24, Takashi Iwai ha scritto:
At Tue, 06 Nov 2012 15:18:58 +0100, Massimo Del Fedele wrote:
Il 06/11/2012 10:06, Takashi Iwai ha scritto:
Could you attach to ML too?
I tried, but they're too big
Did you compress it?
No, but I'm doing now... in compressed file are both info
BTW, did you see the above patch (error in via_auto_fill_dac_nids) ? My patch isn't correct either (fails when the 'continue' path is taken) but it's better than now. I guess that code should be rewritten, it's quite weird in respect to dac numbering.
Could you elaborate a bit more?
Ok. here the original functions :
Hmm... could you give a "diff -up" output instead?
Ok... here is te diff (with whole asus patch). I cleaned up the part of via_auto_fill_dac_nids, it should be correct now in all parts, even for skipped nids.
In anyway, mail me directly and add Cc to ML. This is the standard way to reach developers. People (including me) don't read ML often but check the inbox more frequently.
Ok, thank you for telling
Takashi
Massimo
At Tue, 06 Nov 2012 18:23:51 +0100, Massimo Del Fedele wrote:
Il 06/11/2012 15:24, Takashi Iwai ha scritto:
At Tue, 06 Nov 2012 15:18:58 +0100, Massimo Del Fedele wrote:
Il 06/11/2012 10:06, Takashi Iwai ha scritto:
Could you attach to ML too?
I tried, but they're too big
Did you compress it?
No, but I'm doing now... in compressed file are both info
Could you post also alsa-info.sh output before applying your patch, too?
BTW, did you see the above patch (error in via_auto_fill_dac_nids) ? My patch isn't correct either (fails when the 'continue' path is taken) but it's better than now. I guess that code should be rewritten, it's quite weird in respect to dac numbering.
Could you elaborate a bit more?
Ok. here the original functions :
Hmm... could you give a "diff -up" output instead?
Ok... here is te diff (with whole asus patch). I cleaned up the part of via_auto_fill_dac_nids, it should be correct now in all parts, even for skipped nids.
Actually the only place to be fixed is the assignment of spec->private_dac_nids[]. spec->out_path[] should correspond to cfg->line_out_pins[]. That is, the patch below should suffice (in addition to pin default changes and connection overrides for VT1802).
thanks,
Takashi
--- diff --git a/sound/pci/hda/patch_via.c b/sound/pci/hda/patch_via.c index 72a2f60..1c1367b 100644 --- a/sound/pci/hda/patch_via.c +++ b/sound/pci/hda/patch_via.c @@ -1825,7 +1825,7 @@ static int via_auto_fill_dac_nids(struct hda_codec *codec) &spec->out_mix_path)) dac = spec->out_mix_path.path[0]; if (dac) { - spec->private_dac_nids[i] = dac; + spec->private_dac_nids[dac_num] = dac; dac_num++; } }
At Tue, 06 Nov 2012 18:23:51 +0100, Massimo Del Fedele wrote:
Il 06/11/2012 15:24, Takashi Iwai ha scritto:
At Tue, 06 Nov 2012 15:18:58 +0100, Massimo Del Fedele wrote:
Il 06/11/2012 10:06, Takashi Iwai ha scritto:
Could you attach to ML too?
I tried, but they're too big
Did you compress it?
No, but I'm doing now... in compressed file are both info
Could you post also alsa-info.sh output before applying your patch, too?
BTW, did you see the above patch (error in via_auto_fill_dac_nids) ? My patch isn't correct either (fails when the 'continue' path is taken) but it's better than now. I guess that code should be rewritten, it's quite weird in respect to dac numbering.
Could you elaborate a bit more?
Ok. here the original functions :
Hmm... could you give a "diff -up" output instead?
Ok... here is te diff (with whole asus patch). I cleaned up the part of via_auto_fill_dac_nids, it should be correct now in all parts, even for skipped nids.
Actually the only place to be fixed is the assignment of spec->private_dac_nids[]. spec->out_path[] should correspond to cfg->line_out_pins[]. That is, the patch below should suffice (in addition to pin default changes and connection overrides for VT1802).
thanks,
Takashi
--- diff --git a/sound/pci/hda/patch_via.c b/sound/pci/hda/patch_via.c index 72a2f60..1c1367b 100644 --- a/sound/pci/hda/patch_via.c +++ b/sound/pci/hda/patch_via.c @@ -1825,7 +1825,7 @@ static int via_auto_fill_dac_nids(struct hda_codec *codec) &spec->out_mix_path)) dac = spec->out_mix_path.path[0]; if (dac) { - spec->private_dac_nids[i] = dac; + spec->private_dac_nids[dac_num] = dac; dac_num++; } }
Il 07/11/2012 09:56, Takashi Iwai ha scritto:
At Tue, 06 Nov 2012 18:23:51 +0100, Massimo Del Fedele wrote:
Il 06/11/2012 15:24, Takashi Iwai ha scritto:
At Tue, 06 Nov 2012 15:18:58 +0100, Massimo Del Fedele wrote:
Il 06/11/2012 10:06, Takashi Iwai ha scritto:
Could you attach to ML too?
I tried, but they're too big
Did you compress it?
No, but I'm doing now... in compressed file are both info
Could you post also alsa-info.sh output before applying your patch, too?
BTW, did you see the above patch (error in via_auto_fill_dac_nids) ? My patch isn't correct either (fails when the 'continue' path is taken) but it's better than now. I guess that code should be rewritten, it's quite weird in respect to dac numbering.
Could you elaborate a bit more?
Ok. here the original functions :
Hmm... could you give a "diff -up" output instead?
Ok... here is te diff (with whole asus patch). I cleaned up the part of via_auto_fill_dac_nids, it should be correct now in all parts, even for skipped nids.
Actually the only place to be fixed is the assignment of spec->private_dac_nids[]. spec->out_path[] should correspond to cfg->line_out_pins[]. That is, the patch below should suffice (in addition to pin default changes and connection overrides for VT1802).
thanks,
Takashi
diff --git a/sound/pci/hda/patch_via.c b/sound/pci/hda/patch_via.c index 72a2f60..1c1367b 100644 --- a/sound/pci/hda/patch_via.c +++ b/sound/pci/hda/patch_via.c @@ -1825,7 +1825,7 @@ static int via_auto_fill_dac_nids(struct hda_codec *codec) &spec->out_mix_path)) dac = spec->out_mix_path.path[0]; if (dac) {
spec->private_dac_nids[i] = dac;
spec->private_dac_nids[dac_num] = dac; dac_num++;
Hi... not tested, but IMHO your patch won't be enough; you're not updating the spec->multiout.num_dacs inside the loop, which means that is_empty_dac(codec, conn[i]) inside __parse_output_path() will not detect used DACs as used :
static bool is_empty_dac(struct hda_codec *codec, hda_nid_t dac) { struct via_spec *spec = codec->spec; int i;
for (i = 0; i < spec->multiout.num_dacs; i++) { <---- HERE, using spec->multiout.num_dacs as loop end if (spec->multiout.dac_nids[i] == dac) return false; } if (spec->hp_dac_nid == dac) return false; return true; }
You need to update spec->multiout.num_dacs INSIDE scan loop, NOT at end.
Ciao
Max
At Wed, 07 Nov 2012 14:37:33 +0100, Massimo Del Fedele wrote:
Il 07/11/2012 09:56, Takashi Iwai ha scritto:
At Tue, 06 Nov 2012 18:23:51 +0100, Massimo Del Fedele wrote:
Il 06/11/2012 15:24, Takashi Iwai ha scritto:
At Tue, 06 Nov 2012 15:18:58 +0100, Massimo Del Fedele wrote:
Il 06/11/2012 10:06, Takashi Iwai ha scritto:
Could you attach to ML too?
I tried, but they're too big
Did you compress it?
No, but I'm doing now... in compressed file are both info
Could you post also alsa-info.sh output before applying your patch, too?
> BTW, did you see the above patch (error in via_auto_fill_dac_nids) ? > My patch isn't correct either (fails when the 'continue' path is taken) > but it's better than now. I guess that code should be rewritten, it's > quite weird in respect to dac numbering. Could you elaborate a bit more?
Ok. here the original functions :
Hmm... could you give a "diff -up" output instead?
Ok... here is te diff (with whole asus patch). I cleaned up the part of via_auto_fill_dac_nids, it should be correct now in all parts, even for skipped nids.
Actually the only place to be fixed is the assignment of spec->private_dac_nids[]. spec->out_path[] should correspond to cfg->line_out_pins[]. That is, the patch below should suffice (in addition to pin default changes and connection overrides for VT1802).
thanks,
Takashi
diff --git a/sound/pci/hda/patch_via.c b/sound/pci/hda/patch_via.c index 72a2f60..1c1367b 100644 --- a/sound/pci/hda/patch_via.c +++ b/sound/pci/hda/patch_via.c @@ -1825,7 +1825,7 @@ static int via_auto_fill_dac_nids(struct hda_codec *codec) &spec->out_mix_path)) dac = spec->out_mix_path.path[0]; if (dac) {
spec->private_dac_nids[i] = dac;
spec->private_dac_nids[dac_num] = dac; dac_num++;Hi... not tested, but IMHO your patch won't be enough; you're not updating the spec->multiout.num_dacs inside the loop, which means that is_empty_dac(codec, conn[i]) inside __parse_output_path() wil
l not detect used DACs as used :
Ah, good point. Fixed now.
Takashi
Il 07/11/2012 14:45, Takashi Iwai ha scritto:
At Wed, 07 Nov 2012 14:37:33 +0100, Massimo Del Fedele wrote:
Il 07/11/2012 09:56, Takashi Iwai ha scritto:
At Tue, 06 Nov 2012 18:23:51 +0100, Massimo Del Fedele wrote:
Il 06/11/2012 15:24, Takashi Iwai ha scritto:
At Tue, 06 Nov 2012 15:18:58 +0100, Massimo Del Fedele wrote:
Il 06/11/2012 10:06, Takashi Iwai ha scritto:
> Could you attach to ML too? I tried, but they're too big
Did you compress it?
No, but I'm doing now... in compressed file are both info
Could you post also alsa-info.sh output before applying your patch, too?
>> BTW, did you see the above patch (error in via_auto_fill_dac_nids) ? >> My patch isn't correct either (fails when the 'continue' path is taken) >> but it's better than now. I guess that code should be rewritten, it's >> quite weird in respect to dac numbering. > Could you elaborate a bit more? > Ok. here the original functions :
Hmm... could you give a "diff -up" output instead?
Ok... here is te diff (with whole asus patch). I cleaned up the part of via_auto_fill_dac_nids, it should be correct now in all parts, even for skipped nids.
Actually the only place to be fixed is the assignment of spec->private_dac_nids[]. spec->out_path[] should correspond to cfg->line_out_pins[]. That is, the patch below should suffice (in addition to pin default changes and connection overrides for VT1802).
thanks,
Takashi
diff --git a/sound/pci/hda/patch_via.c b/sound/pci/hda/patch_via.c index 72a2f60..1c1367b 100644 --- a/sound/pci/hda/patch_via.c +++ b/sound/pci/hda/patch_via.c @@ -1825,7 +1825,7 @@ static int via_auto_fill_dac_nids(struct hda_codec *codec) &spec->out_mix_path)) dac = spec->out_mix_path.path[0]; if (dac) {
spec->private_dac_nids[i] = dac;
spec->private_dac_nids[dac_num] = dac; dac_num++; }Hi... not tested, but IMHO your patch won't be enough; you're not updating the spec->multiout.num_dacs inside the loop, which means that is_empty_dac(codec, conn[i]) inside __parse_output_path() wil
l not detect used DACs as used :
Ah, good point. Fixed now.
Takashi
Working well now; this is the verbose dmesg output :
[ 920.868350] ALSA hda_auto_parser.c:664 >hda_codec: VT1802: Apply pincfg for Asus G75 [ 920.868367] ALSA hda_auto_parser.c:318 autoconfig: line_outs=2 (0x24/0x33/0x0/0x0/0x0) type:speaker [ 920.868371] ALSA hda_auto_parser.c:322 speaker_outs=0 (0x0/0x0/0x0/0x0/0x0) [ 920.868374] ALSA hda_auto_parser.c:326 hp_outs=1 (0x25/0x0/0x0/0x0/0x0) [ 920.868376] ALSA hda_auto_parser.c:327 mono: mono_out=0x0 [ 920.868378] ALSA hda_auto_parser.c:330 dig-out=0x2d/0x0 [ 920.868380] ALSA hda_auto_parser.c:331 inputs: [ 920.868384] ALSA hda_auto_parser.c:335 Internal Mic=0x29 [ 920.868387] ALSA hda_auto_parser.c:335 Mic=0x2b [ 920.868631] ALSA patch_via.c:1861 output-path: depth=4, 08/34/14/24/00 [ 920.868647] ALSA patch_via.c:1861 output-path: depth=4, 08/21/14/24/00 [ 920.868861] ALSA patch_via.c:1861 output-path: depth=4, 09/3c/1c/33/00 [ 920.869321] ALSA patch_via.c:1861 output-path: depth=4, 08/35/15/25/00 [ 920.869325] ALSA patch_via.c:1861 output-path: depth=4, 08/21/15/25/00
Which seems ok to me. As before, I now have 2 front speakers (correctly) and 2 rear speakers, going to mono subwoofer. I don't know if it's a correct behaviour or not.
Thank you
Massimo
At Wed, 07 Nov 2012 16:51:01 +0100, Massimo Del Fedele wrote:
Il 07/11/2012 14:45, Takashi Iwai ha scritto:
At Wed, 07 Nov 2012 14:37:33 +0100, Massimo Del Fedele wrote:
Il 07/11/2012 09:56, Takashi Iwai ha scritto:
At Tue, 06 Nov 2012 18:23:51 +0100, Massimo Del Fedele wrote:
Il 06/11/2012 15:24, Takashi Iwai ha scritto:
At Tue, 06 Nov 2012 15:18:58 +0100, Massimo Del Fedele wrote: > Il 06/11/2012 10:06, Takashi Iwai ha scritto: > >> Could you attach to ML too? > I tried, but they're too big Did you compress it?
No, but I'm doing now... in compressed file are both info
Could you post also alsa-info.sh output before applying your patch, too?
>>> BTW, did you see the above patch (error in via_auto_fill_dac_nids) ? >>> My patch isn't correct either (fails when the 'continue' path is taken) >>> but it's better than now. I guess that code should be rewritten, it's >>> quite weird in respect to dac numbering. >> Could you elaborate a bit more? >> > Ok. here the original functions : Hmm... could you give a "diff -up" output instead?
Ok... here is te diff (with whole asus patch). I cleaned up the part of via_auto_fill_dac_nids, it should be correct now in all parts, even for skipped nids.
Actually the only place to be fixed is the assignment of spec->private_dac_nids[]. spec->out_path[] should correspond to cfg->line_out_pins[]. That is, the patch below should suffice (in addition to pin default changes and connection overrides for VT1802).
thanks,
Takashi
diff --git a/sound/pci/hda/patch_via.c b/sound/pci/hda/patch_via.c index 72a2f60..1c1367b 100644 --- a/sound/pci/hda/patch_via.c +++ b/sound/pci/hda/patch_via.c @@ -1825,7 +1825,7 @@ static int via_auto_fill_dac_nids(struct hda_codec *codec) &spec->out_mix_path)) dac = spec->out_mix_path.path[0]; if (dac) {
spec->private_dac_nids[i] = dac;
spec->private_dac_nids[dac_num] = dac; dac_num++; }Hi... not tested, but IMHO your patch won't be enough; you're not updating the spec->multiout.num_dacs inside the loop, which means that is_empty_dac(codec, conn[i]) inside __parse_output_path() wil
l not detect used DACs as used :
Ah, good point. Fixed now.
Takashi
Working well now; this is the verbose dmesg output :
[ 920.868350] ALSA hda_auto_parser.c:664 >hda_codec: VT1802: Apply pincfg for Asus G75 [ 920.868367] ALSA hda_auto_parser.c:318 autoconfig: line_outs=2 (0x24/0x33/0x0/0x0/0x0) type:speaker [ 920.868371] ALSA hda_auto_parser.c:322 speaker_outs=0 (0x0/0x0/0x0/0x0/0x0) [ 920.868374] ALSA hda_auto_parser.c:326 hp_outs=1 (0x25/0x0/0x0/0x0/0x0) [ 920.868376] ALSA hda_auto_parser.c:327 mono: mono_out=0x0 [ 920.868378] ALSA hda_auto_parser.c:330 dig-out=0x2d/0x0 [ 920.868380] ALSA hda_auto_parser.c:331 inputs: [ 920.868384] ALSA hda_auto_parser.c:335 Internal Mic=0x29 [ 920.868387] ALSA hda_auto_parser.c:335 Mic=0x2b [ 920.868631] ALSA patch_via.c:1861 output-path: depth=4, 08/34/14/24/00 [ 920.868647] ALSA patch_via.c:1861 output-path: depth=4, 08/21/14/24/00 [ 920.868861] ALSA patch_via.c:1861 output-path: depth=4, 09/3c/1c/33/00 [ 920.869321] ALSA patch_via.c:1861 output-path: depth=4, 08/35/15/25/00 [ 920.869325] ALSA patch_via.c:1861 output-path: depth=4, 08/21/15/25/00
Which seems ok to me. As before, I now have 2 front speakers (correctly) and 2 rear speakers, going to mono subwoofer. I don't know if it's a correct behaviour or not.
It's OK, just missing the stereo capability check in the mixer code, but almost harmless. Which channel (left or right) of "surround" mixer actually controls the volume of subwoofer on your machine?
Takashi
Il 07/11/2012 16:54, Takashi Iwai ha scritto:
It's OK, just missing the stereo capability check in the mixer code, but almost harmless. Which channel (left or right) of "surround" mixer actually controls the volume of subwoofer on your machine?
Both, as the volume control is at DAC level and not at pin one. aplay with channel test sound shows a 4 channels audio, driving subwoofer with both rear left and rear right data. If I lower left or right volume, just opposite channel goes to subwoofer. I guess that mono mixing is done at widget 0x3e (the hidden one).
Massimo
At Wed, 07 Nov 2012 18:02:20 +0100, Massimo Del Fedele wrote:
Il 07/11/2012 16:54, Takashi Iwai ha scritto:
It's OK, just missing the stereo capability check in the mixer code, but almost harmless. Which channel (left or right) of "surround" mixer actually controls the volume of subwoofer on your machine?
Both, as the volume control is at DAC level and not at pin one.
OK, it must be because of the DAC amp being stereo.
aplay with channel test sound shows a 4 channels audio, driving subwoofer with both rear left and rear right data.
Yes, this is still a missing piece. The driver needs an override to the standard chmap.
If I lower left or right volume, just opposite channel goes to subwoofer. I guess that mono mixing is done at widget 0x3e (the hidden one).
Takashi
participants (3)
-
Massimo Del Fedele -
Raymond Yau -
Takashi Iwai