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

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

25 Jan '10

Dear ALSA Team, I have some queries.Please answer them.(previous post please ignore as they couldn't appear because of encoding problem) I am getting underrun problem whenever the playback is about to get finished. happening in snd_pcm_update_hw_ptr_post function: if (avail >= stop_threshold) { if (substream->runtime->status->state == SNDRV_PCM_STATE_DRAINING) snd_pcm_drain_done(substream); else xrun(substream); //here it is happening.......... return -EPIPE; } 1. As i understand if i dont call drain function this will happen.Ismy understanding correct?Because if am calling drain function then thisproblem is not happening.If the application doesn't call drain functionthen xrun is the only way to stop ALSA or does ALSA detect that thereare no more samples to play and automatically stop the play(if yes,canyou point out the source code)? 2. snd_pcm_playback_avail() returns the number of samples that stillneeds to be played?Below is the diagram which is my understanding. Ring buffer (DMA buffer created using preallocated buffer during system initalisation) ----------------------------------------------------------------- | | | | | | | ----------------------------------------------------------------- ^ ^ | | hw_ptr appl_ptr After first write call: ----------------------------------------------------------------- | | | | | | | ----------------------------------------------------------------- ^ ^ | | appl_ptr hw_ptr So my understanding is once wait_for_avail_min returns insnd_pcm_lib_write1 function.hw_ptr is increased by some amount(periodsize) but appl_ptr will increase only when wait_for_avail_minreturns.And difference of (hw_ptr+runtime->buffersize-appl_ptr) will give us unplayed samples in the case of playback? Is this whole ring buffer is filled after the snd_pcm_lib_write_transfer function is returned? 3.In some rare cases (playback case) i have seen thatwait_for_avail_min doesn't return and driver pointer function keeps ongetting called causing hw_ptr to increase.This causessnd_pcm_playback_avail() function to return a value less than avail_min(as hw_ptr is increasing and appl_ptr is stagnant as it is stuck insnd_pcm_lib_write1 function) which inturn causes wake-up fromsnd_pcm_update_hw_ptr_post() not to get called.When this type ofscenario happens?Is it a normal scenario if yes,then how will it willever come out from wait_for_avail_min? According to my understanding appl_ptr will increase only when we return from wait_for_avail_min? 4.how does alsa know that it is running short of data?As iunderstand that it does not free the memory and data is onlyoverwritten.So how does it distinguish between old and new data? 5.Burst of noise due to stale data problem reported by Jon Smirl and for which Mr Jaroslav has suggested this solution http://mailman.alsa-project.org/pipermail/alsa-devel/2009-May/017119.html.Is it implemented? Best Regards..

2 1

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

25 Jan '10

Hi Takashi et al, This post of mine is just a reminder about my earlier unanswered questions which i raised about underrun. http://mailman.alsa-project.org/pipermail/alsa-devel/2010-January/024286.ht… I guess you were on holiday and i think this is a bit long list of questions which no body cared to answer.This time please answer them as this would help all the new entrants to understand ALSA. Best Regards, anish

1 0

[alsa-devel] How much of the X-Fi (emu20k1) chip has Creative documented?
by Chris Rankin 25 Jan '10

25 Jan '10

Hi, I am thinking about upgrading my Audigy2 sound card, and was looking at the X-Fi. However, the feature matrix for X-Fi cards on the ALSA site only says "PCI". (I assume that also includes PCIe these days.) Given that there is a basic snd-ctxfi driver, it seems likely that this matrix should also include "ANALOGio", and so I was wondering if someone could tell me what the actual matrix entry for the X-Fi cards should be these days, please? Would the documentation that Creative has released allow any additional features to be implemented in the future? I am obviously hoping at least for feature parity with the Audigy2, i.e. multi-voiced hardware mixing. That "crystalizer" would seem to be one of the cards main selling points, too. However, if the driver is "feature complete" as far as Creative's documentation goes, then one of the Xonar cards would seem better value for money. Thanks for any assistance, Cheers, Chris

3 11

Re: [alsa-devel] Reg: Audio recording with twl4030 codec
by Peter Ujfalusi 25 Jan '10

25 Jan '10

Hello, Let's put alsa-devel back to the CC... On Monday 25 January 2010 09:32:45 ext shariff wrote: > Hi Peter, > > 1) As we only have one Main MIC when I am recording in stereo mode by > specifying "-c 2", one channel is silent and one channel is recorded > properly. As it should. Just as a sidenote, I'm usually using -f dat for the format, which gives 48KHz, stereo 16LE > > 2) But still the recorded channel is noisy, how can I reduce the noise of > the recorded channel? Hmm, what kind of noise? How are you configuring the dai with the snd_soc_dai_set_fmt? For stereo it should be (if OMAP is slave, TWL is master): SND_SOC_DAIFMT_I2S | SND_SOC_DAIFMT_NB_NF | SND_SOC_DAIFMT_CBM_CFM; For TDM mode (four channel): SND_SOC_DAIFMT_DSP_A | SND_SOC_DAIFMT_IB_NF | SND_SOC_DAIFMT_CBM_CFM; See omap3beagle.c how it is done. > > I have one more question. ( Regarding Audio path) > > ---> If I want to avoid that one channel silent, do I need to connect "SUB > MIC or AUXR"?( as these are connected right ADC). If you want audio data there, than yes you need another mic for the right channel. > ----> If I need to record 4 channel audio without any silent channel do I > need to connect digital microphones also? You can duplicate the channel 1 and 3 to channel 2 and 4, meaning that you route the ADCL and ADCR to these channels (TX1 and TX2 path are both analog). You can also hook up a stereo digital mic to the digimic1 interface, but remember, that the digimic needs 48KHz sampling rate. -- Péter > > Regards, > Shariff > > On Fri, Jan 22, 2010 at 6:29 PM, shariff > <shariffsinbox(a)gmail.com<mailto:shariffsinbox@gmail.com>> wrote: Hi Peter, > > Thank you very much for your suggestions. > > Regards, > Shariff > > > On Fri, Jan 22, 2010 at 6:11 PM, Peter Ujfalusi > <peter.ujfalusi(a)nokia.com<mailto:peter.ujfalusi@nokia.com>> wrote: Hello, > > On Friday 22 January 2010 11:57:23 ext shariff wrote: > > Hi all, > > > > I am working with OMAP3 based custom board that has twl4030 codec > > & using linux-2.6.29 kernel from opensource. > > This is kind of old... > > > I have some queries regarding Audio recording. > > > > Audio codec is connected to twl4030 as bellow > > > > TWL4030 > > > > |--------------------| > > | > > | |------ MAINMIC > > > > McBSP2 ------ |i2s/tdm | > > > > | ___________| > > > > --> One Analog MIC is connected to Main Mic and I am using Audio > > path not the Voice path. > > > > After selecting Main Mic through amixer control. > > > > and recording audio using "arecord -c 1 -r 8000 -f S16_LE -t > > wav -d 20 record-file.wav" > > The hardware should have been opened in stereo mode, since it is not > supporting the mono, you can verify it by appending -v to arecord and see > how the HW has been opened at the end. > > > --> Here record is successful but with lot of noise. > > > > 1) Can we record Mono(1 channel) through I2S from TWL4030 > > codec? > > The TWL codec "Audio" path is either stereo or 4 channel. > You need to record stereo/4 channel, and than extract/use the data from the > valid channel. > In case of Main mic it is the left channel, or Channel 1 or/and 2 > (depending on the routings) in four channel mode. > > > 2) To record stereo(2 channels), do we need two Mic's ? (i.e do > > I need Sub Mic also). > > No you don't need. The right channel will not contain valid data (most > likely it is going to be silent). > > You need to enable the Mic bias 1 for the main mic in your machine driver, > if you have not done that yet: > > static const struct snd_soc_dapm_widget your_widgets[] = { > ... > SND_SOC_DAPM_MIC("Your Mic", NULL), > ... > }; > > static const struct snd_soc_dapm_route your_audio_map[] = { > ... > {"MAINMIC", NULL, "Mic Bias 1"}, > {"Mic Bias 1", NULL, "Your Mic"}, > ... > }; > > I'm not sure about the state of the twl soc codec driver in 2.6.29, but my > guess is that it should work. > > Are there any capture routing option for TX1 path, which selects between > Analog and Digimic0? If there is than that has to be set to analog as > well. > > > Regards, > > Shariff > > -- > Péter >

