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

[alsa-devel] [PATCH 2/2] ALSA: hda - support OLPC XO-1.5 DC input
by Daniel Drake 08 Jan '10

08 Jan '10

The XO's audio hardware is wired up to allow DC sensors (e.g. light sensors, thermistors, etc) to be plugged in through the microphone jack. Add sound mixer controls to allow this mode to be enabled and tweaked. Signed-off-by: Daniel Drake <dsd(a)laptop.org> --- sound/pci/hda/patch_conexant.c | 213 +++++++++++++++++++++++++++++++++++----- 1 files changed, 190 insertions(+), 23 deletions(-) diff --git a/sound/pci/hda/patch_conexant.c b/sound/pci/hda/patch_conexant.c index 9ad1219..ffc609e 100644 --- a/sound/pci/hda/patch_conexant.c +++ b/sound/pci/hda/patch_conexant.c @@ -117,6 +117,16 @@ struct conexant_spec { unsigned int recording; void (*capture_prepare)(struct hda_codec *codec); void (*capture_cleanup)(struct hda_codec *codec); + + /* OLPC XO-1.5 supports DC input mode (e.g. for use with analog sensors) + * through the microphone jack. + * When the user enables this through a mixer switch, both internal and + * external microphones are disabled. Gain is fixed at 0dB. In this mode, + * we also allow the bias to be configured through a separate mixer + * control. */ + unsigned int dc_enable; + unsigned int dc_input_bias; /* offset into cxt5066_olpc_dc_bias */ + unsigned int mic_boost; /* offset into cxt5066_analog_mic_boost */ }; static int conexant_playback_pcm_open(struct hda_pcm_stream *hinfo, @@ -1974,6 +1984,26 @@ static int cxt5066_hp_master_sw_put(struct snd_kcontrol *kcontrol, return 1; } +static const struct hda_input_mux cxt5066_olpc_dc_bias = { + .num_items = 3, + .items = { + { "Off", PIN_IN }, + { "50%", PIN_VREF50 }, + { "80%", PIN_VREF80 }, + }, +}; + +static int cxt5066_set_olpc_dc_bias(struct hda_codec *codec) +{ + struct conexant_spec *spec = codec->spec; + /* Even though port F is the DC input, the bias is controlled on port B. + * we also leave that port as an active input (but unselected) in DC mode + * just in case that is necessary to make the bias setting take effect. */ + return snd_hda_codec_write_cache(codec, 0x1a, 0, + AC_VERB_SET_PIN_WIDGET_CONTROL, + cxt5066_olpc_dc_bias.items[spec->dc_input_bias].index); +} + /* OLPC defers mic widget control until when capture is started because the * microphone LED comes on as soon as these settings are put in place. if we * did this before recording, it would give the false indication that recording @@ -1984,6 +2014,27 @@ static void cxt5066_olpc_select_mic(struct hda_codec *codec) if (!spec->recording) return; + if (spec->dc_enable) { + /* in DC mode we ignore presence detection and just use the jack + * through our special DC port */ + const struct hda_verb enable_dc_mode[] = { + /* disble internal mic, port C */ + {0x1b, AC_VERB_SET_PIN_WIDGET_CONTROL, 0}, + + /* enable DC capture, port F */ + {0x1e, AC_VERB_SET_PIN_WIDGET_CONTROL, PIN_IN}, + {}, + }; + + snd_hda_sequence_write(codec, enable_dc_mode); + /* port B input disabled (and bias set) through the following call */ + cxt5066_set_olpc_dc_bias(codec); + return; + } + + /* disable DC (port F) */ + snd_hda_codec_write(codec, 0x1e, 0, AC_VERB_SET_PIN_WIDGET_CONTROL, 0); + /* external mic, port B */ snd_hda_codec_write(codec, 0x1a, 0, AC_VERB_SET_PIN_WIDGET_CONTROL, spec->ext_mic_present ? CXT5066_OLPC_EXT_MIC_BIAS : 0); @@ -1999,6 +2050,9 @@ static void cxt5066_olpc_automic(struct hda_codec *codec) struct conexant_spec *spec = codec->spec; unsigned int present; + if (spec->dc_enable) /* don't do presence detection in DC mode */ + return; + present = snd_hda_codec_read(codec, 0x1a, 0, AC_VERB_GET_PIN_SENSE, 0) & 0x80000000; if (present) @@ -2073,13 +2127,16 @@ static void cxt5066_hp_automute(struct hda_codec *codec) /* unsolicited event for jack sensing */ static void cxt5066_olpc_unsol_event(struct hda_codec *codec, unsigned int res) { + struct conexant_spec *spec = codec->spec; snd_printdd("CXT5066: unsol event %x (%x)\n", res, res >> 26); switch (res >> 26) { case CONEXANT_HP_EVENT: cxt5066_hp_automute(codec); break; case CONEXANT_MIC_EVENT: - cxt5066_olpc_automic(codec); + /* ignore mic events in DC mode; we're always using the jack */ + if (!spec->dc_enable) + cxt5066_olpc_automic(codec); break; } } @@ -2109,6 +2166,15 @@ static const struct hda_input_mux cxt5066_analog_mic_boost = { }, }; +static int cxt5066_set_mic_boost(struct hda_codec *codec) +{ + struct conexant_spec *spec = codec->spec; + return snd_hda_codec_write_cache(codec, 0x17, 0, + AC_VERB_SET_AMP_GAIN_MUTE, + AC_AMP_SET_RIGHT | AC_AMP_SET_LEFT | AC_AMP_SET_OUTPUT | + cxt5066_analog_mic_boost.items[spec->mic_boost].index); +} + static int cxt5066_mic_boost_mux_enum_info(struct snd_kcontrol *kcontrol, struct snd_ctl_elem_info *uinfo) { @@ -2119,15 +2185,8 @@ static int cxt5066_mic_boost_mux_enum_get(struct snd_kcontrol *kcontrol, struct snd_ctl_elem_value *ucontrol) { struct hda_codec *codec = snd_kcontrol_chip(kcontrol); - int val; - hda_nid_t nid = kcontrol->private_value & 0xff; - int inout = (kcontrol->private_value & 0x100) ? - AC_AMP_GET_INPUT : AC_AMP_GET_OUTPUT; - - val = snd_hda_codec_read(codec, nid, 0, - AC_VERB_GET_AMP_GAIN_MUTE, inout); - - ucontrol->value.enumerated.item[0] = val & AC_AMP_GAIN; + struct conexant_spec *spec = codec->spec; + ucontrol->value.enumerated.item[0] = spec->mic_boost; return 0; } @@ -2135,23 +2194,101 @@ static int cxt5066_mic_boost_mux_enum_put(struct snd_kcontrol *kcontrol, struct snd_ctl_elem_value *ucontrol) { struct hda_codec *codec = snd_kcontrol_chip(kcontrol); + struct conexant_spec *spec = codec->spec; const struct hda_input_mux *imux = &cxt5066_analog_mic_boost; unsigned int idx; - hda_nid_t nid = kcontrol->private_value & 0xff; - int inout = (kcontrol->private_value & 0x100) ? - AC_AMP_SET_INPUT : AC_AMP_SET_OUTPUT; + idx = ucontrol->value.enumerated.item[0]; + if (idx >= imux->num_items) + idx = imux->num_items - 1; + + spec->mic_boost = idx; + if (!spec->dc_enable) + cxt5066_set_mic_boost(codec); + return 1; +} + +static void cxt5066_enable_dc(struct hda_codec *codec) +{ + const struct hda_verb enable_dc_mode[] = { + /* disable gain */ + {0x17, AC_VERB_SET_AMP_GAIN_MUTE, AMP_OUT_UNMUTE}, + + /* switch to DC input */ + {0x17, AC_VERB_SET_CONNECT_SEL, 3}, + {} + }; + + /* configure as input source */ + snd_hda_sequence_write(codec, enable_dc_mode); + cxt5066_olpc_select_mic(codec); /* also sets configured bias */ +} + +static void cxt5066_disable_dc(struct hda_codec *codec) +{ + /* reconfigure input source */ + cxt5066_set_mic_boost(codec); + /* automic also selects the right mic if we're recording */ + cxt5066_olpc_automic(codec); +} + +static int cxt5066_olpc_dc_get(struct snd_kcontrol *kcontrol, + struct snd_ctl_elem_value *ucontrol) +{ + struct hda_codec *codec = snd_kcontrol_chip(kcontrol); + struct conexant_spec *spec = codec->spec; + ucontrol->value.integer.value[0] = spec->dc_enable; + return 0; +} - if (!imux->num_items) +static int cxt5066_olpc_dc_put(struct snd_kcontrol *kcontrol, + struct snd_ctl_elem_value *ucontrol) +{ + struct hda_codec *codec = snd_kcontrol_chip(kcontrol); + struct conexant_spec *spec = codec->spec; + int dc_enable = !!ucontrol->value.integer.value[0]; + + if (dc_enable == spec->dc_enable) return 0; + + spec->dc_enable = dc_enable; + if (dc_enable) + cxt5066_enable_dc(codec); + else + cxt5066_disable_dc(codec); + + return 1; +} + +static int cxt5066_olpc_dc_bias_enum_info(struct snd_kcontrol *kcontrol, + struct snd_ctl_elem_info *uinfo) +{ + return snd_hda_input_mux_info(&cxt5066_olpc_dc_bias, uinfo); +} + +static int cxt5066_olpc_dc_bias_enum_get(struct snd_kcontrol *kcontrol, + struct snd_ctl_elem_value *ucontrol) +{ + struct hda_codec *codec = snd_kcontrol_chip(kcontrol); + struct conexant_spec *spec = codec->spec; + ucontrol->value.enumerated.item[0] = spec->dc_input_bias; + return 0; +} + +static int cxt5066_olpc_dc_bias_enum_put(struct snd_kcontrol *kcontrol, + struct snd_ctl_elem_value *ucontrol) +{ + struct hda_codec *codec = snd_kcontrol_chip(kcontrol); + struct conexant_spec *spec = codec->spec; + const struct hda_input_mux *imux = &cxt5066_analog_mic_boost; + unsigned int idx; + idx = ucontrol->value.enumerated.item[0]; if (idx >= imux->num_items) idx = imux->num_items - 1; - snd_hda_codec_write_cache(codec, nid, 0, - AC_VERB_SET_AMP_GAIN_MUTE, - AC_AMP_SET_RIGHT | AC_AMP_SET_LEFT | inout | - imux->items[idx].index); - + spec->dc_input_bias = idx; + if (spec->dc_enable) + cxt5066_set_olpc_dc_bias(codec); return 1; } @@ -2173,6 +2310,9 @@ static void cxt5066_olpc_capture_cleanup(struct hda_codec *codec) /* disble internal mic, port C */ {0x1b, AC_VERB_SET_PIN_WIDGET_CONTROL, 0}, + + /* disable DC capture, port F */ + {0x1e, AC_VERB_SET_PIN_WIDGET_CONTROL, 0}, {}, }; @@ -2231,6 +2371,24 @@ static struct snd_kcontrol_new cxt5066_mixer_master_olpc[] = { {} }; +static struct snd_kcontrol_new cxt5066_mixer_olpc_dc[] = { + { + .iface = SNDRV_CTL_ELEM_IFACE_MIXER, + .name = "DC Mode Enable Switch", + .info = snd_ctl_boolean_mono_info, + .get = cxt5066_olpc_dc_get, + .put = cxt5066_olpc_dc_put, + }, + { + .iface = SNDRV_CTL_ELEM_IFACE_MIXER, + .name = "DC Input Bias Enum", + .info = cxt5066_olpc_dc_bias_enum_info, + .get = cxt5066_olpc_dc_bias_enum_get, + .put = cxt5066_olpc_dc_bias_enum_put, + }, + {} +}; + static struct snd_kcontrol_new cxt5066_mixers[] = { { .iface = SNDRV_CTL_ELEM_IFACE_MIXER, @@ -2243,11 +2401,10 @@ static struct snd_kcontrol_new cxt5066_mixers[] = { { .iface = SNDRV_CTL_ELEM_IFACE_MIXER, - .name = "Ext Mic Boost Capture Enum", + .name = "Analog Mic Boost Capture Enum", .info = cxt5066_mic_boost_mux_enum_info, .get = cxt5066_mic_boost_mux_enum_get, .put = cxt5066_mic_boost_mux_enum_put, - .private_value = 0x17, }, HDA_BIND_VOL("Capture Volume", &cxt5066_bind_capture_vol_others), @@ -2341,7 +2498,7 @@ static struct hda_verb cxt5066_init_verbs_olpc[] = { {0x1d, AC_VERB_SET_PIN_WIDGET_CONTROL, 0}, {0x1d, AC_VERB_SET_EAPD_BTLENABLE, 0x2}, /* default on */ - /* Port F: unused */ + /* Port F: external DC input through microphone port */ {0x1e, AC_VERB_SET_PIN_WIDGET_CONTROL, 0}, /* Port G: internal speakers */ @@ -2462,15 +2619,22 @@ static int cxt5066_init(struct hda_codec *codec) if (spec->dell_vostro) cxt5066_vostro_automic(codec); } + cxt5066_set_mic_boost(codec); return 0; } static int cxt5066_olpc_init(struct hda_codec *codec) { + struct conexant_spec *spec = codec->spec; snd_printdd("CXT5066: init\n"); conexant_init(codec); cxt5066_hp_automute(codec); - cxt5066_olpc_automic(codec); + if (!spec->dc_enable) { + cxt5066_set_mic_boost(codec); + cxt5066_olpc_automic(codec); + } else { + cxt5066_enable_dc(codec); + } return 0; } @@ -2553,8 +2717,10 @@ static int patch_cxt5066(struct hda_codec *codec) codec->patch_ops.unsol_event = cxt5066_olpc_unsol_event; spec->init_verbs[0] = cxt5066_init_verbs_olpc; spec->mixers[spec->num_mixers++] = cxt5066_mixer_master_olpc; + spec->mixers[spec->num_mixers++] = cxt5066_mixer_olpc_dc; spec->mixers[spec->num_mixers++] = cxt5066_mixers; spec->port_d_mode = 0; + spec->mic_boost = 3; /* default 30dB gain */ /* no S/PDIF out */ spec->multiout.dig_out_nid = 0; @@ -2576,6 +2742,7 @@ static int patch_cxt5066(struct hda_codec *codec) spec->mixers[spec->num_mixers++] = cxt5066_vostro_mixers; spec->port_d_mode = 0; spec->dell_vostro = 1; + spec->mic_boost = 3; /* default 30dB gain */ snd_hda_attach_beep_device(codec, 0x13); /* no S/PDIF out */ -- 1.6.2.5

2 1

[alsa-devel] [PATCH 1/2] ALSA: hda - Configure XO-1.5 microphones at capture time
by Daniel Drake 08 Jan '10

08 Jan '10

The XO-1.5 has a microphone LED designed to indicate to the user when something is being recorded. This light is controlled by the microphone bias voltage and it is currently coming on all the time. This patch defers the microphone port configuration until when recording is actually taking place, fixing the behaviour of the LED. Signed-off-by: Daniel Drake <dsd(a)laptop.org> --- sound/pci/hda/patch_conexant.c | 125 +++++++++++++++++++++++++++------------- 1 files changed, 85 insertions(+), 40 deletions(-) diff --git a/sound/pci/hda/patch_conexant.c b/sound/pci/hda/patch_conexant.c index c578c28..9ad1219 100644 --- a/sound/pci/hda/patch_conexant.c +++ b/sound/pci/hda/patch_conexant.c @@ -111,8 +111,12 @@ struct conexant_spec { unsigned int dell_automute; unsigned int port_d_mode; - unsigned char ext_mic_bias; unsigned int dell_vostro; + + unsigned int ext_mic_present; + unsigned int recording; + void (*capture_prepare)(struct hda_codec *codec); + void (*capture_cleanup)(struct hda_codec *codec); }; static int conexant_playback_pcm_open(struct hda_pcm_stream *hinfo, @@ -185,6 +189,8 @@ static int conexant_capture_pcm_prepare(struct hda_pcm_stream *hinfo, struct snd_pcm_substream *substream) { struct conexant_spec *spec = codec->spec; + if (spec->capture_prepare) + spec->capture_prepare(codec); snd_hda_codec_setup_stream(codec, spec->adc_nids[substream->number], stream_tag, 0, format); return 0; @@ -196,6 +202,8 @@ static int conexant_capture_pcm_cleanup(struct hda_pcm_stream *hinfo, { struct conexant_spec *spec = codec->spec; snd_hda_codec_cleanup_stream(codec, spec->adc_nids[substream->number]); + if (spec->capture_cleanup) + spec->capture_cleanup(codec); return 0; } @@ -1966,53 +1974,53 @@ static int cxt5066_hp_master_sw_put(struct snd_kcontrol *kcontrol, return 1; } -/* toggle input of built-in and mic jack appropriately */ -static void cxt5066_automic(struct hda_codec *codec) +/* OLPC defers mic widget control until when capture is started because the + * microphone LED comes on as soon as these settings are put in place. if we + * did this before recording, it would give the false indication that recording + * is happening when it is not. */ +static void cxt5066_olpc_select_mic(struct hda_codec *codec) { struct conexant_spec *spec = codec->spec; - struct hda_verb ext_mic_present[] = { - /* enable external mic, port B */ - {0x1a, AC_VERB_SET_PIN_WIDGET_CONTROL, spec->ext_mic_bias}, - - /* switch to external mic input */ - {0x17, AC_VERB_SET_CONNECT_SEL, 0}, + if (!spec->recording) + return; - /* disable internal mic, port C */ - {0x1b, AC_VERB_SET_PIN_WIDGET_CONTROL, 0}, - {} - }; - static struct hda_verb ext_mic_absent[] = { - /* enable internal mic, port C */ - {0x1b, AC_VERB_SET_PIN_WIDGET_CONTROL, PIN_VREF80}, + /* external mic, port B */ + snd_hda_codec_write(codec, 0x1a, 0, AC_VERB_SET_PIN_WIDGET_CONTROL, + spec->ext_mic_present ? CXT5066_OLPC_EXT_MIC_BIAS : 0); - /* switch to internal mic input */ - {0x17, AC_VERB_SET_CONNECT_SEL, 1}, + /* internal mic, port C */ + snd_hda_codec_write(codec, 0x1b, 0, AC_VERB_SET_PIN_WIDGET_CONTROL, + spec->ext_mic_present ? 0 : PIN_VREF80); +} - /* disable external mic, port B */ - {0x1a, AC_VERB_SET_PIN_WIDGET_CONTROL, 0}, - {} - }; +/* toggle input of built-in and mic jack appropriately */ +static void cxt5066_olpc_automic(struct hda_codec *codec) +{ + struct conexant_spec *spec = codec->spec; unsigned int present; - present = snd_hda_jack_detect(codec, 0x1a); - if (present) { + present = snd_hda_codec_read(codec, 0x1a, 0, + AC_VERB_GET_PIN_SENSE, 0) & 0x80000000; + if (present) snd_printdd("CXT5066: external microphone detected\n"); - snd_hda_sequence_write(codec, ext_mic_present); - } else { + else snd_printdd("CXT5066: external microphone absent\n"); - snd_hda_sequence_write(codec, ext_mic_absent); - } + + snd_hda_codec_write(codec, 0x17, 0, AC_VERB_SET_CONNECT_SEL, + present ? 0 : 1); + spec->ext_mic_present = !!present; + + cxt5066_olpc_select_mic(codec); } /* toggle input of built-in digital mic and mic jack appropriately */ static void cxt5066_vostro_automic(struct hda_codec *codec) { - struct conexant_spec *spec = codec->spec; unsigned int present; struct hda_verb ext_mic_present[] = { /* enable external mic, port B */ - {0x1a, AC_VERB_SET_PIN_WIDGET_CONTROL, spec->ext_mic_bias}, + {0x1a, AC_VERB_SET_PIN_WIDGET_CONTROL, PIN_VREF80}, /* switch to external mic input */ {0x17, AC_VERB_SET_CONNECT_SEL, 0}, @@ -2063,7 +2071,7 @@ static void cxt5066_hp_automute(struct hda_codec *codec) } /* unsolicited event for jack sensing */ -static void cxt5066_unsol_event(struct hda_codec *codec, unsigned int res) +static void cxt5066_olpc_unsol_event(struct hda_codec *codec, unsigned int res) { snd_printdd("CXT5066: unsol event %x (%x)\n", res, res >> 26); switch (res >> 26) { @@ -2071,7 +2079,7 @@ static void cxt5066_unsol_event(struct hda_codec *codec, unsigned int res) cxt5066_hp_automute(codec); break; case CONEXANT_MIC_EVENT: - cxt5066_automic(codec); + cxt5066_olpc_automic(codec); break; } } @@ -2147,6 +2155,31 @@ static int cxt5066_mic_boost_mux_enum_put(struct snd_kcontrol *kcontrol, return 1; } +static void cxt5066_olpc_capture_prepare(struct hda_codec *codec) +{ + struct conexant_spec *spec = codec->spec; + /* mark as recording and configure the microphone widget so that the + * recording LED comes on. */ + spec->recording = 1; + cxt5066_olpc_select_mic(codec); +} + +static void cxt5066_olpc_capture_cleanup(struct hda_codec *codec) +{ + struct conexant_spec *spec = codec->spec; + const struct hda_verb disable_mics[] = { + /* disable external mic, port B */ + {0x1a, AC_VERB_SET_PIN_WIDGET_CONTROL, 0}, + + /* disble internal mic, port C */ + {0x1b, AC_VERB_SET_PIN_WIDGET_CONTROL, 0}, + {}, + }; + + snd_hda_sequence_write(codec, disable_mics); + spec->recording = 0; +} + static struct hda_input_mux cxt5066_capture_source = { .num_items = 4, .items = { @@ -2296,10 +2329,10 @@ static struct hda_verb cxt5066_init_verbs_olpc[] = { {0x19, AC_VERB_SET_CONNECT_SEL, 0x00}, /* DAC1 */ /* Port B: external microphone */ - {0x1a, AC_VERB_SET_PIN_WIDGET_CONTROL, CXT5066_OLPC_EXT_MIC_BIAS}, + {0x1a, AC_VERB_SET_PIN_WIDGET_CONTROL, 0}, /* Port C: internal microphone */ - {0x1b, AC_VERB_SET_PIN_WIDGET_CONTROL, PIN_VREF80}, + {0x1b, AC_VERB_SET_PIN_WIDGET_CONTROL, 0}, /* Port D: unused */ {0x1c, AC_VERB_SET_PIN_WIDGET_CONTROL, 0}, @@ -2428,12 +2461,19 @@ static int cxt5066_init(struct hda_codec *codec) cxt5066_hp_automute(codec); if (spec->dell_vostro) cxt5066_vostro_automic(codec); - else - cxt5066_automic(codec); } return 0; } +static int cxt5066_olpc_init(struct hda_codec *codec) +{ + snd_printdd("CXT5066: init\n"); + conexant_init(codec); + cxt5066_hp_automute(codec); + cxt5066_olpc_automic(codec); + return 0; +} + enum { CXT5066_LAPTOP, /* Laptops w/ EAPD support */ CXT5066_DELL_LAPTOP, /* Dell Laptop */ @@ -2470,7 +2510,7 @@ static int patch_cxt5066(struct hda_codec *codec) codec->spec = spec; codec->patch_ops = conexant_patch_ops; - codec->patch_ops.init = cxt5066_init; + codec->patch_ops.init = conexant_init; spec->dell_automute = 0; spec->multiout.max_channels = 2; @@ -2483,7 +2523,6 @@ static int patch_cxt5066(struct hda_codec *codec) spec->input_mux = &cxt5066_capture_source; spec->port_d_mode = PIN_HP; - spec->ext_mic_bias = PIN_VREF80; spec->num_init_verbs = 1; spec->init_verbs[0] = cxt5066_init_verbs; @@ -2510,20 +2549,26 @@ static int patch_cxt5066(struct hda_codec *codec) spec->dell_automute = 1; break; case CXT5066_OLPC_XO_1_5: - codec->patch_ops.unsol_event = cxt5066_unsol_event; + codec->patch_ops.init = cxt5066_olpc_init; + codec->patch_ops.unsol_event = cxt5066_olpc_unsol_event; spec->init_verbs[0] = cxt5066_init_verbs_olpc; spec->mixers[spec->num_mixers++] = cxt5066_mixer_master_olpc; spec->mixers[spec->num_mixers++] = cxt5066_mixers; spec->port_d_mode = 0; - spec->ext_mic_bias = CXT5066_OLPC_EXT_MIC_BIAS; /* no S/PDIF out */ spec->multiout.dig_out_nid = 0; /* input source automatically selected */ spec->input_mux = NULL; + + /* our capture hooks which allow us to turn on the microphone LED + * at the right time */ + spec->capture_prepare = cxt5066_olpc_capture_prepare; + spec->capture_cleanup = cxt5066_olpc_capture_cleanup; break; case CXT5066_DELL_VOSTO: + codec->patch_ops.init = cxt5066_init; codec->patch_ops.unsol_event = cxt5066_vostro_event; spec->init_verbs[0] = cxt5066_init_verbs_vostro; spec->mixers[spec->num_mixers++] = cxt5066_mixer_master_olpc; -- 1.6.2.5

2 1

[alsa-devel] [PATCH] ac97: merge WM9703 and WM9705 ops
by Krzysztof Helt 08 Jan '10

08 Jan '10

From: Krzysztof Helt <krzysztof.h1(a)wp.pl> The WM9705 and WM9703 ops are the same actually so use the same code for both. Signed-off-by: Krzysztof Helt <krzysztof.h1(a)wp.pl> --- I have another problem with the AC97. I have a Creative SB 128 card (model CT4810). It has the ST Micro AC97 codec. There is no ST Micro AC97 codec defined in the ALSA code. The sound plays ok, but reading of certain registers (e.g. whole range from 0x2a to 0x7a) ends with timeout. The codec ID (registers 0x7c and 0x7e) is "STM\04" (0x53544d04). The codec info is 20-bit DAC, 18-bit ADC, no 3D and reading of the tone control register (0x8) end with the timeout. I put photos on the card here: http://picasaweb.google.com/krzysztof.h1/PCISoundCards# Any help with identification is appreciated. Is there any list of codecs used by Creative in the SB 128/64/PCI cards? I suppose there were only few used. Regards, Krzysztof sound/pci/ac97/ac97_patch.c | 17 +---------------- 1 files changed, 1 insertions(+), 16 deletions(-) diff --git a/sound/pci/ac97/ac97_patch.c b/sound/pci/ac97/ac97_patch.c index 139cf3b..e288a55 100644 --- a/sound/pci/ac97/ac97_patch.c +++ b/sound/pci/ac97/ac97_patch.c @@ -544,25 +544,10 @@ static int patch_wolfson04(struct snd_ac97 * ac97) return 0; } -static int patch_wolfson_wm9705_specific(struct snd_ac97 * ac97) -{ - int err, i; - for (i = 0; i < ARRAY_SIZE(wm97xx_snd_ac97_controls); i++) { - if ((err = snd_ctl_add(ac97->bus->card, snd_ac97_cnew(&wm97xx_snd_ac97_controls[i], ac97))) < 0) - return err; - } - snd_ac97_write_cache(ac97, 0x72, 0x0808); - return 0; -} - -static struct snd_ac97_build_ops patch_wolfson_wm9705_ops = { - .build_specific = patch_wolfson_wm9705_specific, -}; - static int patch_wolfson05(struct snd_ac97 * ac97) { /* WM9705, WM9710 */ - ac97->build_ops = &patch_wolfson_wm9705_ops; + ac97->build_ops = &patch_wolfson_wm9703_ops; #ifdef CONFIG_TOUCHSCREEN_WM9705 /* WM9705 touchscreen uses AUX and VIDEO for touch */ ac97->flags |= AC97_HAS_NO_VIDEO | AC97_HAS_NO_AUX; -- 1.6.4 ---------------------------------------------------------------------- Co Ci sie dzisiaj snilo? Czy wiesz, co oznacza Twoj sen? Sprawdz w senniku >> http://link.interia.pl/f2532

2 1

[alsa-devel] ALSA Multichannel through HDMI
by John Ettedgui 08 Jan '10

08 Jan '10

Hello, (since I did not get any feedback on the user ml, I'm trying it here, sorry...) I am using the HDMI output of my radeonhd 4670 to get sound, but I cannot get ALSA to work with (5.1) multichannel, it only outputs to the front left and right speakers (checked by speaker-test). I tried following this howto: http://www.cse.ohio-state.edu/~bondhugu/alsamch.shtml but it did not do much for me... and whenever I tried to add slave.channels 6, I just could not use alsa anymore, it always complained about this line... I tried channels 6 as part of the slave.pcm{} too and got the same result... What should I look into? I tried with 2.6.32 and alsa-lib 1.0.21.a, and then 2.6.33-rc3 (stil using alsa-driver 1.0.21 it seems) and alsa-lib 1.0.22 and no success. I am using the radeonhd xorg driver to get HDMI audio. I compiled alsa-driver 1.0.22.1 on top of a 2.6.32.2 kernel and the result is still the same although this time I did not play with the asound.conf file. Pulse audio on top of alsa does give me a 5.0 setup or at least I can hear that from the speaker-test. Thank you, John

1 0

[alsa-devel] [PATCH, beta] Echoaudio, add suspend/resume support
by Giuliano Pochini 07 Jan '10

07 Jan '10

The following patched add suspend/resume support to all echoaudio drivers. They seem to work fine, but more testing is needed. Some testing have been performed on an IndigoIOx and a Layla3G (thanks to Mark Hills). The most important part which has not been tested is rawmidi. Is someone willing to try ? The following patches are against alsa-driver-1.0.22.1, but should be possible to apply them cleanly on other versions as well because no changes have been done recently. 1/4 Add firmware cache #1: When CONFIG_PM is enabled the firmware cannot be released because the driver may need it again to resume the card. With this patch the firmware is passed as an index of the struct firmware card_fw[] in place of a pointer. That same index is then uses to locate the firmware in the firmware cache. 2/4 Add firmware cache #2: This patch changes get_firmware(), free_firmware() and adds free_firmware_cache(). The first two functions implement a very simple cache and the latter is used to actually release all the stored firmwares when the module is unloaded. When CONFIG_PM is not enabled those functions act as before and free_firmware_cache() is a nop. 3/4 Add suspend support: This patch adds snd_echo_suspend() and snd_echo_resume() callbacks and suspend/resume trigger event handlers. It also makes hardware initialization and mixer setup two clearly distinct stages, so they can be used also in the resume procedure without messing the settings up. As a bonus all init_hw() functions (one for each card) are a little shorter and cleaner. 4/4 patch the patch: Updates pci/echoaudio/echoaudio.patch The patches are here, in the same order as above: http://www.webalice.it/g_pochini/ead/fw_cache_1.patch http://www.webalice.it/g_pochini/ead/fw_cache_2.patch http://www.webalice.it/g_pochini/ead/pm_suspend_10.patch http://www.webalice.it/g_pochini/ead/echoaudio.patch.patch Or if you prefer a single patch (54KB): http://www.webalice.it/g_pochini/ead/all_echoaudio_suspend.patch Please test and report, especially the rawmidi part. TIA. -- Giuliano.

1 0

[alsa-devel] [PATCH 0/2] Add Voice Codec support for DaVinci platforms
by Miguel Aguilar 07 Jan '10

07 Jan '10

Hi, The following patch series adds support for the Voice Codec in the Davinci platform and in this particular case for the DM365 EVM. The second patch of the series configures the DM365 EVM sound card with two audi subdevices the AIC3x codec and the voice codec. The voice codec driver was tested on the DM365 EVM, however when the AIC and Voice Codec are defined as subdevices of the sound card doesn't work properly, so please check the file sound/soc/davinci/davinci-evm.c. Thanks, -- Miguel Angel Aguilar Ulloa Embedded Software Engineer RidgeRun Embedded Solutions miguel.aguilar(a)ridgerun.com

1 0

[alsa-devel] issue with sound stopping and not being able to restart
by Andrew Kohlsmith (Mailing List Account) 07 Jan '10

07 Jan '10

Good afternoon, all, I am new to ALSA development, but experienced in C. I wrote up a little test application which simply opens one playback and one capture device and spits noise into the playback and recording it on the capture device. I cross- correlate the data streams to determine the "depth" or latency of the pipe, end-to-end. I'm using playback and capture callbacks to handle the audio. The program seems to work reasonably well, but at seemingly random times either the playback or capture stream will "hiccup" (xrun) -- I am handling this case, but it's fairly often that the stream does NOT resume and I'm stuck with either no playback or no capture. I've looked at the example programs and the documentation and I do not see what it is I'm doing wrong. I'm posting my code here, hopefully someone can show me the error of my way. Capture/playback setup (error checking removed): snd_pcm_open(handle, fname, stream, SND_PCM_NONBLOCK); snd_pcm_hw_params_malloc(hwptr); snd_pcm_hw_params_any(h, hwp); snd_pcm_hw_params_set_access(h, hwp, SND_PCM_ACCESS_RW_INTERLEAVED); snd_pcm_hw_params_set_format(h, hwp, SND_PCM_FORMAT_S16_LE); snd_pcm_hw_params_set_rate(h, hwp, 8000, 0); snd_pcm_hw_params_set_channels(h, hwp, 2); snd_pcm_hw_params_set_buffer_size(h, hwp, BUF_SIZE); snd_pcm_hw_params(h, hwp); At this point I have the capture or playback device set up for 16 bit signed linear data in interleaved format and two channels. I've set up the buffers to be 160 frames, or 20ms. Each of these calls is checked for errors, and I do verify that the rate, buffer size and buffer time are what I expect. There is nothing unusual going on with these calls that I can determine. I set up the playback and capture callbacks thusly (again checking for errors) snd_async_add_pcm_handler(&ahp, hp, playback_callback, &pb_data); snd_async_add_pcm_handler(&ahc, hc, capture_callback, &cap_data); At this point I believe I'm ready to go, all I have to do is start playback and capture: if((fcount = snd_pcm_writei(h[PLAYBACK], pb_data.buf, BUF_SIZE)) != BUF_SIZE) { if(fcount < 0) { if((e = snd_pcm_recover(h[PLAYBACK], fcount, 0)) < 0) fprintf(stderr, "initial: can't writei: %s\n", snd_strerror(e)); } else { fprintf(stderr, "initial: short write: %d instead of %d\n", fcount, BUF_SIZE); } } if((e = snd_pcm_start(h[CAPTURE])) < 0) { fprintf(stderr, "capture prepare error: %s\n", snd_strerror(e)); return 1; } Now the playback and capture handlers are called by ALSA as required. The capture handler looks like this: /* capture callback. Called by ALSA whenever a period time is up */ void capture_callback(snd_async_handler_t *ah) { snd_pcm_t *h = snd_async_handler_get_pcm(ah); struct async_data *d = snd_async_handler_get_callback_private(ah); snd_pcm_sframes_t fa; short *p; int i, fc, e, faloops; struct timeval tv; static int c=0; /* read in whatever is available */ fa = snd_pcm_avail_update(h); faloops = 0; while(fa > 0) { if(fa > BUF_SIZE) fa = BUF_SIZE; if((fc = snd_pcm_readi(h, d->buf, fa)) != fa) { if(fc < 0) { if((e = snd_pcm_recover(h, e, 0)) < 0) { fprintf(stderr, "callback: can't readi: %s\n", snd_strerror(e)); } fc = 0; } else { fprintf(stderr, "callback: short read: %d instead of %ld\n", fc, fa); } } for(i=0,p=&d->buf[0]; i<fc; i++) { *d->ptr++ = *p++; p++; if(d->ptr > &in[MAX_BUFS * (BUF_SIZE - 1)]) { d->ptr = (short *)&in[0]; } } c += fc; if(c >= BUF_SIZE) { gettimeofday(&tv, NULL); c -= BUF_SIZE; in_step++; if(in_step >= MAX_BUFS) in_step = 0; } frames_cap += fc; fa = snd_pcm_avail_update(h); faloops++; }; cap_faloops=faloops; } The playback callback is very similar: /* playback callback. Called by ALSA whenever a period time is up */ void playback_callback(snd_async_handler_t *ah) { snd_pcm_t *h = snd_async_handler_get_pcm(ah); struct async_data *d = snd_async_handler_get_callback_private(ah); snd_pcm_sframes_t fa; int i, fc, e, faloops; static int c=0; struct timeval tv; fa = snd_pcm_avail_update(h); faloops = 0; while(fa > 0) { if(fa > BUF_SIZE) fa = BUF_SIZE; for(i=0; i<fa; i++) { d->buf[i*2] = awgn(&noise_source); d->buf[i*2+1] = awgn(&noise_source); } if((fc = snd_pcm_writei(h, d->buf, fa)) != fa) { if(fc < 0) { if((e = snd_pcm_recover(h, e, 0)) < 0) { fprintf(stderr, "callback: can't writei: error %x %s\n", e, snd_strerror(e)); } fc = 0; } else { fprintf(stderr, "callback: short write: %d instead of %ld\n", fc, fa); } } for(i=0; i<fc; i++) { *d->ptr++ = d->buf[i*2]; if(d->ptr > &out[MAX_BUFS * (BUF_SIZE - 1)]) { d->ptr = (short *)&out[0]; } } c += fc; if(c >= BUF_SIZE) { gettimeofday(&tv, NULL); c -= BUF_SIZE; out_step++; if(out_step >= MAX_BUFS) out_step = 0; } frames_pb += fc; fa = snd_pcm_avail_update(h); faloops++; }; pb_faloops = faloops; } That's really it; the main loop keeps track of the in_step and out_step variables and does the cross-correlation as the data comes in. Now it seems that it's the capture playback that is getting xruns, but I when capture xruns occur my playback callback seems to stop, and sometimes the entire program just hangs as if it is waiting for ALSA to call one of the callbacks. Can anyone shed any light on this? I'm certain it's something very simple and braindead, but I can't find it. Regards, Andrew

1 0

Re: [alsa-devel] playback delay and problems with simultaneous playback/capture
by Max Klein 07 Jan '10

07 Jan '10

concerning the first point, I did some measurements... the file I used has a length of 1488 ms trigger start jiffies=7466937 trigger stop jiffies=7468172 difference = 1235 (1235 ms) pcm prepare jiffies 2=6761125 trigger start jiffies=6761126 trigger stop jiffies=6762361 difference = 1235 (1235 ms) trigger stopped, buffer empty, stop decoder jiffies=6762684 difference = 323 (323 ms) so I was wondering, why the difference between trigger start - stop is not 1488ms but 1235ms. I still guess that it may is a wrongly updated pcm pointer? Thanks for your help, Max -- Jetzt kostenlos herunterladen: Internet Explorer 8 und Mozilla Firefox 3.5 - sicherer, schneller und einfacher! http://portal.gmx.net/de/go/atbrowser

1 0

[alsa-devel] question on dapm_reg_event()
by Haojian Zhuang 06 Jan '10

06 Jan '10

Hi all, I just have a question on dapm code. In dapm_reg_event(), -(w->reg + 1) is input parameter of snd_soc_update_bits(). Why we need to use negative value as input parameter at here? Why do we not use w->reg at here? Thanks Haojian

3 3

[alsa-devel] playback delay and problems with simultaneous playback/capture
by mein_name＠ist-einmalig.de 06 Jan '10

06 Jan '10

I am currently testing my driver but I've got some problems with the "pcm machine"...as it is my first ALSA driver I am open for every hint. The code currently is not conform to linux kernel coding style, I will do all such cosmetically stuff after functionality is given. 1. Playing a file works fine, but when the ALSA middle layer triggers stop command, the DSP still has data to play, so sending a stop signal to the DSP at this moment would result in breaking the playback. The strange thing here is, that it seems there are 6 frames missing, but the buffer of the DSP is only about 3 frames long. I am not sure if the problem here is, that I am not correctly "calculating" the pcm_pointer: static snd_pcm_uframes_t snd_card_mychip_pcm_pointer(struct snd_pcm_substream *substream) { struct snd_pcm_runtime *runtime = substream->runtime; struct snd_mychip_pcm *dpcm = runtime->private_data; /* get the current hardware pointer */ // TODO: calc correct return value print_log(DEBUGC "pcm pointer: ret b=%lu\n", bytes_to_frames(runtime, dpcm->pcm_buf_pos)); return bytes_to_frames(runtime, dpcm->pcm_buf_pos); } 2. when playing and capturing data simultaneously, I get troubles in both. Playback or Capture alone is working, but if both come togheter, troubles occur. The data-transfer from ALSA to DSP and DSP to ALSA I am doing in the timer function, I am not sure if this could be the problem...but to send data to the DSP I have to check a flag if the DSP is able to receive data, if so, I can send data, otherwise I have to wait until DSP is ready to receive data. That is done with dsp_sendstream. When capturing, the DSP is sending an interrupt every captured period that is available, so I store that in a buffer from where it got read frequently via the timer function (done by readbuf)...everytime when going through this function I think that this way may work, as it does normally, but I am absolutely not sure if this is a "right" way. I know that there are so called "copy" and "silence" callbacks, but using the copy callback for playback I lost frames, so I did it like it is now... static void snd_card_mychip_pcm_timer_function(unsigned long data) { struct snd_mychip_pcm *dpcm = (struct snd_mychip_pcm *)data; unsigned long flags; int count, pos, status; // disable interrupts spin_lock_irqsave(&dpcm->lock, flags); // restart the timer to be called again after one jiffie = 1 ms dpcm->timer.expires = 1 + jiffies; add_timer(&dpcm->timer); if (dpcm->substream->stream == 0) { // playback stream // increase counters by bytes per jiffie if (dpcm->sendingnotpossible == 0) { dpcm->pcm_irq_pos += dpcm->pcm_jiffie; //0..MAX_PERIOD_SIZE step=jiffie dpcm->pcm_buf_pos += dpcm->pcm_jiffie; //0..MAX_BUFFER_SIZE step=jiffie } // if pcm_count has been reached, call snd_pcm_period_elapsed // to signal the end of one period (e.g. 288 for mpg or 768 for wav) if (dpcm->pcm_irq_pos >= dpcm->pcm_count) { // >= MAX_PERIOD_SIZE? count=dpcm->pcm_count; // number of bytes to be sent pos=dpcm->pcm_buf_pos-count; // start offset in DMA buffer // try to send data to dsp status = dsp_sendstream(dpcm->substream->pcm->device, dpcm->substream->runtime->dma_area+pos, count); if (status != 0) { // sending not possible dpcm->sendingnotpossible=1; } else { // sending successful dpcm->sendingnotpossible=0; dpcm->sentframes++; if (dpcm->sentframes == 3) // 3 frames in buffer so we can start playback { // start decoder playback status=dsp_decod_action(dpcm->substream->pcm->device, DECOD_START); print_log(DEBUGA "reply of dsp_decod_action = %i\n",status); } // wrap counter if end of buffer is reached dpcm->pcm_buf_pos %= dpcm->pcm_size; // wrap this counter too dpcm->pcm_irq_pos %= dpcm->pcm_count; // tell the PCM middle layer when the buffer position goes across the prescribed period size snd_pcm_period_elapsed(dpcm->substream); print_log(DEBUGC "timer_function: Period elapsed (p) - pcm_count=%i - pcm_size=%i - src=%p - jiffie=%i\n",dpcm->pcm_count,dpcm->pcm_size,dpcm->substream->runtime->dma_area,dpcm->pcm_jiffie); } // enable interrupts spin_unlock_irqrestore(&dpcm->lock, flags); } else { // wrap counter if end of buffer is reached dpcm->pcm_buf_pos %= dpcm->pcm_size; // enable interrupts spin_unlock_irqrestore(&dpcm->lock, flags); } } else if (dpcm->substream->stream == 1) { // capture stream count = dpcm->pcm_count; // number of bytes to be captured pos = dpcm->pcm_buf_pos; // start offset in DMA buffer // read from HIF buffer status = readbuf(dpcm->substream->pcm->device, dpcm->substream->runtime->dma_area+pos, count); if (status == 0) { // we got new data from HIF buffer => increase pointers.. dpcm->pcm_buf_pos += count; // wrap counter if end of buffer is reached dpcm->pcm_buf_pos %= dpcm->pcm_size; // wrap this counter too //dpcm->pcm_irq_pos %= dpcm->pcm_count; // tell the PCM middle layer when the buffer position goes across the prescribed period size snd_pcm_period_elapsed(dpcm->substream); print_log(DEBUG "timer_function: Period elapsed (c) - pcm_count=%i - pcm_size=%i - src=%p - jiffie=%i\n",dpcm->pcm_count,dpcm->pcm_size,dpcm->substream->runtime->dma_area,dpcm->pcm_jiffie); } // enable interrupts spin_unlock_irqrestore(&dpcm->lock, flags); } } 3. Sometimes I am getting underruns with aplay or xruns with arecord. Currently I am not quite sure why they occur, but I guess this has to do with some of above problems? -bash-3.2# aplay 20575_24k_100.wav Playing WAVE '20575_24k_100.wav ' : Signed 16 bit Little Endian, Rate 24000 Hz, Mono underrun!!! (at least 8.019 ms long) As a reference I used the dummy driver and the tutorial Writing an ALSA Driver. If there are some other drivers that may be similar and I can look at, I am thankful for every hint! So far thanks for helping me! Greetings, Max -- Jetzt kostenlos herunterladen: Internet Explorer 8 und Mozilla Firefox 3.5 - sicherer, schneller und einfacher! http://portal.gmx.net/de/go/chbrowser

1 0

[alsa-devel] Sound still not working after 1.0.22.1 update
by Daniel Grandja 06 Jan '10

06 Jan '10

I have managed to Download / Compile / Install the upgrade, but still no sound, and now i can't log in to Gnome (Xfce still works) http://www.alsa-project.org/db/?f=f31c932fe24d1ad6a8d67189eb2e984f03545be8 i have a VIA VT82xx based onboard card any ideas as to what has gone wrong ? from the log i noticed that the driver version was still 1.0.20 is this correct ? i wonder why that didn't update ? can i force it somehow ? cheers Daniel

2 1

Re: [alsa-devel] capturing data from the microphone
by Mark Brown 06 Jan '10

06 Jan '10

On Wed, Jan 06, 2010 at 11:44:04AM +0100, Marc Garnier wrote: > OK, well, I work on a custom device platform based on an Atmel > at91sam9261. I wrote an alsa driver composed of 2 files CCing in the list and Sedji, who wrote the driver. Please also try avoid top posting - Linux lists generally intersperse replies with the relevant context from the original message since it makes mails much more legible. > But when I want to record a pcm stream I have this error: > # arecord -v -c 1 -t wav -f S16_LE -r 8000 -d 10 input.wav > arecord: pcm_read:1629: read error: Input/output error [With an AT91 in slave mode...] > and actually no interrupt occur and I > wonder why... Can you see clocks on the audio interface? Have you checked that the pins on the processor are configured to route the signals to the correct IP block?

2 1

[alsa-devel] ASoC updates for 2.6.33
by Mark Brown 04 Jan '10

04 Jan '10

The following changes since commit c5974b835a909ff15c3b7e6cf6789b5eb919f419: Linus Torvalds (1): Merge branch 'limits_cleanup' of git://decibel.fi.muni.cz/~xslaby/linux are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound-2.6.git for-2.6.33 Takashi is on holiday for the first few weeks of the year so he said to send direct pull requests in the interim. The patch from Morimoto-san is finishing off a cross-tree merge while the others are driver-specific fixes. Guennadi Liakhovetski (1): ASoC: fix params_rate() macro use in several codecs Kuninori Morimoto (1): ASoC: fsi-ak4642: Remove ak4642_add_i2c_device Manuel Lauss (1): ASoC: fixup oops in generic AC97 codec glue Mark Brown (1): Merge commit 'v2.6.33-rc2' into for-2.6.33 sound/soc/codecs/ac97.c | 6 ++++++ sound/soc/codecs/wm8510.c | 14 +++++++------- sound/soc/codecs/wm8940.c | 14 +++++++------- sound/soc/codecs/wm8974.c | 14 +++++++------- sound/soc/sh/fsi-ak4642.c | 30 ------------------------------ 5 files changed, 27 insertions(+), 51 deletions(-)

1 0

[alsa-devel] [PATCH] ASoc: tpa6130a2: Remove unnecessary variable
by Ilkka Koskinen 04 Jan '10

04 Jan '10

Signed-off-by: Ilkka Koskinen <ilkka.koskinen(a)nokia.com> --- sound/soc/codecs/tpa6130a2.c | 4 ---- 1 files changed, 0 insertions(+), 4 deletions(-) diff --git a/sound/soc/codecs/tpa6130a2.c b/sound/soc/codecs/tpa6130a2.c index 0eb33d4..8e98ccf 100644 --- a/sound/soc/codecs/tpa6130a2.c +++ b/sound/soc/codecs/tpa6130a2.c @@ -267,12 +267,8 @@ static const struct snd_kcontrol_new tpa6130a2_controls[] = { */ static void tpa6130a2_channel_enable(u8 channel, int enable) { - struct tpa6130a2_data *data; u8 val; - BUG_ON(tpa6130a2_client == NULL); - data = i2c_get_clientdata(tpa6130a2_client); - if (enable) { /* Enable channel */ /* Enable amplifier */ -- 1.6.0.4

3 2

[alsa-devel] [PATCH] ASoC: fixup oops in generic AC97 codec glue
by Manuel Lauss 04 Jan '10

04 Jan '10

Initialize the glue by calling snd_soc_new_ac97_codec() as is done in other ASoC AC97 codecs. Fixes an oops caused by dereferencing uninitialized members in snd_soc_new_pcms(). Run-tested on Au1250. Signed-off-by: Manuel Lauss <manuel.lauss(a)gmail.com> --- Fixes the oops I reported here: http://mailman.alsa-project.org/pipermail/alsa-devel/2009-December/023995.h… sound/soc/codecs/ac97.c | 6 ++++++ 1 files changed, 6 insertions(+), 0 deletions(-) diff --git a/sound/soc/codecs/ac97.c b/sound/soc/codecs/ac97.c index 69bd0ac..a1bbe16 100644 --- a/sound/soc/codecs/ac97.c +++ b/sound/soc/codecs/ac97.c @@ -102,6 +102,12 @@ static int ac97_soc_probe(struct platform_device *pdev) INIT_LIST_HEAD(&codec->dapm_widgets); INIT_LIST_HEAD(&codec->dapm_paths); + ret = snd_soc_new_ac97_codec(codec, &soc_ac97_ops, 0); + if (ret < 0) { + printk(KERN_ERR "ASoC: failed to init gen ac97 glue\n"); + goto err; + } + /* register pcms */ ret = snd_soc_new_pcms(socdev, SNDRV_DEFAULT_IDX1, SNDRV_DEFAULT_STR1); if (ret < 0) -- 1.6.6.rc3

2 1

[alsa-devel] Underrun problem and some basic queries
by ANISH KUMAR 04 Jan '10

04 Jan '10

1 0

[alsa-devel] [PATCH 0/5] ASoC: tlv320dac33: Adding new FIFO mode
by Peter Ujfalusi 04 Jan '10

04 Jan '10

Hello, the following series adds new FIFO operating mode to the tlv320dac33 codec driver. To be able to add new FIFO mode the code has to be restructured in order to keep it readable after the new mode is added. Since both of the support FIFO mode in the driver needs the codec to be the master, an additional check is added to avoid misconfiguration. --- Peter Ujfalusi (5): ASoC: tlv320dac33: Change nsample switch to FIFO mode enum ASoC: tlv320dac33: Introduce prefill and playback state handlers ASoC: tlv320dac33: Clean up the hardware configuration code ASoC: tlv320dac33: Add new FIFO mode: mode 7 ASoC: tlv320dac33: Safety check for codec slave mode sound/soc/codecs/tlv320dac33.c | 190 ++++++++++++++++++++++++++++++++-------- 1 files changed, 153 insertions(+), 37 deletions(-)

2 8

[alsa-devel] Underrun problem and some basic queries
by ANISH KUMAR 04 Jan '10

04 Jan '10

1 0

[alsa-devel] Echoaudio, suspend/resume question on rawmidi device
by Giuliano Pochini 03 Jan '10

03 Jan '10

I have some patches that add PM support to all echoaudio drivers. It seems to work fine, but it has been tested on two cards only and the rawmidi device hasn't been tested at all. I can't test it because suspend-to-anything does not work on my pmac. I want to be sure at least it cannot deadlock. * On suspend: Rawmidi input is interrupt-driven. The driver tells the card to stop accepting data. Rawmidi output is timer-driven. The driver uses a timer to check if the card's output buffer has room for more data to send. Do del_timer_sync() and wait until all buffered data is sent, which may take 20ms (64 bytes at 31250bps). * On resume: Input: Re-enable midi in. Output: Restart the timer. Do you see any race condition or weak points in this scheme, especially in the midi-out part ? Is del_timer_sync() safe ? -- Giuliano.

1 0

[alsa-devel] Cross-compile problem with alsa-driver version 1.0.22
by Jie Jiang 03 Jan '10

03 Jan '10

Hi all, Recently I downloaded alsa-driver 1.0.22 and tried to build for i.MX27 platform. The "INSTALL" file enclosed in this release requires "--with-cross=arm-linux-" configuration option to cross-compile alsa driver for this ARM platform. Here is my build process #./configure --with-cross=arm-linux- --with-kernel=/home/working/bsp/Kernel/linux-2.6.19.2 --with-build=/home/working/bsp/ Kernel/linux-2.6.19.2 --with-moddir=/home/working/bsp/tmp --with-debug=full --enable-dynamic-minors --with-cards=all checking for gcc... arm-linux-gcc checking for C compiler default output file name... a.out checking whether the C compiler works... configure: error: cannot run C compiled programs. If you meant to cross compile, use `--host'. See `config.log' for more details. It seems that "--host=arm-linux" should be provided to configure script. However, when given the --host option, in the generated "Makefile.conf", I saw the following outputs, which are very confusing: NEW_KBUILD = mainsrcdir = . MAINSRCDIR = /work/63/alsa/alsa-driver-1.0.22 CROSS_COMPILE ?= arm-linux- ARCH ?= ifdef NEW_KBUILD CC = $(CROSS_COMPILE)arm-linux-gcc CPP = $(CROSS_COMPILE)arm-linux-gcc -E export CROSS_COMPILE ARCH else AS = $(CROSS_COMPILE)as LD = $(CROSS_COMPILE)ld CC = $(CROSS_COMPILE)arm-linux-gcc CPP = $(CROSS_COMPILE)arm-linux-gcc -E AR = $(CROSS_COMPILE)ar MODFLAGS = -DMODULE=1 CFLAGS_KERNEL = GENKSYMS = /sbin/genksyms -k 0.0.0 endif Obviously, the CC and CPP variables are not expected as "arm-linux-gcc". (There is one more $(CROSS_COMPILE)!) I overcome this problem by providing CC and CROSS_COMPILE variables with configure script: CC=gcc CROSS_COMPILE=arm-linux-gcc ./configure --with-cross=arm-linux- --with-kernel=/home/working/bsp/Kernel/linux-2.6.19.2 --with-build=/home/working/bsp/Kernel/linux-2.6.19.2 --with-moddir=/home/working/bsp/tmp --with-debug=full --enable-dynamic-minors --with-cards=all Then things become OK. What's wrong with the "INSTALL" file? Another problem. Even if "--with-cards=all" is given, codes in soc/codecs, soc/imx, and many other subdirs are not built. It seems that the configure script sets some variables according to the kernel version and target platform and outputs into "toplevel.config". Is it possible to manually edit "toplevel.config" file (after configure process) to get soc/codecs, soc/imx codes compiled? Regards, Jie

2 1

[alsa-devel] Trouble with sound over HDMI with Nvidia MCP7A HDMI
by Austin Robertson 03 Jan '10

03 Jan '10

I am having trouble getting sound over hdmi with my Nvidia MCP7A HDMI. The strange thing is that everything works fine in a Live disc, but once I do a fresh install of that Live disc I get no sound, even though my configuration is exactly the same (as far as I can tell). I've checked the little things like alsamixer volumes, aplay -l, etc etc. Everything looks good to me. I can reproduce on multiple TVs so its not the receiver. Video drivers are the same in both live version and installed. aplay -l detects my device. sound/pci/hda/patch_nvhdmi.c already has my correct vendor id in it. Perhaps the following info can help figure out what my installed environment is lacking. I've been at it for days now and I'm stumped! Any ideas? *Live Disc Info* XMBC Live 9.11 (basically a optimized version of Karmic configured to start XBMC, or Xbox Media Center, see http://www.xbmc.org for more info) NOTE: My problem is not specific to the XBMC program. Things like aplay and speaker-test don't work either. *Hardware* Acer Aspire Revo R1600 http://www.newegg.com/Product/Product.aspx?Item=N82E16883103228&Tpk=AR1600 *XBMC Live installed to hard disk via Ubuntu installer* (This setup gives me no sound over HDMI) (This is a fresh install. No additional changes were made) alsa-info.sh http://www.alsa-project.org/db/?f=ab7cef7c7233f8c42756d36e362df684b9147d38 xbmc@XBMCLive:~$ aplay -l **** List of PLAYBACK Hardware Devices **** card 0: NVidia [HDA NVidia], device 0: ALC662 rev1 Analog [ALC662 rev1 Analog] Subdevices: 0/1 Subdevice #0: subdevice #0 card 0: NVidia [HDA NVidia], device 3: NVIDIA HDMI [NVIDIA HDMI] Subdevices: 1/1 Subdevice #0: subdevice #0 xbmc@XBMCLive:~$ aplay -L default:CARD=NVidia HDA NVidia, ALC662 rev1 Analog Default Audio Device front:CARD=NVidia,DEV=0 HDA NVidia, ALC662 rev1 Analog Front speakers surround40:CARD=NVidia,DEV=0 HDA NVidia, ALC662 rev1 Analog 4.0 Surround output to Front and Rear speakers surround41:CARD=NVidia,DEV=0 HDA NVidia, ALC662 rev1 Analog 4.1 Surround output to Front, Rear and Subwoofer speakers surround50:CARD=NVidia,DEV=0 HDA NVidia, ALC662 rev1 Analog 5.0 Surround output to Front, Center and Rear speakers surround51:CARD=NVidia,DEV=0 HDA NVidia, ALC662 rev1 Analog 5.1 Surround output to Front, Center, Rear and Subwoofer speakers surround71:CARD=NVidia,DEV=0 HDA NVidia, ALC662 rev1 Analog 7.1 Surround output to Front, Center, Side, Rear and Woofer speakers hdmi:CARD=NVidia,DEV=0 HDA NVidia, NVIDIA HDMI HDMI Audio Output null Discard all samples (playback) or generate zero samples (capture) * ### speaker-test executes but NO SOUND over hdmi*. *I've also tried other devices like -D hdmi:0 -D hw:0,3 -D hdmi -D plug:hdmi, etc, etc* xbmc@XBMCLive:~$ speaker-test -D plughw:0,3 -c2 speaker-test 1.0.20 Playback device is plughw:0,3 Stream parameters are 48000Hz, S16_LE, 2 channels Using 16 octaves of pink noise Rate set to 48000Hz (requested 48000Hz) Buffer size range from 64 to 16384 Period size range from 32 to 8192 Using max buffer size 16384 Periods = 4 was set period_size = 4096 was set buffer_size = 16384 0 - Front Left 1 - Front Right Time per period = 5.637709 0 - Front Left xbmc@XBMCLive:~$ cat /proc/driver/nvidia/version NVRM version: NVIDIA UNIX x86 Kernel Module 190.53 Tue Dec 8 18:51:41 PST 2009 GCC version: gcc version 4.4.1 (Ubuntu 4.4.1-4ubuntu8) * XMBC Live Disc * ** (This setup gives me audio over hdmi perfectly) (This is running as a Live disc, ie not installed) ** alsa-info.sh http://www.alsa-project.org/db/?f=c95bebdc433f15147fb0be415be4e61e4d0b72ad [ ^<http://www.alsa-project.org/db/?f=c95bebdc433f15147fb0be415be4e61e4d0b72ad> ] xbmc@XBMCLive:~$ aplay -l **** List of PLAYBACK Hardware Devices **** card 0: NVidia [HDA NVidia], device 0: ALC662 rev1 Analog [ALC662 rev1 Analog] Subdevices: 0/1 Subdevice #0: subdevice #0 card 0: NVidia [HDA NVidia], device 3: NVIDIA HDMI [NVIDIA HDMI] Subdevices: 1/1 Subdevice #0: subdevice #0 xbmc@XBMCLive:~$ aplay -L default:CARD=NVidia HDA NVidia, ALC662 rev1 Analog Default Audio Device front:CARD=NVidia,DEV=0 HDA NVidia, ALC662 rev1 Analog Front speakers surround40:CARD=NVidia,DEV=0 HDA NVidia, ALC662 rev1 Analog 4.0 Surround output to Front and Rear speakers surround41:CARD=NVidia,DEV=0 HDA NVidia, ALC662 rev1 Analog 4.1 Surround output to Front, Rear and Subwoofer speakers surround50:CARD=NVidia,DEV=0 HDA NVidia, ALC662 rev1 Analog 5.0 Surround output to Front, Center and Rear speakers surround51:CARD=NVidia,DEV=0 HDA NVidia, ALC662 rev1 Analog 5.1 Surround output to Front, Center, Rear and Subwoofer speakers surround71:CARD=NVidia,DEV=0 HDA NVidia, ALC662 rev1 Analog 7.1 Surround output to Front, Center, Side, Rear and Woofer speakers hdmi:CARD=NVidia,DEV=0 HDA NVidia, NVIDIA HDMI HDMI Audio Output null Discard all samples (playback) or generate zero samples (capture) ###* speaker-test plays audio over hdmi perfectly. other programs play audio over hdmi.* xbmc@XBMCLive:~$ speaker-test -D plughw:0,3 -c2 speaker-test 1.0.20 Playback device is plughw:0,3 Stream parameters are 48000Hz, S16_LE, 2 channels Using 16 octaves of pink noise Rate set to 48000Hz (requested 48000Hz) Buffer size range from 64 to 16384 Period size range from 32 to 8192 Using max buffer size 16384 Periods = 4 was set period_size = 4096 was set buffer_size = 16384 0 - Front Left 1 - Front Right Time per period = 5.638693 xbmc@XBMCLive:~$ cat /proc/driver/nvidia/version NVRM version: NVIDIA UNIX x86 Kernel Module 190.53 Tue Dec 8 18:51:41 PST 2009 GCC version: gcc version 4.4.1 (Ubuntu 4.4.1-4ubuntu8) *Additional Information * I had an idea to run a diff on the two alsa-info.sh outputs of my installed and live version. (non-working and working, see above) I figured that might give me a clue on what I was missing. Most things should be identical with a few exceptions like timestamps, etc. MacBook-Austin:Desktop Austin$ diff -crB alsa-info_installed.txt alsa-info_live.txt > alsa-infodiff.diff alsa-info_installed.txt: http://pastebin.com/f63afa045 (non-working, same as above) alsa-info_live.txt: http://pastebin.com/f7b47d46d (working, same as above) alsa-infodiff.diff: http://pastebin.com/f79cf9c15 Only a few things caught my attention. At first I thought I had my playback volumes muted (line 525,532) according to the diff. But then I realized that was just for the mic, so that shouldn't matter. The only other thing that I saw was that my Amp-Out vals differed (line 123, 129). Perhaps, a more trained eye will have better luck. Bug has also been reported here: https://bugtrack.alsa-project.org/alsa-bug/view.php?id=4865

1 0

[alsa-devel] Cross-compile problem with alsa-driver version 1.0.22
by Jie Jiang 03 Jan '10

03 Jan '10

Hi all, Recently I downloaded alsa-driver 1.0.22 and tried to build for i.MX27 platform. The "INSTALL" file enclosed in this release requires "--with-cross=arm-linux-" configuration option to cross-compile alsa driver for this ARM platform. Here is my build process #./configure --with-cross=arm-linux- --with-kernel=/home/working/bsp/Kernel/linux-2.6.19.2 --with-build=/home/working/bsp/ Kernel/linux-2.6.19.2 --with-moddir=/home/working/bsp/tmp --with-debug=full --enable-dynamic-minors --with-cards=all checking for gcc... arm-linux-gcc checking for C compiler default output file name... a.out checking whether the C compiler works... configure: error: cannot run C compiled programs. If you meant to cross compile, use `--host'. See `config.log' for more details. It seems that "--host=arm-linux" should be provided to configure script. However, when given the --host option, in the generated "Makefile.conf", I saw the following outputs, which are very confusing: NEW_KBUILD = mainsrcdir = . MAINSRCDIR = /work/63/alsa/alsa-driver-1.0.22 CROSS_COMPILE ?= arm-linux- ARCH ?= ifdef NEW_KBUILD CC = $(CROSS_COMPILE)arm-linux-gcc CPP = $(CROSS_COMPILE)arm-linux-gcc -E export CROSS_COMPILE ARCH else AS = $(CROSS_COMPILE)as LD = $(CROSS_COMPILE)ld CC = $(CROSS_COMPILE)arm-linux-gcc CPP = $(CROSS_COMPILE)arm-linux-gcc -E AR = $(CROSS_COMPILE)ar MODFLAGS = -DMODULE=1 CFLAGS_KERNEL = GENKSYMS = /sbin/genksyms -k 0.0.0 endif Obviously, the CC and CPP variables are not expected as "arm-linux-gcc". (There is one more $(CROSS_COMPILE)!) I overcome this problem by providing CC and CROSS_COMPILE variables with configure script: CC=gcc CROSS_COMPILE=arm-linux-gcc ./configure --with-cross=arm-linux- --with-kernel=/home/working/bsp/Kernel/linux-2.6.19.2 --with-build=/home/working/bsp/Kernel/linux-2.6.19.2 --with-moddir=/home/working/bsp/tmp --with-debug=full --enable-dynamic-minors --with-cards=all Then things become OK. What's wrong with the "INSTALL" file? Another problem. Even if "--with-cards=all" is given, codes in soc/codecs, soc/imx, and many other subdirs are not built. Is this because my target kernel version is too low (2.6.19.2)? It seems that the configure script sets some variables according to the kernel version and target platform and outputs into "toplevel.config". Is it possible to manually edit "toplevel.config" file (after configure process) to get soc/codecs, soc/imx codes compiled? Regards, Jie

1 0

[alsa-devel] Git repository from which Takashi's snapshot is taken.
by Wael Nasreddine (aka eMxyzptlk) 02 Jan '10

02 Jan '10

Hello, I would like to patch the alsa with the patch given in this message[0], which at the time, applies to Takashi's snapshot[1], but it doesn't apply at the moment, in an effort to help me maintain it I would like to apply it to the git repository from which the snapshot has been made. Can someone give me the url to the repository from which the snapshot is taken? Thanks P.S: Happy New Year!! Footnotes: ---------- [0]: http://mailman.alsa-project.org/pipermail/alsa-devel/2009-November/023203.h… [1]: ftp://ftp.kernel.org/pub/linux/kernel/people/tiwai/snapshot/alsa-driver-sna… -- Wael Nasreddine Weem Chief-Development Officer - http://www.weem.com Blog : http://wael.nasreddine.com E-mail : wael.nasreddine(a)weem.com gTalk : wael.nasreddine(a)gmail.com Tel : +33.6.32.94.70.13 Skype : eMxyzptlk Twitter : @eMxyzptlk PGP: 1024D/C8DD18A2 06F6 1622 4BC8 4CEB D724 DE12 5565 3945 C8DD 18A2 .: An infinite number of monkeys typing into GNU emacs, would never make a good program. (L. Torvalds 1995) :. /<o>\ If entropy is increasing, where is it coming from?

2 1