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

[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