2 1

[alsa-devel] ASoC updates for 2.6.34
by Mark Brown 25 Jan '10

25 Jan '10

The following changes since your topic/asoc branch are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound-2.6.git for-2.6.34 Since they include (via the 2.6.33 merge) a merge of Linus' tree I've only included the changes that aren't already in your tree or mainline in the summary below, though it looks like the diffstat picked up some extra changes due to the way I tried to do that. Barry Song (4): ASoC: ad1836: reset and restore clock control mode in suspend/resume entry ASoC: ad1938: fix typo, rename mask to rx_mask for ad1938_set_tdm_slot ASoC: ad1938: let soc-core dapm handle PLL power ASoC: soc-cache: cleanup training whitespace and coding style Ilkka Koskinen (2): ASoc: tpa6130a2: Remove unnecessary variable ASoC: tpa6130a2: Support for tpa6140's regulators Kuninori Morimoto (3): ASoC: fsi: Add over_period flag to prevent the misunderstanding ASoC: fsi: Add fsi_get_dai to get snd_soc_dai ASoC: fsi: Add over/under run error settlement Mark Brown (9): ASoC: Remove unneeded suspend checks from CODEC drivers ASoC: Use snprintf() when generating stream names ASoC: Fix variable shadowing warning in TLV320AIC3x ASoC: Only restore non-default registers for WM8731 ASoC: Only restore non-default registers for WM8776 ASoC: Only restore non-default registers for WM8961 ASoC: Implement suspend and resume for WM8993 ASoC: Fix WM8350 DSP mode B configuration Merge branch 'for-2.6.33' into for-2.6.34 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 include/sound/soc.h | 3 + include/sound/tpa6130a2-plat.h | 6 + include/sound/wm8904.h | 57 + include/sound/wm8955.h | 26 + sound/soc/codecs/Kconfig | 12 + sound/soc/codecs/Makefile | 10 +- sound/soc/codecs/ad1836.c | 32 + sound/soc/codecs/ad1938.c | 64 +- sound/soc/codecs/cs4270.c | 43 +- sound/soc/codecs/da7210.c | 589 +++++++++ sound/soc/codecs/da7210.h | 24 + sound/soc/codecs/tlv320aic3x.c | 75 +- sound/soc/codecs/tlv320dac33.c | 282 ++++- sound/soc/codecs/tpa6130a2.c | 109 ++- sound/soc/codecs/wm8350.c | 2 +- sound/soc/codecs/wm8727.c | 66 +- sound/soc/codecs/wm8731.c | 3 + sound/soc/codecs/wm8753.c | 8 - sound/soc/codecs/wm8776.c | 2 + sound/soc/codecs/wm8904.c | 2556 +++++++++++++++++++++++++++++++++++++ sound/soc/codecs/wm8904.h | 1681 ++++++++++++++++++++++++ sound/soc/codecs/wm8955.c | 1151 +++++++++++++++++ sound/soc/codecs/wm8955.h | 489 +++++++ sound/soc/codecs/wm8961.c | 3 + sound/soc/codecs/wm8990.c | 8 - sound/soc/codecs/wm8993.c | 67 + sound/soc/davinci/davinci-mcasp.c | 18 +- sound/soc/davinci/davinci-mcasp.h | 1 + sound/soc/davinci/davinci-pcm.c | 2 +- sound/soc/s3c24xx/s3c64xx-i2s.c | 120 +-- sound/soc/sh/Kconfig | 8 + sound/soc/sh/Makefile | 2 + sound/soc/sh/fsi-da7210.c | 83 ++ sound/soc/sh/fsi.c | 164 ++- sound/soc/soc-cache.c | 2 +- sound/soc/soc-core.c | 11 +- sound/soc/soc-dapm.c | 37 +- 37 files changed, 7457 insertions(+), 359 deletions(-) create mode 100644 include/sound/wm8904.h create mode 100644 include/sound/wm8955.h create mode 100644 sound/soc/codecs/da7210.c create mode 100644 sound/soc/codecs/da7210.h create mode 100644 sound/soc/codecs/wm8904.c create mode 100644 sound/soc/codecs/wm8904.h create mode 100644 sound/soc/codecs/wm8955.c create mode 100644 sound/soc/codecs/wm8955.h create mode 100644 sound/soc/sh/fsi-da7210.c

4 19

[alsa-devel] ALSA: hda - add possibility to choose speakers configuration for 4930g
by Łukasz Wojniłowicz 25 Jan '10

25 Jan '10

I've got such possibility on MS Windows XP with Realtek drivers (prove is at http://img694.imageshack.us/i/choosechannelmod.png/ ) so I should have possibility to do it also on Linux e.g. here http://img704.imageshack.us/i/screenshotsoundpreferen.png/ Patch given in attachment should do the thing. patch_realtek.c was downloaded from http://git.alsa-project.org/?p=alsa-kernel.git on Thu, 21 Jan 2010 13:58:25 +0000

2 1

Re: [alsa-devel] snd_pcm_hw_params_free() immediately after snd_pcm_hw_params() ???
by Clemens Ladisch 24 Jan '10

24 Jan '10

Raymond Yau wrote: > Is there any flags in substream which can indicate snd_xxx_hw_params() was > called at first time since snd_xxx_hw_params() were called many times > during OSS emulation (probing the supported rates , channels , .... ) ? There is no such flag. It is the responsibility of the driver to track the resources it has allocated. If a resource does not depend on the hardware parameters, it might be a better idea to allocate/free it in the open/close callbacks. Best regards, Clemens

3 2

[alsa-devel] [PATCH] add simplified versions of widget macros
by Guennadi Liakhovetski 23 Jan '10

23 Jan '10

Many macros from include/sound/soc-dapm.h take an array and a number of elements in it as arguments, whereas most users use static arrays and use "x, ARRAY_SIZE(x)" as arguments. This patch adds simplified versions of those macros, calling ARRAY_SIZE() internally. Signed-off-by: Guennadi Liakhovetski <g.liakhovetski(a)gmx.de> --- diff --git a/include/sound/soc-dapm.h b/include/sound/soc-dapm.h index c5c95e1..c0922a0 100644 --- a/include/sound/soc-dapm.h +++ b/include/sound/soc-dapm.h @@ -95,6 +95,21 @@ .shift = wshift, .invert = winvert, .kcontrols = wcontrols, \ .num_kcontrols = 1} +/* Simplified versions of above macros, assuming wncontrols = ARRAY_SIZE(wcontrols) */ +#define SOC_PGA_ARRAY(wname, wreg, wshift, winvert,\ + wcontrols) \ +{ .id = snd_soc_dapm_pga, .name = wname, .reg = wreg, .shift = wshift, \ + .invert = winvert, .kcontrols = wcontrols, .num_kcontrols = ARRAY_SIZE(wcontrols)} +#define SOC_MIXER_ARRAY(wname, wreg, wshift, winvert, \ + wcontrols)\ +{ .id = snd_soc_dapm_mixer, .name = wname, .reg = wreg, .shift = wshift, \ + .invert = winvert, .kcontrols = wcontrols, .num_kcontrols = ARRAY_SIZE(wcontrols)} +#define SOC_MIXER_NAMED_CTL_ARRAY(wname, wreg, wshift, winvert, \ + wcontrols)\ +{ .id = snd_soc_dapm_mixer_named_ctl, .name = wname, .reg = wreg, \ + .shift = wshift, .invert = winvert, .kcontrols = wcontrols, \ + .num_kcontrols = ARRAY_SIZE(wcontrols)} + /* path domain with event - event handler must return 0 for success */ #define SND_SOC_DAPM_PGA_E(wname, wreg, wshift, winvert, wcontrols, \ wncontrols, wevent, wflags) \ @@ -126,6 +141,23 @@ .invert = winvert, .kcontrols = wcontrols, .num_kcontrols = 1, \ .event = wevent, .event_flags = wflags} +/* Simplified versions of above macros, assuming wncontrols = ARRAY_SIZE(wcontrols) */ +#define SOC_PGA_E_ARRAY(wname, wreg, wshift, winvert, wcontrols, \ + wevent, wflags) \ +{ .id = snd_soc_dapm_pga, .name = wname, .reg = wreg, .shift = wshift, \ + .invert = winvert, .kcontrols = wcontrols, .num_kcontrols = ARRAY_SIZE(wcontrols), \ + .event = wevent, .event_flags = wflags} +#define SOC_MIXER_E_ARRAY(wname, wreg, wshift, winvert, wcontrols, \ + wevent, wflags) \ +{ .id = snd_soc_dapm_mixer, .name = wname, .reg = wreg, .shift = wshift, \ + .invert = winvert, .kcontrols = wcontrols, .num_kcontrols = ARRAY_SIZE(wcontrols), \ + .event = wevent, .event_flags = wflags} +#define SOC_MIXER_NAMED_CTL_E_ARRAY(wname, wreg, wshift, winvert, \ + wcontrols, wevent, wflags) \ +{ .id = snd_soc_dapm_mixer, .name = wname, .reg = wreg, .shift = wshift, \ + .invert = winvert, .kcontrols = wcontrols, \ + .num_kcontrols = ARRAY_SIZE(wcontrols), .event = wevent, .event_flags = wflags} + /* events that are pre and post DAPM */ #define SND_SOC_DAPM_PRE(wname, wevent) \ { .id = snd_soc_dapm_pre, .name = wname, .kcontrols = NULL, \

