Variable Delay through ALSA driver

Variable Delay through ALSA driver

[Brandon Yates]

I have an application using the ALSA API that writes to playback device
and simultaneously reads from capture device.  My processing loop is :

1)Read from microphone (blocking)
2)Process Data
3)Write to speaker

I am measuring the delay from the time I play a series of frames to the
speaker until I detect the echo of this coming back in through the
microphone.  This delay seems to be changing every time I initialize the
devices with ALSA. I have measured in the range of 60-160ms delay.  I
know things like period size effect delay, but using the exact same
software and hardware configuration I would expect this to be constant
across runs.  What are some parameters that can help me make the delay
deterministic?

Thanks,
Brandon        

Re: Variable Delay through ALSA driver

[Pierre-Louis Bossart]

On 9/17/13 3:07 PM, Brandon Yates wrote:
> I have an application using the ALSA API that writes to playback device
> and simultaneously reads from capture device.  My processing loop is :
>
> 1)Read from microphone (blocking)
> 2)Process Data
> 3)Write to speaker
>
> I am measuring the delay from the time I play a series of frames to the
> speaker until I detect the echo of this coming back in through the
> microphone.  This delay seems to be changing every time I initialize the
> devices with ALSA. I have measured in the range of 60-160ms delay.  I
> know things like period size effect delay, but using the exact same
> software and hardware configuration I would expect this to be constant
> across runs.  What are some parameters that can help me make the delay
> deterministic?

snd_pcm_link can help make sure your playback and capture devices start 
at the same time, if supported in hardware (HDAudio works well). 
Otherwise you need a cross-correlation to find out the delay and 
compensate for it in software.
-Pierre

Using codecs with AND without cpu_dai

[Mike Looijmans]

I've run into a second project where we'll probably want to use an audio codec 
in multiple ways. In this case, it means that we want to activate the codec 
without actually capturing data, but we alsa want to "peek" at the data while 
the codec is running.

More in detail, the I2S data from the codec is processed by, for example, an 
FPGA. The I2C bus is also connected to the CPU, so that the CPU can also 
aquire the data via Alsa.

So far, I've been using a piece of hackish code like this to turn on a codec 
without capturing from it (kernel 2.6.37 based code for now):

	struct snd_soc_codec *codec = codec_dai->codec;
	struct snd_soc_pcm_runtime fake_rtd;
	fake_rtd.codec_dai = tacho_dai;
	fake_rtd.codec = codec;
	codec->active++;
	codec_dai->active++;
	codec_dai->capture_active++;
	snd_soc_dapm_stream_event(&fake_rtd, capture_stream_name, 
SND_SOC_DAPM_STREAM_START);


This works well, it neatly uses DAPM to switch on the proper ADC paths. One 
can now also use the regular Alsa interfaces to start sampling from that 
codec. Of course, when you stop the capture stream, the codec will be shut 
down because there's no reference counting or anything similar on the codec usage.

It would be neater to have a "dummy" dai that connects to the codec, but when 
I do that, the regular cpu dai cannot be used and I cannot capture the stream 
and process it elsewhere at the same time.

A similar situation in pure audio components would be a second codec that 
outputs the I2S data to SPDIF, and a primary codec that samples analog audio 
to the I2S bus. Quite similar, you don't need to have a capture running, but 
both codecs must be powered on an actively run in order to have a 
analog-to-spdif function without involving the CPU. And the CPU should be able 
to "plug in" at will to grab the audio data, without disturbing the two.

Anyone any experience or ideas into a CORRECT way to handle these kind of setups?


Met vriendelijke groet / kind regards,

Mike Looijmans

TOPIC Embedded Systems
Eindhovenseweg 32-C, NL-5683 KH Best
Postbus 440, NL-5680 AK Best
Telefoon: (+31) – (0)499 - 33.69.79
Telefax: (+31) - (0)499 - 33.69.70
E-mail: mike.looijmans@topic.nl
Website: www.topic.nl

Dit e-mail bericht en de eventueel daarbij behorende bijlagen zijn uitsluitend bestemd voor de geadresseerde, zoals die blijkt uit het e-mail bericht en/of de bijlagen. Er kunnen gegevens met betrekking tot een derde instaan. Indien u als niet-geadresseerde dit bericht en de bijlagen ontvangt, terwijl u niet bevoegd of gemachtigd bent om dit bericht namens de geadresseerde te ontvangen, wordt u verzocht de afzender hierover direct te informeren en het e-mail bericht met de bijlagen te vernietigen. Ieder gebruik van de inhoud van het e-mail bericht, waaronder de daarbij behorende bijlagen, door een ander dan de geadresseerde is onrechtmatig jegens ons dan wel de eventueel in het e-mail bericht of de bijlagen voorkomende andere personen. TOPIC Embedded Systems is niet aansprakelijk voor enigerlei schade voortvloeiend uit het gebruik en/of acceptatie van dit e-mail bericht of de daarbij behorende bijlagen.

The contents of this message, as well as any enclosures, are addressed personally to, and thus solely intended for the addressee. They may contain information regarding a third party. A recipient who is neither the addressee, nor empowered to receive this message on behalf of the addressee, is kindly requested to immediately inform the sender of receipt, and to destroy the message and the enclosures. Any use of the contents of this message and/or the enclosures by any other person than the addressee or person who is empowered to receive this message, is illegal towards the sender and/or the aforementioned third party. TOPIC Embedded Systems is not  liable for any damage as a result of the use and/or acceptance of this message and as well as any enclosures.
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel