[alsa-devel] Conexant CX20582 HDA codec support
Hi,
I'm working on some sound issues with the new OLPC XO-1.5 alpha board. This laptop is now based on a VIA VX855 chipset and our board includes a CX20582-10Q HDA codec. We are running kernel v2.6.30.
We have a few issues, which are:
1. Volume range is ridiculous, you can go all the way down to -74dB gain. Beyond -42dB you can barely hear anything from the speakers, and I note that all my other systems only go down as far as -46.5dB.
2. No microphone automute. The internal microphone continues recording sound while there is an external one plugged in.
3. No speaker automute. The internal speakers continue playing sound while there are headphones plugged in.
4. Mixer arrangement is odd. There are 3 microphones: Mic, Mic 1, and Mic 2. Mic (the default) records nothing. Mic 1 and Mic 2 both seem to behave the same, and record from both internal and external microphones.
I looked into adding some quirks into patch_conexant.c to hopefully solve some of the above. However I note that there is no support for the CX20582, hence the generic HDA parser is being used. How has support for the other CX chips been developed -- are datasheets always required? (I'll try and get hold of one anyway)
Here is some more info. codec dump http://dev.laptop.org/~dsd/20090629/codec0.txt
codec graph http://dev.laptop.org/~dsd/20090629/codecgraph.svg
lspci entry http://dev.laptop.org/~dsd/20090629/lspci-entry.txt
verbose dmesg from probing http://dev.laptop.org/~dsd/20090629/dmesg-probe.txt
Any thoughts/input appreciated! Thanks, Daniel
On Mon, Jun 29, 2009 at 01:10:53PM +0100, Daniel Drake wrote:
- Volume range is ridiculous, you can go all the way down to -74dB
gain. Beyond -42dB you can barely hear anything from the speakers, and I note that all my other systems only go down as far as -46.5dB.
This is normally just a case of drivers exposing whatever control they get from the hardware. Devices will often expose very high degrees of attenuation since they're doing it anyway in order to implement the mute functionality.
At Mon, 29 Jun 2009 13:26:26 +0100, Mark Brown wrote:
On Mon, Jun 29, 2009 at 01:10:53PM +0100, Daniel Drake wrote:
- Volume range is ridiculous, you can go all the way down to -74dB
gain. Beyond -42dB you can barely hear anything from the speakers, and I note that all my other systems only go down as far as -46.5dB.
This is normally just a case of drivers exposing whatever control they get from the hardware. Devices will often expose very high degrees of attenuation since they're doing it anyway in order to implement the mute functionality.
Yep. There are some workaround for each codec chip. See create_controls_idx() in patch_sigmatel.c, for example.
Takashi
Hi,
On Mon, 2009-06-29 at 14:48 +0200, Takashi Iwai wrote:
At Mon, 29 Jun 2009 13:26:26 +0100, Mark Brown wrote:
On Mon, Jun 29, 2009 at 01:10:53PM +0100, Daniel Drake wrote:
- Volume range is ridiculous, you can go all the way down to -74dB
gain. Beyond -42dB you can barely hear anything from the speakers, and I note that all my other systems only go down as far as -46.5dB.
This is normally just a case of drivers exposing whatever control they get from the hardware. Devices will often expose very high degrees of attenuation since they're doing it anyway in order to implement the mute functionality.
Yep. There are some workaround for each codec chip. See create_controls_idx() in patch_sigmatel.c, for example.
Great. Do you have any other examples? This does not seem so easy for a non-virtual master.
This is my kcontrol for master: HDA_CODEC_VOLUME("Master Playback Volume", 0x10, 0x00, HDA_OUTPUT),
Thanks, Daniel
At Fri, 03 Jul 2009 21:05:37 +0100, Daniel Drake wrote:
Hi,
On Mon, 2009-06-29 at 14:48 +0200, Takashi Iwai wrote:
At Mon, 29 Jun 2009 13:26:26 +0100, Mark Brown wrote:
On Mon, Jun 29, 2009 at 01:10:53PM +0100, Daniel Drake wrote:
- Volume range is ridiculous, you can go all the way down to -74dB
gain. Beyond -42dB you can barely hear anything from the speakers, and I note that all my other systems only go down as far as -46.5dB.
This is normally just a case of drivers exposing whatever control they get from the hardware. Devices will often expose very high degrees of attenuation since they're doing it anyway in order to implement the mute functionality.
Yep. There are some workaround for each codec chip. See create_controls_idx() in patch_sigmatel.c, for example.
Great. Do you have any other examples? This does not seem so easy for a non-virtual master.
This is my kcontrol for master: HDA_CODEC_VOLUME("Master Playback Volume", 0x10, 0x00, HDA_OUTPUT),
Well, currently only patch_sigmatel.c uses the workaround. But, it's relatively easy. Define the element like
{ .iface = SNDRV_CTL_ELEM_IFACE_MIXER, .name = "Master Playback Volume", .access = SNDRV_CTL_ELEM_ACCESS_READWRITE | SNDRV_CTL_ELEM_ACCESS_TLV_READ | SNDRV_CTL_ELEM_ACCESS_TLV_CALLBACK, .info = snd_hda_mixer_amp_volume_info, .get = snd_hda_mixer_amp_volume_get, .put = snd_hda_mixer_amp_volume_put, .tlv = { .c = snd_hda_mixer_amp_tlv }, .private_value = HDA_COMPOSE_AMP_VAL_OFS(0x10, 3, 0, HDA_OUTPUT, 0x30), }
This is almost a plain expansion of HDA_CODE_VOLUME() macro except for the private_value field. It uses HDA_COMPOSE_AMP_VAL_OFS() instead. The last argument (0x30) is the offset of the volume steps. That is, if the volume has 127 steps (0x7f) and you want to set the lower limit to 0x30. Then pass 0x30 there.
The upper limit of the volume steps can be changed by snd_hda_override_amp_caps(), BTW.
Takashi
At Mon, 29 Jun 2009 13:10:53 +0100, Daniel Drake wrote:
Hi,
I'm working on some sound issues with the new OLPC XO-1.5 alpha board. This laptop is now based on a VIA VX855 chipset and our board includes a CX20582-10Q HDA codec. We are running kernel v2.6.30.
We have a few issues, which are:
- Volume range is ridiculous, you can go all the way down to -74dB
gain. Beyond -42dB you can barely hear anything from the speakers, and I note that all my other systems only go down as far as -46.5dB.
- No microphone automute. The internal microphone continues recording
sound while there is an external one plugged in.
The generic parser doesn't support this. It gives only a few basic functionalities, so far.
- No speaker automute. The internal speakers continue playing sound
while there are headphones plugged in.
Ditto.
- Mixer arrangement is odd. There are 3 microphones: Mic, Mic 1, and
Mic 2. Mic (the default) records nothing. Mic 1 and Mic 2 both seem to behave the same, and record from both internal and external microphones.
A similar issue. Likely a problem of the generic parser.
I looked into adding some quirks into patch_conexant.c to hopefully solve some of the above. However I note that there is no support for the CX20582, hence the generic HDA parser is being used. How has support for the other CX chips been developed -- are datasheets always required?
Ideally, yes. If the codec tree looks similar as other Conexant codecs, you can adapt patch_conexant.c...
Takashi
Hi,
On Mon, 2009-06-29 at 14:50 +0200, Takashi Iwai wrote:
Ideally, yes. If the codec tree looks similar as other Conexant codecs, you can adapt patch_conexant.c...
Thanks for the quick explanations to all my issues. Makes sense.
Our contacts at Conexant pointed us to this file: http://www.linuxant.com/alsa-driver/alsa-driver-linuxant-1.0.19ppch12-1.noar...
The patch_conexant.c inside includes support for CX20582 ("Pebble") and a few more. Complete list:
{ .id = 0x14f15061, .name = "CX2058? (Pebble)", .patch = patch_cxtppch }, { .id = 0x14f15066, .name = "CX20582 (Pebble)", .patch = patch_cxtppch }, { .id = 0x14f15067, .name = "CX20583 (Pebble 56-LQFP)", .patch = patch_cxtppch }, { .id = 0x14f15068, .name = "CX20584 (Pebble)", .patch = patch_cxtppch }, { .id = 0x14f15069, .name = "CX20585 (Pebble 56-QFN)", .patch = patch_cxtppch }, { .id = 0x14f15070, .name = "CX20592 (Pelican)", .patch = patch_cxtppch }, { .id = 0x14f15071, .name = "CX20593 (Pelican 56-LQFP)", .patch = patch_cxtppch }, { .id = 0x14f15072, .name = "CX20594 (Pelican)", .patch = patch_cxtppch }, { .id = 0x14f15073, .name = "CX20595 (Pelican 56-QFN)", .patch = patch_cxtppch }, { .id = 0x14f15074, .name = "CX2059? (Pelican)", .patch = patch_cxtppch }, { .id = 0x14f150D0, .name = "CX20688 (Cabo)", .patch = patch_cxtppch }, { .id = 0x14f150D4, .name = "CX20692 (Huntington)", .patch = patch_cxtppch }, { .id = 0x14f150D5, .name = "CX20693 (Huntington)", .patch = patch_cxtppch }, { .id = 0x14f150D6, .name = "CX20694 (Huntington)", .patch = patch_cxtppch }, { .id = 0x14f150D7, .name = "CX20695 (Huntington)", .patch = patch_cxtppch }, { .id = 0x14f12bfa, .mfg = 2, .name = "HSF", .patch = patch_cxthsfmodem }, { .id = 0x14f12c06, .mfg = 2, .name = "HSF", .patch = patch_cxthsfmodem }, { .id = 0x14f10000, .mask = 0xffff0000, .mfg = 2, .name = "HSF", .patch = patch_cxthsfmodem },
Perhaps a useful link to keep around in future if other people come along looking for new codec support...
Over the next few days, I plan to extract the CX20584 support, get it working on the XO-1.5 and then send you a patch.
Thanks, Daniel
On Tue, 2009-06-30 at 19:48 +0100, Daniel Drake wrote:
Our contacts at Conexant pointed us to this file: http://www.linuxant.com/alsa-driver/alsa-driver-linuxant-1.0.19ppch12-1.noar...
The patch_conexant.c inside includes support for CX20582 ("Pebble") and a few more.
Daniel, if the license is favourable I'd rather extract it all. Is it alright if I have a look at this for you on Thursday? (I might have time tomorrow but I can't guarantee it; I'll be in data centres most of the day)
Regards, Tony V.
On Tue, 2009-06-30 at 20:23 +0100, Tony Vroon wrote:
Daniel, if the license is favourable I'd rather extract it all. Is it alright if I have a look at this for you on Thursday? (I might have time tomorrow but I can't guarantee it; I'll be in data centres most of the day)
Please go ahead :) The code will need a little clean up, I think.
Daniel
participants (4)
-
Daniel Drake -
Mark Brown -
Takashi Iwai -
Tony Vroon