3 2

[alsa-devel] [PATCH] ASoC: fix a memory-leak in wm8903
by Guennadi Liakhovetski 23 Jan '10

23 Jan '10

Remember to free the temporary register-cache. Signed-off-by: Guennadi Liakhovetski <g.liakhovetski(a)gmx.de> --- should go in -rc, maybe also for stable diff --git a/sound/soc/codecs/wm8903.c b/sound/soc/codecs/wm8903.c index ce5515e..3595bd5 100644 --- a/sound/soc/codecs/wm8903.c +++ b/sound/soc/codecs/wm8903.c @@ -1504,7 +1504,7 @@ static int wm8903_resume(struct platform_device *pdev) struct i2c_client *i2c = codec->control_data; int i; u16 *reg_cache = codec->reg_cache; - u16 *tmp_cache = kmemdup(codec->reg_cache, sizeof(wm8903_reg_defaults), + u16 *tmp_cache = kmemdup(reg_cache, sizeof(wm8903_reg_defaults), GFP_KERNEL); /* Bring the codec back up to standby first to minimise pop/clicks */ @@ -1516,6 +1516,7 @@ static int wm8903_resume(struct platform_device *pdev) for (i = 2; i < ARRAY_SIZE(wm8903_reg_defaults); i++) if (tmp_cache[i] != reg_cache[i]) snd_soc_write(codec, i, tmp_cache[i]); + kfree(tmp_cache); } else { dev_err(&i2c->dev, "Failed to allocate temporary cache\n"); }

3 2

[alsa-devel] ca0106 broken (fwd)
by Russell Whitaker 23 Jan '10

23 Jan '10

Hi Sent msg below and no responce. As a work-around replaced ng code with know good code into 2.6.29.6 and it worked. Tried same trick with 2.6.31.12 and it won't compile. If you send me something to try will do it and report back. Russ ---------- Forwarded message ---------- Date: Wed, 21 Oct 2009 14:54:45 -0700 (PDT) From: Russell Whitaker <russ(a)ashlandhome.net> To: James(a)superbug.demon.co.uk Subject: ca0106 broken Hi ca0106 is known to work in these releases: linux-2.6.27.20 linux-2.6.27.23 linux-2.6.28.10 It is broken in: linux-2.6.29.6 linux-2.6.30.9 For the broken releases dmesg reports: unknown hardware "CA0106" "" "" "" "" Anything I can do to help? Russ

2 3