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

[alsa-devel] snd_pcm_prepare FAILS
by Irfan Shaikh 01 Mar '11

01 Mar '11

Hello, I have been using following section of code, my snd_pcm_prepare() always fails and i am not able to play audio using snd_pcm_writei(). /******************************Code*********************************/ err=snd_pcm_prepare(handle); if (err < 0) RSE_TRACE_ERROR(MP_ALSA_TRACE,("Can't recovery from underrun, prepare failed: %s\n", snd_strerror(err))); /**********************************************************************/ $$$$$$$$$$$$ Output : Can't recovery from underrun, prepare failed: Device or resource busy $$$$$$$$$$$$$ Can some one please share there comments on the above. What is going run above. Regards, SASKEN BUSINESS DISCLAIMER: This message may contain confidential, proprietary or legally privileged information. In case you are not the original intended Recipient of the message, you must not, directly or indirectly, use, disclose, distribute, print, or copy any part of this message and you are requested to delete it and inform the sender. Any views expressed in this message are those of the individual sender unless otherwise stated. Nothing contained in this message shall be construed as an offer or acceptance of any offer by Sasken Communication Technologies Limited ("Sasken") unless sent with that express intent and with due authority of Sasken. Sasken has taken enough precautions to prevent the spread of viruses. However the company accepts no liability for any damage caused by any virus transmitted by this email. Read Disclaimer at http://www.sasken.com/extras/mail_disclaimer.html

2 1

[alsa-devel] Underrun
by Irfan Shaikh 01 Mar '11

01 Mar '11

Hello All, A) I am getting many under-run in my audio capture and playback application. 1) My CAPTURE buffer is of 1024 * 8 (Period size * no of periods), PLAYBACK buffer is of (512 * 16) 2) I try to read 8 K frames each time and write returned frames to playback device. 3) Stereo audio, sample size 2 bytes, frame size 4 bytes, 48000 Hz I have done following to reduce under run : 1) Increased the number of periods on playback device (to increase playback latency). 2) optimized my code Please sugest me some more way so that i can avoid underrun of my playback device B) Can i use snd_pcm_prepare() twice in two consecutive lines For eg : { snd_pcm_prepare(pcm); snd_pcm_prepare(pcm); } I just want to know if this is OK for playback device state. Regards SASKEN BUSINESS DISCLAIMER: This message may contain confidential, proprietary or legally privileged information. In case you are not the original intended Recipient of the message, you must not, directly or indirectly, use, disclose, distribute, print, or copy any part of this message and you are requested to delete it and inform the sender. Any views expressed in this message are those of the individual sender unless otherwise stated. Nothing contained in this message shall be construed as an offer or acceptance of any offer by Sasken Communication Technologies Limited ("Sasken") unless sent with that express intent and with due authority of Sasken. Sasken has taken enough precautions to prevent the spread of viruses. However the company accepts no liability for any damage caused by any virus transmitted by this email. Read Disclaimer at http://www.sasken.com/extras/mail_disclaimer.html

2 1

[alsa-devel] [PATCH 0/5] Even more hdspmixer fixes
by Adrian Knoth 01 Mar '11

01 Mar '11

