- Alsa-devel - mailman.alsa-project.org

Re: [alsa-devel] asihpi driver -> kernel
by Takashi Iwai 20 Dec '07

20 Dec '07

Hi Eliot, [it seems that you Cc'ed to the old alsa-devel ML so the last one seemed missing.] At Tue, 16 Oct 2007 14:47:15 +1300, Eliot Blennerhassett wrote: > > Hi Takashi, > > still trying to move forward on this... > > Looking for "what is the first step" change to make in your opinion? The first step would be to get closer to linux kernel coding style. Namely, - get rid of C++ style function names, variables and field names (no hungarian!) - remove API wrappers Eventually, we may get rid of unneeded typedefs, too. Then, we can begin with simplifying the driver structure. Currently, asihpi and hpi are almost indepedent implementations. This makes life harder. > Takashi Iwai wrote: > > At Wed, 05 Sep 2007 13:00:35 +1200, > > Eliot Blennerhassett wrote: > >> Hi Takashi, > >> > >> I'd like to talk more about what you think is needed to get asihpi driver > >> ready for kernel tree. > >> > >> I think for now we should put aside cosmetic coding style changes (eg. comment > >> style, whitespace etc.) these are fixable with combination of automated tools > >> and some monkey work. > >> > >> So, lets start with the hard part. If we can't solve that there is no point in > >> cosmetics! > >> > >> A while ago you said "The specific problem I'm concerned is the "glue-code" > >> style in HPI driver. The OS-independent wrapper code is often disliked by > >> kernel maintainers. " > >> > >> Can you point to specific examples. Even better suggest how you think it > >> should be done better. Either way I need to consider how your concerns could > >> be addressed without breaking our codebase for other OSes etc. > >> > >> thanks and regards > > > > The problem is that the whole "wrapping" is superfluous when you > > concentrate on Linux driver. Merging into the linux kernel tree means > > that the driver would be dedicated to Linux. It's no longer your > > child, and it's no longer for every other OS. Thus, "common codebase" > > doesn't exist per se. > > > > For example, the whole definitions in hpios_linux_kernel.h should go > > away. The driver should use the native kernel API instead. > > Even this is not so hard, as it a mechanical process to replace wrapped > calls with linux native calls. OK, then it's fine. > > I know it's a very hard decision. Supporting other OSes is very > > important in most cases. OTOH, the slim-down is the best way to make > > the driver code maintainable for other people. Honestly, I find it > > also hard to maintain/debug the current ASIHPI code. It's too > > different from the normal codes, and understanding it alone takes too > > much energy before analyzing the problem. > > This is where I need more input, because to _me_ (of course) the code is > understandable. > > Is it the whole source or just parts that are hard. > E.g toplevel asihpi.c Ok/No? The code in asihpi.c is readable enough. But, other parts are different. The difficulty is that the driver structure isn't straight (apart from the coding style issues). We have an entry point for PCI driver _and_ indepdendent HPI initialization. This is already puzzling because HPI is also assigned to the corresponding PCI device. Also, the message union/struct is another stuff that is pretty hard to follow. Since we use no C++, union is often bad for readability. Could it be a bit simpler? > > The coding-style issues are similar problems. When C++-style codes > > appear in the tree of C-codes, they are strange. Simply so. It makes > > difficult to find the problematic part. "A buggy part looks buggy" -- > > it's the whole point of having a uniform coding style. > > Again, a mechanical process to change comments and style etc. Then it's fine with me. Let's try and see the progress. > > These problems (different from others) make it impossible to merge to > > the upstream tree, so far. > > > > > > > >> Eliot > >> BTW I'm happy to conduct this discussion publically on alsa-devel, some other > >> people might learn something too... > > > > I think it's a good thing, too. Feel free to add alsa-devel to Cc in > > the next reply with citation. > > > >> For reference here is the source tree diagram. > >> > >> asihpi.c alsa driver toplevel > >> | > >> hpifunc.c message/response pack/unpack > >> | > >> hpimsgx.c hpi stream ownership, backend selection, some init > >> | > >> hpi6205.c hpi6000.c hpi4000.c card family drivers > >> | > >> hpicmn.c, hpios_linux.c hpidspcd.c hpidebug.c library code > >> > >> hpimod.c probing, HPI ioctl > >> > > > > > > thanks, > > > > Takashi thanks, Takashi

2 13

[alsa-devel] [PATCH] The alc268 input_mux should be a selector instead of mixer
by Jiang zhe 20 Dec '07

20 Dec '07

Hi, According to the [0003659], the node 0x23,0x24 is a selector. I checked the alc268 spec on the REALTEK website and it showed that they were selectors indeed. However, current code implement the alc268 input_mux in a mixer way. Signed-off-by: Jiang Zhe <zhe.jiang(a)intel.com> --- alsa-driver-hg20071219/alsa-kernel/pci/hda/patch_realtek.c 2007-12-18 09:00:08.000000000 +0800 +++ b/alsa-kernel/pci/hda/patch_realtek.c 2007-12-20 10:09:11.000000000 +0800 @@ -9196,19 +9196,13 @@ static struct hda_verb alc268_base_init_ {0x1c, AC_VERB_SET_AMP_GAIN_MUTE, AMP_OUT_MUTE}, {0x1d, AC_VERB_SET_AMP_GAIN_MUTE, (0x7000 | (0x00 << 8))}, - /* FIXME: use matrix-type input source selection */ - /* Mixer elements: 0x18, 19, 1a, 1c, 14, 15, 0b */ - /* Input mixer1: unmute Mic, F-Mic, Line, CD inputs */ - /* Input mixer2 */ - {0x23, AC_VERB_SET_AMP_GAIN_MUTE, (0x7000 | (0x00 << 8))}, - {0x23, AC_VERB_SET_AMP_GAIN_MUTE, (0x7000 | (0x01 << 8))}, - {0x23, AC_VERB_SET_AMP_GAIN_MUTE, (0x7000 | (0x02 << 8))}, - {0x23, AC_VERB_SET_AMP_GAIN_MUTE, (0x7000 | (0x03 << 8))}, - - {0x24, AC_VERB_SET_AMP_GAIN_MUTE, (0x7000 | (0x00 << 8))}, - {0x24, AC_VERB_SET_AMP_GAIN_MUTE, (0x7000 | (0x01 << 8))}, - {0x24, AC_VERB_SET_AMP_GAIN_MUTE, (0x7000 | (0x02 << 8))}, - {0x24, AC_VERB_SET_AMP_GAIN_MUTE, (0x7000 | (0x03 << 8))}, + /* Unmute Selector 23h,24h and set the default input to mic-in */ + + {0x23, AC_VERB_SET_CONNECT_SEL, 0x00}, + {0x23, AC_VERB_SET_AMP_GAIN_MUTE, AMP_OUT_UNMUTE}, + {0x24, AC_VERB_SET_CONNECT_SEL, 0x00}, + {0x24, AC_VERB_SET_AMP_GAIN_MUTE, AMP_OUT_UNMUTE}, + { } }; @@ -9253,29 +9247,14 @@ static int alc268_mux_enum_put(struct sn { struct hda_codec *codec = snd_kcontrol_chip(kcontrol); struct alc_spec *spec = codec->spec; - const struct hda_input_mux *imux = spec->input_mux; + unsigned int adc_idx = snd_ctl_get_ioffidx(kcontrol, &ucontrol->id); static hda_nid_t capture_mixers[3] = { 0x23, 0x24 }; hda_nid_t nid = capture_mixers[adc_idx]; - unsigned int *cur_val = &spec->cur_mux[adc_idx]; - unsigned int i, idx; - idx = ucontrol->value.enumerated.item[0]; - if (idx >= imux->num_items) - idx = imux->num_items - 1; - if (*cur_val == idx) - return 0; - for (i = 0; i < imux->num_items; i++) { - unsigned int v = (i == idx) ? 0 : HDA_AMP_MUTE; - snd_hda_codec_amp_stereo(codec, nid, HDA_INPUT, - imux->items[i].index, - HDA_AMP_MUTE, v); - snd_hda_codec_write_cache(codec, nid, 0, - AC_VERB_SET_CONNECT_SEL, - idx ); - } - *cur_val = idx; - return 1; + return snd_hda_input_mux_put(codec, spec->input_mux, ucontrol, + nid, + &spec->cur_mux[adc_idx]); } static struct snd_kcontrol_new alc268_capture_alt_mixer[] = {

2 1

[alsa-devel] [PATCH]Device ID for Toshiba laptop which uses AD1986A
by Jiang zhe 20 Dec '07

20 Dec '07

Hi, Please refer to the [0003662]. The model laptop-eapd get rid of the high-pitched noise. Signed-Off-by: Jiang Zhe <zhe.jiang(a)intel.com> --- alsa-driver-hg20071219/alsa-kernel/pci/hda/patch_analog.c 2007-12-20 09:40:37.000000000 +0800 +++ b/alsa-kernel/pci/hda/patch_analog.c 2007-12-20 09:23:05.000000000 +0800 @@ -859,6 +859,7 @@ static struct snd_pci_quirk ad1986a_cfg_ SND_PCI_QUIRK(0x17aa, 0x1017, "Lenovo A60", AD1986A_3STACK), SND_PCI_QUIRK(0x17aa, 0x2066, "Lenovo N100", AD1986A_LAPTOP_AUTOMUTE), SND_PCI_QUIRK(0x17c0, 0x2017, "Samsung M50", AD1986A_LAPTOP), + SND_PCI_QUIRK(0x1179, 0xff40, "Toshiba", AD1986A_LAPTOP_EAPD), {} };

2 1

[alsa-devel] Event notification
by Miloslaw Smyk 20 Dec '07

20 Dec '07

Hi, My app needs to know about the events occurring to a sound card. Specifically, I am interested in start, stop, pause and volume change. While I could monitor volume by similar means as alsamixer does (is there any doc on this apart from the source code?), I am not sure if monitoring other events is at all possible. I would appreciate any suggestions as to how to do this. Kind Regards, Milek

2 1

[alsa-devel] pcm file question
by Leigh Stewart 20 Dec '07

20 Dec '07

hey all, im writing a little app that needs to tie into the audio in/out-put from another alsa application. in other words i need to take all audio produced by the app and do some work with it, and supply data to its audio input. im not sure but i think the pcm_file plugin will allow me to do what i need to do. i.e. i as i understand it i could tie the audio output to a fifo file using the plugin, and then read from the file. anyway im not sure how write a program that uses the plugin code. i wrote something like ... > #include <alsa/asoundlib.h> > #include <iostream> > #include <alsa/pcm.h> > #include <alsa/pcm_plugin.h> > ... > err = snd_pcm_file_open (&pcm_handle, pcm_name, (char*)0, fdo, (char*)0, > fdi, "raw", 777, capture_handle, 0); > if(err < 0) { > fprintf (stderr, "cannot open pcm_file device %s (%s)\n", pcm_name, > snd_strerror (err)); > exit (1); > } but there are no method signatures in pcm_plugin.h. i've tried building alsa from source 1.0.15. i see method signatures for copy and dmix, and even jack, but not for file. how can i compile the plugin in? can i even use pcm_file programmatically? can anyone refer me to any examples? thanks, lstewart

1 0

[alsa-devel] [PATCH 3/12] neo1973: ASoC include pathname fix
by Harald Welte 19 Dec '07

19 Dec '07

[PATCH] Fix s3c24xx include file path changes in asoc driver Signed-off-by: Harald Welte <laforge(a)openmoko.org> --- Index: linux-2.6.22/sound/soc/s3c24xx/neo1973_wm8753.c =================================================================== --- linux-2.6.22.orig/sound/soc/s3c24xx/neo1973_wm8753.c +++ linux-2.6.22/sound/soc/s3c24xx/neo1973_wm8753.c @@ -30,13 +30,15 @@ #include <asm/mach-types.h> #include <asm/hardware/scoop.h> -#include <asm/arch/regs-iis.h> #include <asm/arch/regs-clock.h> #include <asm/arch/regs-gpio.h> #include <asm/hardware.h> #include <asm/arch/audio.h> #include <asm/io.h> #include <asm/arch/spi-gpio.h> + +#include <asm/plat-s3c24xx/regs-iis.h> + #include "../codecs/wm8753.h" #include "lm4857.h" #include "s3c24xx-pcm.h" Index: linux-2.6.22/sound/soc/s3c24xx/s3c24xx-i2s.c =================================================================== --- linux-2.6.22.orig/sound/soc/s3c24xx/s3c24xx-i2s.c +++ linux-2.6.22/sound/soc/s3c24xx/s3c24xx-i2s.c @@ -33,13 +33,14 @@ #include <asm/hardware.h> #include <asm/io.h> -#include <asm/arch/regs-iis.h> #include <asm/arch/regs-gpio.h> #include <asm/arch/regs-clock.h> #include <asm/arch/audio.h> #include <asm/dma.h> #include <asm/arch/dma.h> +#include <asm/plat-s3c24xx/regs-iis.h> + #include "s3c24xx-pcm.h" #include "s3c24xx-i2s.h" -- - Harald Welte <laforge(a)openmoko.org> http://openmoko.org/ ============================================================================ Software for the world's first truly open Free Software mobile phone

2 2

[alsa-devel] snd-hda-intel support for SPDIF-in wiht vt1708 card?
by John Stile 19 Dec '07

19 Dec '07

I am trying to use a Via VT1708 audio card ( uses the snd-hda-intel.ko driver) to record from SPDIF-in. An off-list reply to my posting to alsa-users list suggested that snd-hda-intel.ko might not support SPDIF-in with the VT1708 card, which brought me here. Can someone who works on the Intel HDA driver tell me if it supports SPDIF-in on the VT1708 audio card? Should 'arecord -L' show "Digital Audio Input"? Environment: Audio Card: VT1708 ALSA version: 1.0.15 (as gentoo packages) Driver: snd-hda-intel.ko (In-kernel) Kernel: 2.6.23-gentoo-r3 Distribution: Gentoo Systemboard: PX10000G (VIA pico-itx) Case: Serener GS-L08 case

3 7

[alsa-devel] interesting message, but not sure where its coming from
by Christopher Johnson 19 Dec '07

19 Dec '07

I'm working on a complicated program that uses the ALSA library in an embedded environment. I have things working pretty well, although occasionally I get the following message printed on the console: buffer empty, loop_cnt 4727, loop_cnt_of_last_copy 4682, last period elapsed 4700, elapsed flag 0, chip_data->prev_cnt F000 buffer empty, loop_cnt 4758, loop_cnt_of_last_copy 4727, last period elapsed 4700, elapsed flag 0, chip_data->prev_cnt F000 I know this isn't my code, and I can't find anything that looks like this in the alsa library or the kernel. Does anybody recognize this?

2 1

[alsa-devel] Fix capture mixers of ALC662 models
by Herton Ronaldo Krzesinski 19 Dec '07

19 Dec '07

The below patches fixes capture mixers of ALC662 models. The first one applies to current hg tree, the second one to Linus tree (2.6.24-rcX). The commit that added support for ASUS P701 eeepc also changed the mixers of other ALC662 models, duplicating entries for the Capture items, making them to not work anymore. This fixes it by removing duplicated entries using where possible the common alc662_capture_mixer. Also alc662_capture_mixer should use alc662* functions and not alc882 (I checked /proc/asound/card0/codec* on an eepc model and it's ok). Signed-off-by: Herton Ronaldo Krzesinski <herton(a)mandriva.com> --- alsa-kernel/pci/hda/patch_realtek.c.orig 2007-12-18 21:57:02.000000000 -0200 +++ alsa-kernel/pci/hda/patch_realtek.c 2007-12-18 22:01:24.000000000 -0200 @@ -12364,17 +12364,6 @@ static struct snd_kcontrol_new alc662_3S HDA_CODEC_MUTE("Front Mic Playback Switch", 0x0b, 0x1, HDA_INPUT), HDA_CODEC_VOLUME("PC Speaker Playback Volume", 0x0b, 0x05, HDA_INPUT), HDA_CODEC_MUTE("PC Speaker Playback Switch", 0x0b, 0x05, HDA_INPUT), - HDA_CODEC_VOLUME("Capture Volume", 0x09, 0x0, HDA_INPUT), - HDA_CODEC_MUTE("Capture Switch", 0x09, 0x0, HDA_INPUT), - { - .iface = SNDRV_CTL_ELEM_IFACE_MIXER, - /* .name = "Capture Source", */ - .name = "Input Source", - .count = 1, - .info = alc662_mux_enum_info, - .get = alc662_mux_enum_get, - .put = alc662_mux_enum_put, - }, { } /* end */ }; @@ -12398,17 +12387,6 @@ static struct snd_kcontrol_new alc662_3S HDA_CODEC_MUTE("Front Mic Playback Switch", 0x0b, 0x1, HDA_INPUT), HDA_CODEC_VOLUME("PC Speaker Playback Volume", 0x0b, 0x05, HDA_INPUT), HDA_CODEC_MUTE("PC Speaker Playback Switch", 0x0b, 0x05, HDA_INPUT), - HDA_CODEC_VOLUME("Capture Volume", 0x09, 0x0, HDA_INPUT), - HDA_CODEC_MUTE("Capture Switch", 0x09, 0x0, HDA_INPUT), - { - .iface = SNDRV_CTL_ELEM_IFACE_MIXER, - /* .name = "Capture Source", */ - .name = "Input Source", - .count = 1, - .info = alc662_mux_enum_info, - .get = alc662_mux_enum_get, - .put = alc662_mux_enum_put, - }, { } /* end */ }; @@ -12422,17 +12400,6 @@ static struct snd_kcontrol_new alc662_le HDA_CODEC_MUTE("Line Playback Switch", 0x0b, 0x02, HDA_INPUT), HDA_CODEC_VOLUME("Mic Playback Volume", 0x0b, 0x1, HDA_INPUT), HDA_CODEC_MUTE("Mic Playback Switch", 0x0b, 0x1, HDA_INPUT), - HDA_CODEC_VOLUME("Capture Volume", 0x09, 0x0, HDA_INPUT), - HDA_CODEC_MUTE("Capture Switch", 0x09, 0x0, HDA_INPUT), - { - .iface = SNDRV_CTL_ELEM_IFACE_MIXER, - /* .name = "Capture Source", */ - .name = "Input Source", - .count = 1, - .info = alc662_mux_enum_info, - .get = alc662_mux_enum_get, - .put = alc662_mux_enum_put, - }, { } /* end */ }; @@ -12463,6 +12430,25 @@ static struct snd_kcontrol_new alc662_ch { } /* end */ }; +/* capture mixer elements */ +static struct snd_kcontrol_new alc662_capture_mixer[] = { + HDA_CODEC_VOLUME("Capture Volume", 0x09, 0x0, HDA_INPUT), + HDA_CODEC_MUTE("Capture Switch", 0x09, 0x0, HDA_INPUT), + { + .iface = SNDRV_CTL_ELEM_IFACE_MIXER, + /* The multiple "Capture Source" controls confuse alsamixer + * So call somewhat different.. + */ + /* .name = "Capture Source", */ + .name = "Input Source", + .count = 1, + .info = alc662_mux_enum_info, + .get = alc662_mux_enum_get, + .put = alc662_mux_enum_put, + }, + { } /* end */ +}; + static struct hda_verb alc662_init_verbs[] = { /* ADC: mute amp left and right */ {0x09, AC_VERB_SET_AMP_GAIN_MUTE, AMP_IN_MUTE(0)}, @@ -12585,26 +12571,6 @@ static struct hda_verb alc662_auto_init_ { } }; -/* capture mixer elements */ -static struct snd_kcontrol_new alc662_capture_mixer[] = { - HDA_CODEC_VOLUME("Capture Volume", 0x09, 0x0, HDA_INPUT), - HDA_CODEC_MUTE("Capture Switch", 0x09, 0x0, HDA_INPUT), - { - .iface = SNDRV_CTL_ELEM_IFACE_MIXER, - /* The multiple "Capture Source" controls confuse alsamixer - * So call somewhat different.. - * FIXME: the controls appear in the "playback" view! - */ - /* .name = "Capture Source", */ - .name = "Input Source", - .count = 1, - .info = alc882_mux_enum_info, - .get = alc882_mux_enum_get, - .put = alc882_mux_enum_put, - }, - { } /* end */ -}; - static void alc662_lenovo_101e_ispeaker_automute(struct hda_codec *codec) { unsigned int present; @@ -12746,8 +12712,7 @@ static struct alc_config_preset alc662_p .input_mux = &alc662_capture_source, }, [ALC662_5ST_DIG] = { - .mixers = { alc662_base_mixer, alc662_chmode_mixer, - alc662_capture_mixer }, + .mixers = { alc662_base_mixer, alc662_chmode_mixer }, .init_verbs = { alc662_init_verbs }, .num_dacs = ARRAY_SIZE(alc662_dac_nids), .dac_nids = alc662_dac_nids, The commit that added support for ASUS P701 eeepc also changed the mixers of other ALC662 models, duplicating entries for the Capture items, making them to not work anymore. This fixes it by removing duplicated entries using where possible the common alc662_capture_mixer. Also alc662_capture_mixer should use alc662* functions and not alc882 (I checked /proc/asound/card0/codec* on an eepc model and it's ok). Signed-off-by: Herton Ronaldo Krzesinski <herton(a)mandriva.com> diff --git a/sound/pci/hda/patch_realtek.c b/sound/pci/hda/patch_realtek.c index 1c50278..85e54d1 100644 --- a/sound/pci/hda/patch_realtek.c +++ b/sound/pci/hda/patch_realtek.c @@ -11728,17 +11728,6 @@ static struct snd_kcontrol_new alc662_3ST_2ch_mixer[] = { HDA_CODEC_MUTE("Front Mic Playback Switch", 0x0b, 0x1, HDA_INPUT), HDA_CODEC_VOLUME("PC Speaker Playback Volume", 0x0b, 0x05, HDA_INPUT), HDA_CODEC_MUTE("PC Speaker Playback Switch", 0x0b, 0x05, HDA_INPUT), - HDA_CODEC_VOLUME("Capture Volume", 0x09, 0x0, HDA_INPUT), - HDA_CODEC_MUTE("Capture Switch", 0x09, 0x0, HDA_INPUT), - { - .iface = SNDRV_CTL_ELEM_IFACE_MIXER, - /* .name = "Capture Source", */ - .name = "Input Source", - .count = 1, - .info = alc662_mux_enum_info, - .get = alc662_mux_enum_get, - .put = alc662_mux_enum_put, - }, { } /* end */ }; @@ -11762,17 +11751,6 @@ static struct snd_kcontrol_new alc662_3ST_6ch_mixer[] = { HDA_CODEC_MUTE("Front Mic Playback Switch", 0x0b, 0x1, HDA_INPUT), HDA_CODEC_VOLUME("PC Speaker Playback Volume", 0x0b, 0x05, HDA_INPUT), HDA_CODEC_MUTE("PC Speaker Playback Switch", 0x0b, 0x05, HDA_INPUT), - HDA_CODEC_VOLUME("Capture Volume", 0x09, 0x0, HDA_INPUT), - HDA_CODEC_MUTE("Capture Switch", 0x09, 0x0, HDA_INPUT), - { - .iface = SNDRV_CTL_ELEM_IFACE_MIXER, - /* .name = "Capture Source", */ - .name = "Input Source", - .count = 1, - .info = alc662_mux_enum_info, - .get = alc662_mux_enum_get, - .put = alc662_mux_enum_put, - }, { } /* end */ }; @@ -11786,17 +11764,6 @@ static struct snd_kcontrol_new alc662_lenovo_101e_mixer[] = { HDA_CODEC_MUTE("Line Playback Switch", 0x0b, 0x02, HDA_INPUT), HDA_CODEC_VOLUME("Mic Playback Volume", 0x0b, 0x1, HDA_INPUT), HDA_CODEC_MUTE("Mic Playback Switch", 0x0b, 0x1, HDA_INPUT), - HDA_CODEC_VOLUME("Capture Volume", 0x09, 0x0, HDA_INPUT), - HDA_CODEC_MUTE("Capture Switch", 0x09, 0x0, HDA_INPUT), - { - .iface = SNDRV_CTL_ELEM_IFACE_MIXER, - /* .name = "Capture Source", */ - .name = "Input Source", - .count = 1, - .info = alc662_mux_enum_info, - .get = alc662_mux_enum_get, - .put = alc662_mux_enum_put, - }, { } /* end */ }; @@ -11827,6 +11794,25 @@ static struct snd_kcontrol_new alc662_chmode_mixer[] = { { } /* end */ }; +/* capture mixer elements */ +static struct snd_kcontrol_new alc662_capture_mixer[] = { + HDA_CODEC_VOLUME("Capture Volume", 0x09, 0x0, HDA_INPUT), + HDA_CODEC_MUTE("Capture Switch", 0x09, 0x0, HDA_INPUT), + { + .iface = SNDRV_CTL_ELEM_IFACE_MIXER, + /* The multiple "Capture Source" controls confuse alsamixer + * So call somewhat different.. + */ + /* .name = "Capture Source", */ + .name = "Input Source", + .count = 1, + .info = alc662_mux_enum_info, + .get = alc662_mux_enum_get, + .put = alc662_mux_enum_put, + }, + { } /* end */ +}; + static struct hda_verb alc662_init_verbs[] = { /* ADC: mute amp left and right */ {0x09, AC_VERB_SET_AMP_GAIN_MUTE, AMP_IN_MUTE(0)}, @@ -11949,26 +11935,6 @@ static struct hda_verb alc662_auto_init_verbs[] = { { } }; -/* capture mixer elements */ -static struct snd_kcontrol_new alc662_capture_mixer[] = { - HDA_CODEC_VOLUME("Capture Volume", 0x09, 0x0, HDA_INPUT), - HDA_CODEC_MUTE("Capture Switch", 0x09, 0x0, HDA_INPUT), - { - .iface = SNDRV_CTL_ELEM_IFACE_MIXER, - /* The multiple "Capture Source" controls confuse alsamixer - * So call somewhat different.. - * FIXME: the controls appear in the "playback" view! - */ - /* .name = "Capture Source", */ - .name = "Input Source", - .count = 1, - .info = alc882_mux_enum_info, - .get = alc882_mux_enum_get, - .put = alc882_mux_enum_put, - }, - { } /* end */ -}; - static void alc662_lenovo_101e_ispeaker_automute(struct hda_codec *codec) { unsigned int present; @@ -12109,8 +12075,7 @@ static struct alc_config_preset alc662_presets[] = { .input_mux = &alc662_capture_source, }, [ALC662_5ST_DIG] = { - .mixers = { alc662_base_mixer, alc662_chmode_mixer, - alc662_capture_mixer }, + .mixers = { alc662_base_mixer, alc662_chmode_mixer }, .init_verbs = { alc662_init_verbs }, .num_dacs = ARRAY_SIZE(alc662_dac_nids), .dac_nids = alc662_dac_nids, -- []'s Herton

2 3

[alsa-devel] [PATCH] Dmux mixer conflict
by Matthew Ranostay 19 Dec '07

19 Dec '07

DMUX mixers need to be created before input source mixers, otherwise some STAC9228 codecs fail to record correctly or at all. --- Signed-off-by: Matthew Ranostay <mranostay(a)embeddedalley.com> diff -r fbe3540c8df4 pci/hda/patch_sigmatel.c --- a/pci/hda/patch_sigmatel.c Tue Dec 18 18:05:52 2007 +0100 +++ b/pci/hda/patch_sigmatel.c Tue Dec 18 15:27:34 2007 -0700 @@ -834,15 +834,16 @@ static int stac92xx_build_controls(struc if (err < 0) return err; - for (i = 0; i < spec->num_mixers; i++) { - err = snd_hda_add_new_ctls(codec, spec->mixers[i]); - if (err < 0) - return err; - } if (spec->num_dmuxes > 0) { stac_dmux_mixer.count = spec->num_dmuxes; err = snd_ctl_add(codec->bus->card, snd_ctl_new1(&stac_dmux_mixer, codec)); + if (err < 0) + return err; + } + + for (i = 0; i < spec->num_mixers; i++) { + err = snd_hda_add_new_ctls(codec, spec->mixers[i]); if (err < 0) return err; }

2 2