Re: [alsa-devel] [PATCH v2] Introduce config for intel dg45id board
At Tue, 08 Dec 2009 17:30:18 +0100, Alexey Fisher wrote:
Am Dienstag, den 08.12.2009, 14:15 +0100 schrieb Takashi Iwai:
At Tue, 08 Dec 2009 14:02:43 +0100, Alexey Fisher wrote:
Am Dienstag, den 08.12.2009, 12:04 +0100 schrieb Takashi Iwai:
At Sun, 6 Dec 2009 11:29:13 +0100, Alexey Fisher wrote:
This patch introduce pin config and some workarounds for dg45id board. Currently tested Mic + Surround 7.1 on rear panel, and Mic + HP on front panel. SPDIF front and SPDIF rear are untested. Both Mics provide VREF_80 (4,05 V) in mic mode and no VREF in line-in mode.
Signed-off-by: Alexey Fisher bug-track@fisher-privat.net
Thanks for the patch.
But, I still don't see the reason for so many init verbs, especially doing static routings. Can't be they connected properly by the parser? If so, it's the parser to be fixed, not a quirky init table.
Ok. I prefer to have the part with mixer. The driver currently can't handle this.
What do you mean exactly with "mixer"?
It seems to make some problem with front HP. By default All mixer inputs use 0x0a (Front HP out), in this situation i get hi freq noise on 0x0a. So or driver should learn to work with mixer or...?
Not sure what you are talking about here...
I talking about widget like this:
Node 0x0b [Audio Mixer] wcaps 0x20010b: Stereo Amp-In Amp-In caps: ofs=0x17, nsteps=0x1f, stepsize=0x05, mute=1 Amp-In vals: [0x80 0x80] [0x80 0x80] [0x80 0x80] [0x80 0x80] [0x80 0x80] Connection: 5 0x18 0x19 0x1a 0x1b 0x1d
this is an example from my laptop. Normally this widget connected to the audio selector like this:
Node 0x23 [Audio Selector] wcaps 0x300101: Stereo Connection: 7 0x18 0x19 0x1a 0x1b 0x1d 0x12* 0x0b
ALSA will list only attached to "Audio Selector" "Mic" or "Line in" pins, not "Audio mixer". ALSA do not give control for audio mixer too.
Just because STAC/IDT codecs have no mixer widget. It's a hardware issue.
And, your machine has really no headphone detection? I mean, not about your taste but it's not physically doable?
HP detection working on rear green (0x0d), not on front green (0x0a). May be there is something wrong with connector. Anyway, it working fine under M$. May be we should provide UI control for this (to make user completely confused:)?
If Windows driver can detect the front HP jack, it means the connection is alive. You can try hda-verb to check whether the pin-detection works, independently from the driver setup.
Pin detection working only on rear panel, on front panel it do not working and on windows and on linux. Probably broken front panel jack... I assume windwos use different logic.
OK, then it's likely a typical problem of the cabling and the case model. In many cases, an AC97-style case is connected to a HD-audio board.
linux logic: if no hp, play sound to speaker and mute hp. if hp detected
- unmute hp and mute speaker.
winodws logic: if no hp detected play to hp and to speaker, if hp detected - mute speaker and continue play to hp.
I think, if ALSA will behave in same way it will need less hp quirks.
Yes, that's how no_jd model works.
But, keeping the headphone output even with unplugged state means you are wasting unneeded power. The driver powers down the circuit appropriately if a pin isn't being used. That's why the headphone detection is implemented as default.
And, whether the HP detection works or not doesn't depend on the mobo. It's rather the connection. So, giving the fixed "no-jd" option for a certain PCI SSID is basically wrong. Someone else might have a same mobo but with a right case with the front-panel jack detection.
That is, it's fine to create a new quirk model, but assigning statically to that workaround isn't always acceptable.
thanks,
Takashi
Am Dienstag, den 08.12.2009, 17:39 +0100 schrieb Takashi Iwai:
At Tue, 08 Dec 2009 17:30:18 +0100, Alexey Fisher wrote:
Am Dienstag, den 08.12.2009, 14:15 +0100 schrieb Takashi Iwai:
At Tue, 08 Dec 2009 14:02:43 +0100, Alexey Fisher wrote:
Am Dienstag, den 08.12.2009, 12:04 +0100 schrieb Takashi Iwai:
At Sun, 6 Dec 2009 11:29:13 +0100, Alexey Fisher wrote:
This patch introduce pin config and some workarounds for dg45id board. Currently tested Mic + Surround 7.1 on rear panel, and Mic + HP on front panel. SPDIF front and SPDIF rear are untested. Both Mics provide VREF_80 (4,05 V) in mic mode and no VREF in line-in mode.
Signed-off-by: Alexey Fisher bug-track@fisher-privat.net
Thanks for the patch.
But, I still don't see the reason for so many init verbs, especially doing static routings. Can't be they connected properly by the parser? If so, it's the parser to be fixed, not a quirky init table.
Ok. I prefer to have the part with mixer. The driver currently can't handle this.
What do you mean exactly with "mixer"?
It seems to make some problem with front HP. By default All mixer inputs use 0x0a (Front HP out), in this situation i get hi freq noise on 0x0a. So or driver should learn to work with mixer or...?
Not sure what you are talking about here...
I talking about widget like this:
Node 0x0b [Audio Mixer] wcaps 0x20010b: Stereo Amp-In Amp-In caps: ofs=0x17, nsteps=0x1f, stepsize=0x05, mute=1 Amp-In vals: [0x80 0x80] [0x80 0x80] [0x80 0x80] [0x80 0x80] [0x80 0x80] Connection: 5 0x18 0x19 0x1a 0x1b 0x1d
this is an example from my laptop. Normally this widget connected to the audio selector like this:
Node 0x23 [Audio Selector] wcaps 0x300101: Stereo Connection: 7 0x18 0x19 0x1a 0x1b 0x1d 0x12* 0x0b
ALSA will list only attached to "Audio Selector" "Mic" or "Line in" pins, not "Audio mixer". ALSA do not give control for audio mixer too.
Just because STAC/IDT codecs have no mixer widget. It's a hardware issue.
i talking about "IDT 92HD73E1X5" wich _has_ mixer widget. I use it on windows and i can use it on linux (directly, by controlling it with hda-verb). So this is not hardware issue. Here is the part of codecdump from IDT 92HD73E1X5:
Node 0x1d [Audio Mixer] wcaps 0x20010b: Stereo Amp-In Amp-In caps: ofs=0x17, nsteps=0x1f, stepsize=0x05, mute=1 Amp-In vals: [0x97 0x97] [0x97 0x97] [0x97 0x97] [0x97 0x97] [0x97 0x97] Connection: 5 0x28 0x29 0x2a 0x2b 0x12
And, your machine has really no headphone detection? I mean, not about your taste but it's not physically doable?
HP detection working on rear green (0x0d), not on front green (0x0a). May be there is something wrong with connector. Anyway, it working fine under M$. May be we should provide UI control for this (to make user completely confused:)?
If Windows driver can detect the front HP jack, it means the connection is alive. You can try hda-verb to check whether the pin-detection works, independently from the driver setup.
Pin detection working only on rear panel, on front panel it do not working and on windows and on linux. Probably broken front panel jack... I assume windwos use different logic.
OK, then it's likely a typical problem of the cabling and the case model. In many cases, an AC97-style case is connected to a HD-audio board.
linux logic: if no hp, play sound to speaker and mute hp. if hp detected
- unmute hp and mute speaker.
winodws logic: if no hp detected play to hp and to speaker, if hp detected - mute speaker and continue play to hp.
I think, if ALSA will behave in same way it will need less hp quirks.
Yes, that's how no_jd model works.
But, keeping the headphone output even with unplugged state means you are wasting unneeded power. The driver powers down the circuit appropriately if a pin isn't being used. That's why the headphone detection is implemented as default.
And, whether the HP detection works or not doesn't depend on the mobo. It's rather the connection. So, giving the fixed "no-jd" option for a certain PCI SSID is basically wrong. Someone else might have a same mobo but with a right case with the front-panel jack detection.
That is, it's fine to create a new quirk model, but assigning statically to that workaround isn't always acceptable.
Ok, i get the point. But no-jd should be provided as "Jack Detect Switch". I know... i tolking about work :)... probably i'll try to do this. But i think it make sense.
thanks,
Takashi
At Tue, 08 Dec 2009 21:12:27 +0100, Alexey Fisher wrote:
Am Dienstag, den 08.12.2009, 17:39 +0100 schrieb Takashi Iwai:
At Tue, 08 Dec 2009 17:30:18 +0100, Alexey Fisher wrote:
Am Dienstag, den 08.12.2009, 14:15 +0100 schrieb Takashi Iwai:
At Tue, 08 Dec 2009 14:02:43 +0100, Alexey Fisher wrote:
Am Dienstag, den 08.12.2009, 12:04 +0100 schrieb Takashi Iwai:
At Sun, 6 Dec 2009 11:29:13 +0100, Alexey Fisher wrote: > > This patch introduce pin config and some workarounds for dg45id board. > Currently tested Mic + Surround 7.1 on rear panel, and Mic + HP on front panel. > SPDIF front and SPDIF rear are untested. > Both Mics provide VREF_80 (4,05 V) in mic mode and no VREF in line-in mode. > > Signed-off-by: Alexey Fisher bug-track@fisher-privat.net
Thanks for the patch.
But, I still don't see the reason for so many init verbs, especially doing static routings. Can't be they connected properly by the parser? If so, it's the parser to be fixed, not a quirky init table.
Ok. I prefer to have the part with mixer. The driver currently can't handle this.
What do you mean exactly with "mixer"?
It seems to make some problem with front HP. By default All mixer inputs use 0x0a (Front HP out), in this situation i get hi freq noise on 0x0a. So or driver should learn to work with mixer or...?
Not sure what you are talking about here...
I talking about widget like this:
Node 0x0b [Audio Mixer] wcaps 0x20010b: Stereo Amp-In Amp-In caps: ofs=0x17, nsteps=0x1f, stepsize=0x05, mute=1 Amp-In vals: [0x80 0x80] [0x80 0x80] [0x80 0x80] [0x80 0x80] [0x80 0x80] Connection: 5 0x18 0x19 0x1a 0x1b 0x1d
this is an example from my laptop. Normally this widget connected to the audio selector like this:
Node 0x23 [Audio Selector] wcaps 0x300101: Stereo Connection: 7 0x18 0x19 0x1a 0x1b 0x1d 0x12* 0x0b
ALSA will list only attached to "Audio Selector" "Mic" or "Line in" pins, not "Audio mixer". ALSA do not give control for audio mixer too.
Just because STAC/IDT codecs have no mixer widget. It's a hardware issue.
i talking about "IDT 92HD73E1X5" wich _has_ mixer widget. I use it on windows and i can use it on linux (directly, by controlling it with hda-verb). So this is not hardware issue. Here is the part of codecdump from IDT 92HD73E1X5:
Node 0x1d [Audio Mixer] wcaps 0x20010b: Stereo Amp-In Amp-In caps: ofs=0x17, nsteps=0x1f, stepsize=0x05, mute=1 Amp-In vals: [0x97 0x97] [0x97 0x97] [0x97 0x97] [0x97 0x97] [0x97 0x97] Connection: 5 0x28 0x29 0x2a 0x2b 0x12
Ah, yes, this codec has a mixer. But, Windows never uses the analog mixer. They do that all in the software side.
And, the current IDT/STAC parser doesn't support it too, because otherwise it makes the power-management more complex.
And, your machine has really no headphone detection? I mean, not about your taste but it's not physically doable?
HP detection working on rear green (0x0d), not on front green (0x0a). May be there is something wrong with connector. Anyway, it working fine under M$. May be we should provide UI control for this (to make user completely confused:)?
If Windows driver can detect the front HP jack, it means the connection is alive. You can try hda-verb to check whether the pin-detection works, independently from the driver setup.
Pin detection working only on rear panel, on front panel it do not working and on windows and on linux. Probably broken front panel jack... I assume windwos use different logic.
OK, then it's likely a typical problem of the cabling and the case model. In many cases, an AC97-style case is connected to a HD-audio board.
linux logic: if no hp, play sound to speaker and mute hp. if hp detected
- unmute hp and mute speaker.
winodws logic: if no hp detected play to hp and to speaker, if hp detected - mute speaker and continue play to hp.
I think, if ALSA will behave in same way it will need less hp quirks.
Yes, that's how no_jd model works.
But, keeping the headphone output even with unplugged state means you are wasting unneeded power. The driver powers down the circuit appropriately if a pin isn't being used. That's why the headphone detection is implemented as default.
And, whether the HP detection works or not doesn't depend on the mobo. It's rather the connection. So, giving the fixed "no-jd" option for a certain PCI SSID is basically wrong. Someone else might have a same mobo but with a right case with the front-panel jack detection.
That is, it's fine to create a new quirk model, but assigning statically to that workaround isn't always acceptable.
Ok, i get the point. But no-jd should be provided as "Jack Detect Switch". I know... i tolking about work :)... probably i'll try to do this. But i think it make sense.
Why it must be a mixer switch? It's obviously a system configuration.
When you set up your car and choose a Diesel or Gas motor, would you like to change it with a gear?
Takashi
participants (2)
-
Alexey Fisher -
Takashi Iwai