Hi! Next round of hdspmixer updates. Mostly cosmetics, but also fixing a segfault with H9652 cards. Thanks to Craig Bourne for immediate testing, also tested and confirmed to be working on RayDAT, Multiface and AES32. Adrian Knoth (5): hdspmixer: Fix compiler warnings. hdspmixer: Don't use hardcoded number of cards. hdspmixer: Make static destination maps extern hdspmixer: Lower nesting depth in label assignment hdspmixer: Fix labels on H9652 hdspmixer/pixmaps/Slider1.xpm | 2 +- hdspmixer/pixmaps/Slider2.xpm | 2 +- hdspmixer/pixmaps/Zlmloop2.xpm | 2 +- hdspmixer/pixmaps/Zlmloopm2.xpm | 2 +- hdspmixer/pixmaps/b_blank.xpm | 2 +- hdspmixer/pixmaps/b_card1.xpm | 2 +- hdspmixer/pixmaps/b_card2.xpm | 2 +- hdspmixer/pixmaps/b_card3.xpm | 2 +- hdspmixer/pixmaps/b_mute.xpm | 2 +- hdspmixer/pixmaps/b_pre1.xpm | 2 +- hdspmixer/pixmaps/b_pre2.xpm | 2 +- hdspmixer/pixmaps/b_pre3.xpm | 2 +- hdspmixer/pixmaps/b_pre4.xpm | 2 +- hdspmixer/pixmaps/b_pre5.xpm | 2 +- hdspmixer/pixmaps/b_pre6.xpm | 2 +- hdspmixer/pixmaps/b_pre7.xpm | 2 +- hdspmixer/pixmaps/b_pre8.xpm | 2 +- hdspmixer/pixmaps/b_save.xpm | 2 +- hdspmixer/pixmaps/b_solo.xpm | 2 +- hdspmixer/pixmaps/b_zlm.xpm | 2 +- hdspmixer/pixmaps/buttons.xpm | 2 +- hdspmixer/pixmaps/empty.xpm | 2 +- hdspmixer/pixmaps/empty_2.xpm | 2 +- hdspmixer/pixmaps/empty_linux.xpm | 2 +- hdspmixer/pixmaps/iomixer.xpm | 2 +- hdspmixer/pixmaps/iomixer_r.xpm | 2 +- hdspmixer/pixmaps/level.xpm | 2 +- hdspmixer/pixmaps/matrix_black.xpm | 2 +- hdspmixer/pixmaps/matrix_grey.xpm | 2 +- hdspmixer/pixmaps/matrix_grey_l.xpm | 2 +- hdspmixer/pixmaps/matrix_grey_o.xpm | 2 +- hdspmixer/pixmaps/matrix_grey_ol.xpm | 2 +- hdspmixer/pixmaps/matrix_mute.xpm | 2 +- hdspmixer/pixmaps/matrix_white.xpm | 2 +- hdspmixer/pixmaps/matrix_yellow.xpm | 2 +- hdspmixer/pixmaps/monitor.xpm | 2 +- hdspmixer/pixmaps/mute.xpm | 2 +- hdspmixer/pixmaps/output.xpm | 2 +- hdspmixer/pixmaps/output_r.xpm | 2 +- hdspmixer/pixmaps/over.xpm | 2 +- hdspmixer/pixmaps/peak.xpm | 2 +- hdspmixer/pixmaps/solo.xpm | 2 +- hdspmixer/src/HDSPMixerAbout.cxx | 2 +- hdspmixer/src/HDSPMixerAbout.h | 2 +- hdspmixer/src/HDSPMixerAboutText.h | 2 +- hdspmixer/src/HDSPMixerGain.cxx | 2 +- hdspmixer/src/HDSPMixerGain.h | 2 +- hdspmixer/src/HDSPMixerIOMixer.h | 4 +- hdspmixer/src/HDSPMixerOutput.cxx | 189 ++++++++++-------- hdspmixer/src/HDSPMixerOutput.h | 4 +- hdspmixer/src/HDSPMixerSelector.cxx | 38 ++-- hdspmixer/src/HDSPMixerSelector.h | 2 +- hdspmixer/src/HDSPMixerSetup.cxx | 2 +- hdspmixer/src/HDSPMixerSetup.h | 2 +- hdspmixer/src/Makefile.am | 1 + hdspmixer/src/channelmap.cxx | 368 ++++++++++++++++++++++++++++++++++ hdspmixer/src/channelmap.h | 348 ++++++--------------------------- hdspmixer/src/pixmaps.h | 76 ++++---- 58 files changed, 642 insertions(+), 486 deletions(-) create mode 100644 hdspmixer/src/channelmap.cxx -- 1.7.4.1

2 7

[alsa-devel] [PATCH v2] ASoC: WM8994: Ensure late enable events are processed for the ADCs
by Dimitris Papastamos 01 Mar '11

01 Mar '11

