2011/5/18 Raymond Yau superquad.vortex2@gmail.com:
2011/5/17 alex dot baldacchino dot alsasub at gmail dot com alex.baldacchino.alsasub@gmail.com
Hello, It took me a while before I could post again here, sorry.
I've installed the snapshot tarball I had downloaded, with debug support enabled, result at following link; results are close to previous ones. [...] It seems configure script for the snapshot has found correct source and installation paths, overwriting existing sound drivers, as expectable; I've left userspace configuration untouched (installed new modules with 'make install-modules' to leave alsa script in /etc/init.d as it was).
!!Aplay/Arecord output !!------------
APLAY
aplay: device_list:240: no soundcards found...
ARECORD
arecord: device_list:240: no soundcards found...
!!Amixer output !!-------------
!!-------Mixer controls for card 0 [SB]
Invalid card number. Usage: amixer <options> [command]
You may need the expert to tell you what 's wrong since you need amixer to change the controls and aplay/arecord to perform test
As I wrote in my first mail, there's a mixer in my system failing an assertion in alsa-lib; starting from there I've investigated what was going on there in (by adding some fprintf to stderr to a few library functions) and have found a sort of inconsistency across /dev/snd/* files minors, udev and the driver. Alsa-lib was using files in /dev/snd, which are statically created with minors that work in kernel 2.6.33.2 + alsa driver 1.0.21, but seems to be unusable for driver version 1.0.23 - 1.0.24. At the same time, udev created sound related stuff in /dev (which weren't used), with the very same major/minor as those ones in /dev/snd in k .33 + alsa 1.0.21, but different minors with a newer alsa driver (e.g. I get /dev/controlC0 with minor 6 (by udev) vs /dev/snd/controlC0 (statically existing) with minor 0, /dev/controlC1 with minor 9 vs /dev/snd/controlC1 with minor 32 and so on). Changing some macros in alsa lib, such as SND_FILE_CONTROL in cards.c, so that files in /dev where used seemed to solve, so I've rebuild alsa lib with option "--with-alsa-devdir=/dev" and now things seem to work... (please, note that's the same regardless of compiling the driver with or without support for dynamic minors, actually it works without dynamic minors using udev created files) alsa-info output at following link:
As an aside, I've noted there are different macros defined in different files (in alsa-lib source) to access the same resource. For instance, in file cards.c
#define SND_FILE_CONTROL ALSA_DEVICE_DIRECTORY "controlC%i"
and in file control_hw.c
#define SNDRV_FILE_CONTROL ALSA_DEVICE_DIRECTORY "controlC%i"
those are/can be used in the same 'context', I mean, at some point function _snd_ctl_hw_open() (in file control_hw.c) can call function snd_card_get_index() (in file cards.c) which uses function snd_card_load1() which uses SND_FILE_CONTROL; then (at last)_snd_ctl_hw_open() calls snd_ctl_hw_open() (same file) which uses SNDRV_FILE_CONTROL, but then snd_ctl_hw_open() can call snd_card_load (cards.c) and again snd_card_load1(). It might look a bit complicated (and somehow duplicated, but both _snd_ctl_hw_open() and snd_ctl_hw_open() are interface functions and could be eventually called independently), but I understand one may need to open a device ro and call an ioctl to get info about it before (re-)opening it rw (though I think functions in cards.c could avoid calling both snd_ctl_hw_open() and snd_ctl_card_info() with a simple change to snd_card_load2(), but that's another story). Anyway, the overall mechanism requires consistency between macros used to identify a control's path, so, perhaps, using just one and moving it into a (local, non-interface) header could improve maintainability a bit, eventually (just a little consideration).
Moreover, it looks like there's a bug in snd_ctl_hw_open() (but it could have been fixed and I could have missed it - just using the stable source I got a while ago for lib 1.0.24.1). In the end it executes the following block - I've added a comment where I think something else should be done:
err = snd_ctl_new(&ctl, SND_CTL_TYPE_HW, name); if (err < 0) { close(fd); free(hw); /* COMMENT ADDED BY ME */ /* should return -ENOMEM (that is err) ?*/ } ctl->ops = &snd_ctl_hw_ops; ctl->private_data = hw; ctl->poll_fd = fd; *handle = ctl; return 0;
If snd_ctl_new() failed, variable ctl would rest uninitialized and a random memory area would be overwritten by successive assignments to dereferenced offsets of ctl.
For the rest, I need some more learning of the driver and architecture insights. For the moment, I can tell the following.
First of all, I was misinterpreting entries in a connection list as outputs instead of inputs (as per hd audio specs), so I was a bit confused on what widget was driving what widget.
I've not applied the lines you were suggesting, because I'm still trying to understand how things work and how would work after any change (and have been more focused on solving driver installation issues).
Front panel disconnected but enabled in bios:
[..]
Misc=NO_PRESENCE mean the external circuitry is not capable of supporting the functionality
Misc[3:0] is a bit field used to indicate other information about the jack. Currently, only bit 0 is defined. If bit 0 is set, it indicates that the jack has no presence detect capability, so even if a Pin Complex indicates that the codec hardware supports the presence detect functionality on the jack, the external circuitry is not capable of supporting the functionality.
That's meaningful. Since the panel wasn't connected to the motherboard, just enabled in bios, the driver must have checked what signals came from that path and got none. It seems it worked as it should be supposed to.
Do you mean the BIOS is able to differentiate HD front panel and AC97 Front panel without user to setup ?
I think those first generation HDA codecs are AC97 compatible
My BIOS has only two options for the front panel: [Auto] and [Disabled], thus it should be capable of autodetection (though, the manual would suggest there should be a third option [Enabled] to set the front panel up as AC97, but there's no such option).
if vt2020 is as same as vt1718s, you need to find a correct nid in the function side_mute_channel() for update_side_mute_status() which mute/unmute side channel when independent HP Is "ON"/"OFF"
it seem that vt1718s does not need to update_side_mute_status if there is a grey jack
http://git.alsa-project.org/?p=alsa-kernel.git;a=commit;h=4d02d1b638af580ae3...
static const struct snd_kcontrol_new via_hp_mixer[2] = { { .iface = SNDRV_CTL_ELEM_IFACE_MIXER, .name = "Independent HP", .info = via_independent_hp_info, .get = via_independent_hp_get, .put = via_independent_hp_put, }, { .iface = NID_MAPPING, .name = "Independent HP", }, };
Must these controls be always coupled? Is it a specification constraint? What if via_hp_build() didn't execute
knew = via_clone_control(spec, &via_hp_mixer[1]);
when side_mute_status() returned '0' ?
Given actual implementation, those should be at least compatible to some extent; in case there were differences between nids in different 'flavours' of vt1718s ( for the sake of side_mute_channel(struct via_spec *spec) ), it should be possible to check spec->codec->vendor_id within the switch statement when spec->codec_type is VT1718S - the problem is finding the right nid
https://bugs.launchpad.net/ubuntu/+source/alsa-driver/+bug/772638
There is codec info of vt1718s on ASRock H55M Pro
comparing the nodes and topology with those of vt1718s
vt2020 has
Node 0x13 [Audio Input] wcaps 0x100711: Stereo Digital Node 0x22 [Beep Generator Widget] wcaps 0x70040c: Mono Amp-Out Node 0x2f [Pin Complex] wcaps 0x400601: Stereo Digital
- grey jack at 0x27 is connected to 0x0b through 0x1a and HP is
connected to 0x0c through 0x1b
what the driver need is a "channel mode" switch from 6 to 8 which configure 0x2a as output/input , and change max_channels between 6 and 8
- without grey jack ,
note there can be an error in my MoBo manual,
There are two choice a) 0x2a is really can be retask as output and connected to 0x0c so HP may need to connect to 0x0b
b) HP is retasked as Side
I haven't got an 8-channel system to test it; according to the manual, line in should be used to create an 8 channel setup. As I understand it, line-in (blue jack) should be a replacement for the gray jack when retasked.
http://www.viaarena.com/forums/showthread.php?t=41015
Refer to administrator 's answer
The Headphone Configuration Panel is shown in Figure 18. There are two headphone configurations that can be chosen: “Independent Headphone” or “Redirected Headphone”. The “Independent Headphone” feature enables the user to play separate music on the headphone and speaker. For example, the user can use a multi-channel device (such as 5.1 surround sound) to watch a movie while simultaneously using the independent headphone feature to make phone calls through a VoIP Internet phone.
The “Redirected Headphone” feature enables the user to hear the same audio that is being channeled to the front speakers. In this mode, once the headphone has been inserted the audio will be redirected from the speakers to the headphone. Please note that the “Independent Headphone” function requires two channels. Therefore, only six channels will be available if “Independent Headphone” is being used.
The last part is interesting. If vt2020 works the same way, the 8-channel setup should disallow the "Independent HP" function, that is it should be automatically turned off and 0x28 should be either muted, or used as a 'duplicate' for 0x0c (same sound of blue jack) or 0x08 (same sound as rear green jack, as in 'redirected audio' ). If I'm not misunderstanding everything, of course.
BTW, 0x2a is connected to (gets input from) 0x09, which is labeled 'Surround Playback Volume' and is also an input for 0x25 ('Surround Playback Switch', black jack, rear speaker according to manual) throughout 0x19; 0x27 (missing gray jack) would be connected to 0x0b throughout 0x1a...
In alsa,
when independent HP is on,
The HP jack is supposed to connected to [Audio Output] which is not used by the rear panel jacks (i.e. 0x25) and application has to use sudevice 1
you can use aplay -Dhw:0,0,1 stereo.wav
Tested: it works. I can get different streams out of rear (front playback) and front (hp) line out jacks (used mplayer on the 'default' rear channel(s) and aplay as above on the front panel)
When Independent HP is off, (it is similar to Redirected Headphone) when automute is not enabled
Turning off Independent HP I can notice the following change:
Node 0x34 [Audio Selector] wcaps 0x300501: Stereo Control: name="Independent HP", index=0, device=0 Power states: D0 D1 D2 D3 Power: setting=D0, actual=D0 Connection: 3 0x08* 0x0b 0x0c
Node 0x08 is connected to rear green jack, and I get same sound on both rear and front jacks
Seem no "Stereo Mix" , 0x28 is HP and only 0x2c, 0x2b and 0x29 are input sources and the other must be muted
node 0x2a "Line Playback Switch" have to be muted and write-protect whenever blue jack is retask
need to modify vt1718S_auto_create_analog_input_ctls()
I have no idea how to do that, my understanding of the code is to limited for now. Perhaps it should be also considered if one needs to modify only vt1718S_auto_create_analog_input_ctls(), both this one and vt_auto_create_analog_input_ctls() or just the latter (but perhaps you just mean the former function should pass a different array to the latter one, and I'm misunderstanding they should also take care somehow of node 0x2a retasking, at least on creation)
Can you record from blue jack ?
you should able to hear the input signal of blue jack at green jack when you unmute "Line Playback Volume"
I cannot test it properly at the moment. I've tried to use my headset's mic connected to blue jack, setting 'line' as first input source and executing 'arecord -vv -d 5 test.wav'. Playing the resulting file with "aplay -vv test.wav" showed a noisy and highly distorted, yet understandable (mono) sound (with all controls set to their max value); recording from rear mic jack, selecting both 'stereo mix' and 'rear mic' as input source created a more natural but still noisy sound (playing with the mixer solves the problem, but I needed top volumes to get sound from line-in without an external amplifier).
By the way, when I select 'Line' as input source with a mixer (selected both sources), I can notice the following changes:
Node 0x1e [Audio Selector] wcaps 0x300501: Stereo Control: name="Input Source", index=0, device=0 Power states: D0 D1 D2 D3 Power: setting=D0, actual=D0 Connection: 6 0x2c 0x2b 0x2a* 0x29 0x28 0x21 Node 0x1f [Audio Selector] wcaps 0x300501: Stereo Control: name="Input Source", index=1, device=0 Power states: D0 D1 D2 D3 Power: setting=D0, actual=D0 Connection: 6 0x2c 0x2b 0x2a* 0x29 0x28 0x21
Selecting 'stereo mixer' those are:
Node 0x1e [Audio Selector] wcaps 0x300501: Stereo Control: name="Input Source", index=0, device=0 Power states: D0 D1 D2 D3 Power: setting=D0, actual=D0 Connection: 6 0x2c 0x2b 0x2a 0x29 0x28 0x21* Node 0x1f [Audio Selector] wcaps 0x300501: Stereo Control: name="Input Source", index=1, device=0 Power states: D0 D1 D2 D3 Power: setting=D0, actual=D0 Connection: 6 0x2c 0x2b 0x2a 0x29 0x28 0x21*
Node 0x2c [Pin Complex] wcaps 0x400401: Stereo Pincap 0x00000020: IN Pin Default 0x593701f8: [N/A] CD at Int ATAPI Conn = Analog, Color = Unknown DefAssociation = 0xf, Sequence = 0x8 Misc = NO_PRESENCE Pin-ctls: 0x00: Power states: D0 D1 D2 D3 Power: setting=D0, actual=D0
What should this be? It doesn't seem to me there's any CD Audio connector in my motherboard. Is it supported by the codec anyway?
This mean that No physical connection for CD connector at the motherboard
Pin Default 0x593701f8
Bit 31:30 Port connectiviy
00b The Port Complex is connected to a jack (1/8", ATAPI, etc.). 01b No physical connection for Port. 10b A fixed function device (integrated speaker, integrated mic, etc.) is attached. 11b Both a jack and an internal device are attached. The Information provided in all other fields refers to the integrated device. The PD pin will reflect the status of the jack; the user will need to be queried to figure out what it is. _______________________________________________ Alsa-devel mailing list Alsa-devel@alsa-project.org http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
Thank you for your clarification.
Regards