Ensure that the ADCs are provided with a clock as the previous patch "ASoC: WM8994: Improve playback robustness" did not handle this case properly. Signed-off-by: Dimitris Papastamos <dp(a)opensource.wolfsonmicro.com> --- sound/soc/codecs/wm8994.c | 26 +++++++++++++++++++++++--- 1 files changed, 23 insertions(+), 3 deletions(-) diff --git a/sound/soc/codecs/wm8994.c b/sound/soc/codecs/wm8994.c index 4dfbaee..b17ac19 100644 --- a/sound/soc/codecs/wm8994.c +++ b/sound/soc/codecs/wm8994.c @@ -1095,6 +1095,13 @@ static int aif2clk_ev(struct snd_soc_dapm_widget *w, return 0; } +static int adc_mux_ev(struct snd_soc_dapm_widget *w, + struct snd_kcontrol *kcontrol, int event) +{ + late_enable_ev(w, kcontrol, event); + return 0; +} + static int dac_ev(struct snd_soc_dapm_widget *w, struct snd_kcontrol *kcontrol, int event) { @@ -1415,6 +1422,18 @@ SND_SOC_DAPM_DAC("DAC1L", NULL, WM8994_POWER_MANAGEMENT_5, 1, 0), SND_SOC_DAPM_DAC("DAC1R", NULL, WM8994_POWER_MANAGEMENT_5, 0, 0), }; +static const struct snd_soc_dapm_widget wm8994_adc_revd_widgets[] = { +SND_SOC_DAPM_MUX_E("ADCL Mux", WM8994_POWER_MANAGEMENT_4, 1, 0, &adcl_mux, + adc_mux_ev, SND_SOC_DAPM_PRE_PMU), +SND_SOC_DAPM_MUX_E("ADCR Mux", WM8994_POWER_MANAGEMENT_4, 0, 0, &adcr_mux, + adc_mux_ev, SND_SOC_DAPM_PRE_PMU), +}; + +static const struct snd_soc_dapm_widget wm8994_adc_widgets[] = { +SND_SOC_DAPM_MUX("ADCL Mux", WM8994_POWER_MANAGEMENT_4, 1, 0, &adcl_mux), +SND_SOC_DAPM_MUX("ADCR Mux", WM8994_POWER_MANAGEMENT_4, 0, 0, &adcr_mux), +}; + static const struct snd_soc_dapm_widget wm8994_dapm_widgets[] = { SND_SOC_DAPM_INPUT("DMIC1DAT"), SND_SOC_DAPM_INPUT("DMIC2DAT"), @@ -1509,9 +1528,6 @@ SND_SOC_DAPM_ADC("DMIC1R", NULL, WM8994_POWER_MANAGEMENT_4, 2, 0), SND_SOC_DAPM_ADC("ADCL", NULL, SND_SOC_NOPM, 1, 0), SND_SOC_DAPM_ADC("ADCR", NULL, SND_SOC_NOPM, 0, 0), -SND_SOC_DAPM_MUX("ADCL Mux", WM8994_POWER_MANAGEMENT_4, 1, 0, &adcl_mux), -SND_SOC_DAPM_MUX("ADCR Mux", WM8994_POWER_MANAGEMENT_4, 0, 0, &adcr_mux), - SND_SOC_DAPM_MUX("Left Headphone Mux", SND_SOC_NOPM, 0, 0, &hpl_mux), SND_SOC_DAPM_MUX("Right Headphone Mux", SND_SOC_NOPM, 0, 0, &hpr_mux), @@ -3282,11 +3298,15 @@ static int wm8994_codec_probe(struct snd_soc_codec *codec) if (wm8994->revision < 4) { snd_soc_dapm_new_controls(dapm, wm8994_lateclk_revd_widgets, ARRAY_SIZE(wm8994_lateclk_revd_widgets)); + snd_soc_dapm_new_controls(dapm, wm8994_adc_revd_widgets, + ARRAY_SIZE(wm8994_adc_revd_widgets)); snd_soc_dapm_new_controls(dapm, wm8994_dac_revd_widgets, ARRAY_SIZE(wm8994_dac_revd_widgets)); } else { snd_soc_dapm_new_controls(dapm, wm8994_lateclk_widgets, ARRAY_SIZE(wm8994_lateclk_widgets)); + snd_soc_dapm_new_controls(dapm, wm8994_adc_widgets, + ARRAY_SIZE(wm8994_adc_widgets)); snd_soc_dapm_new_controls(dapm, wm8994_dac_widgets, ARRAY_SIZE(wm8994_dac_widgets)); } -- 1.7.4.1

1 0

[alsa-devel] [TLV320AIC23] [AM3517EVM][AUDIO] codec name mis-match in soc_bind_dai_link
by Koyamangalath, Abhilash 01 Mar '11

01 Mar '11

While trying to register the sound card on the AM3517EVM (which uses a tlv320aic23 codec), with the 2.6.37 kernel I get the following error message: CODEC tlv320aic23-codec not registered This is despite having gotten previously: Registered codec 'tlv320aic23-codec.2-001a' I realized that there was a names' mismatch in soc_bind_dai_link(): In fn soc_bind_dai_link:1249:codec->name is tlv320aic23-codec.2-001a, dai_link->codec_name is tlv320aic23-codec The 2-001a is the <i2c_bus>-<i2c_address> pair as defined in arch/arm/mach-omap2/board-am3517evm.c: static struct i2c_board_info __initdata am3517evm_i2c2_boardinfo[] = { { I2C_BOARD_INFO("tlv320aic23", 0x1A), }, This is the device name of the i2c client set automatically by i2c_new_device() when __process_new_driver() on the device is called, in response to a i2c_register_driver() request. Now, all devices with names in <i2c_bus>-<i2c_address> are assumed to be i2c clients by snd_soc_register_codec() and so <driver_name>.<dev_name> is the name supplied to the codec. Now, if I change the dai-link->codec_name to force-match by appending 2-001a to the codec_name in (sound/soc/omap/am3517evm.c): static struct snd_soc_dai_link am3517evm_dai = { : .codec_name = "tlv320aic23-codec.2-001a ", : }; the registration proceeds smoothly and I can see device nodes getting created. Since now there is no way to provide a customized i2c device name to a client device (or so I believe), what could be the best solution to this problem ? -Abhilash PS: OMAP3 evm does not have this problem as the audio codec twl4030 is on platform bus, I believe. -- To unsubscribe from this list: send the line "unsubscribe alsa-devel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html

2 1