[alsa-devel] some problem about alsa lib usage on arm926
Dear All:
right now, I'm using alsa lib interface to work with voip application. Our hardware platform is an ARM926 266MHz box with Linux kernel 2.6.19.2. We got some problems. would you like to do us favors?
1. what is the different between "plughw:0,0", "defalut", "hw:0.0"? after reading the document in http://www.alsa-project.org/alsa-doc/alsa-lib/pcm.html about "PCM naming conventions", we still not very sure the relationship between those device conventions. is there any more detail documents talk about on this? right now, we are using alsa lib 1.0.13 and the device is "plughw:0,0".
2. Is there any documents detail discuss the setting about sample rate, buffer size, period size. because, I have two different voice codec to handle, one is narrow band(8k Hz), the other is wide band(16K Hz). right now, I using the following functions and setting to make alsa work. snd_pcm_hw_params_set_rate_near sets sample rate, 8k or 16k. snd_pcm_hw_params_set_period_size_near sets period size, current is 128. snd_pcm_hw_params_set_buffer_size_near sets buffer size, 8k is 2048, 16k is 4096. the unit seems be samples not byte.
3. the code was based on the following URL. http://www.suse.de/~mana/alsa090_howto.html http://www.equalarea.com/paul/alsa-audio.html open capture and playback at one function, and provide one read and one write interface to up layer. here comes three problems: a. the channel opened is just only one, but If I set the snd_pcm_hw_params_set_access as SND_PCM_ACCESS_RW_NONINTERLEAVED. using snd_pcm_readn and snd_pcm_writen the code will not work. what is the wrong? but if set snd_pcm_hw_params_set_access as SND_PCM_ACCESS_RW_INTERLEAVED and using snd_pcm_readi and snd_pcm_writei. the code work very well. one channel also have data interleave problem? I don't understand why?
b. in snd_pcm_open the block flag is set as 0. what is the mode of the operation? blocking or non-blocking?
c. call the xrun_recovery() timing. currently the xrun_recovery only do on EPIPE. the following is the handling core. err = snd_pcm_prepare(handle); if(err == -ESTRPIPE) { while ((err = snd_pcm_resume(handle)) == -EAGAIN) { nanosleep(&retryTime, &tmpTime); LOG("audio device resume fail, %s\n", snd_strerror(err)); } if(err < 0) { err = snd_pcm_prepare(handle); if(err < 0) LOG("audio data IO fail, %s\n", snd_strerror(err)); } } else { if(err < 0) LOG("audio device prepare fail, %s\n", snd_strerror(err)); }
Does the code have any missing point to handle? If any missing, what should I to add?
4. BTW, I call xrun_recovery both in capture and playback direction. After long time test. the test procedure is as the following steps: 1. capture voice data as PCM data. 2. encoded as amr-wb bit stream. 3. decoded as PCM data from encoded bit stream. 4. playback PCM data. after 16 hours continue tests, there are some delay, about 800 mili seconds. is there any way to reduce the delay after long time test. we want make the delay about < 400 mili seconds after one week continue test. BTW, is there any way to prevent xrun_recovery calling? is there any index to monitor ALSA device buffer information?
5. If we want using salsa lib to replace the usage of alsa lib, what do we have to take care? how about the latency and performance between salsa and alsa? how about the stability of salsa?
There are so many problems after many tests. If you found any documents we need to study more detail. please tell us. Thanks in advance. Thank you.
Best Regards, Akio
Dear All:
right now, I'm using alsa lib interface to work with voip application. Our hardware platform is an ARM926 266MHz box with Linux kernel 2.6.19.2. We got some problems. would you like to do us favors?
1. what is the different between "plughw:0,0", "defalut", "hw:0.0"? after reading the document in http://www.alsa-project.org/alsa-doc/alsa-lib/pcm.html about "PCM naming conventions", we still not very sure the relationship between those device conventions. is there any more detail documents talk about on this? right now, we are using alsa lib 1.0.13 and the device is "plughw:0,0".
2. Is there any documents detail discuss the setting about sample rate, buffer size, period size. because, I have two different voice codec to handle, one is narrow band(8k Hz), the other is wide band(16K Hz). right now, I using the following functions and setting to make alsa work. snd_pcm_hw_params_set_rate_near sets sample rate, 8k or 16k. snd_pcm_hw_params_set_period_size_near sets period size, current is 128. snd_pcm_hw_params_set_buffer_size_near sets buffer size, 8k is 2048, 16k is 4096. the unit seems be samples not byte.
3. the code was based on the following URL. http://www.suse.de/~mana/alsa090_howto.html http://www.equalarea.com/paul/alsa-audio.html open capture and playback at one function, and provide one read and one write interface to up layer. here comes three problems: a. the channel opened is just only one, but If I set the snd_pcm_hw_params_set_access as SND_PCM_ACCESS_RW_NONINTERLEAVED. using snd_pcm_readn and snd_pcm_writen the code will not work. what is the wrong? but if set snd_pcm_hw_params_set_access as SND_PCM_ACCESS_RW_INTERLEAVED and using snd_pcm_readi and snd_pcm_writei. the code work very well. one channel also have data interleave problem? I don't understand why?
b. in snd_pcm_open the block flag is set as 0. what is the mode of the operation? blocking or non-blocking?
c. call the xrun_recovery() timing. currently the xrun_recovery only do on EPIPE. the following is the handling core. err = snd_pcm_prepare(handle); if(err == -ESTRPIPE) { while ((err = snd_pcm_resume(handle)) == -EAGAIN) { nanosleep(&retryTime, &tmpTime); LOG("audio device resume fail, %s\n", snd_strerror(err)); } if(err < 0) { err = snd_pcm_prepare(handle); if(err < 0) LOG("audio data IO fail, %s\n", snd_strerror(err)); } } else { if(err < 0) LOG("audio device prepare fail, %s\n", snd_strerror(err)); }
Does the code have any missing point to handle? If any missing, what should I to add?
4. BTW, I call xrun_recovery both in capture and playback direction. After long time test. the test procedure is as the following steps: 1. capture voice data as PCM data. 2. encoded as amr-wb bit stream. 3. decoded as PCM data from encoded bit stream. 4. playback PCM data. after 16 hours continue tests, there are some delay, about 800 mili seconds. is there any way to reduce the delay after long time test. we want make the delay about < 400 mili seconds after one week continue test. BTW, is there any way to prevent xrun_recovery calling? is there any index to monitor ALSA device buffer information?
5. If we want using salsa lib to replace the usage of alsa lib, what do we have to take care? how about the latency and performance between salsa and alsa? how about the stability of salsa?
There are so many problems after many tests. If you found any documents we need to study more detail. please tell us. Thanks in advance. Thank you.
Best Regards, Akio
Akio wrote:
- what is the different between "plughw:0,0", "defalut", "hw:0.0"?
"hw" goes directly to the driver, without any plugins. "plughw" inserts sample rate and/or sample format conversion plugins if the format requested by the application is not supported by the driver. "default" does some additional things, depending on the driver. On most cards, it adds the "dmix" plugin for software mixing.
a. the channel opened is just only one, but If I set the snd_pcm_hw_params_set_access as SND_PCM_ACCESS_RW_NONINTERLEAVED. using snd_pcm_readn and snd_pcm_writen the code will not work. what is the wrong? but if set snd_pcm_hw_params_set_access as SND_PCM_ACCESS_RW_INTERLEAVED and using snd_pcm_readi and snd_pcm_writei. the code work very well. one channel also have data interleave problem?
INTERLEAVED is the only supported format for most stereo sound cards, so it is the setting to be used for mono, too.
NONINTERLEAVED is only used for multichannel streams that are not interleaved.
b. in snd_pcm_open the block flag is set as 0. what is the mode of the operation? blocking or non-blocking?
Blocking.
After long time test. the test procedure is as the following steps:
- capture voice data as PCM data.
- encoded as amr-wb bit stream.
- decoded as PCM data from encoded bit stream.
- playback PCM data.
after 16 hours continue tests, there are some delay, about 800 mili seconds.
You did not specify between what two quantities you've measured the delay, but I guess you mean the relative positions of the playback and capture devices.
The speed of the devices is determined by the hardware. The playback and capture devices will run out of sync if they are not using the same clock. Are the capture and playback devices on different computers?
is there any way to reduce the delay after long time test.
Measure the relative speed of the capture and playback devices, then resample accordingly (or just insert or drop a sample when needed).
- If we want using salsa lib to replace the usage of alsa lib, what do we have to take care?
Plugins for sample rate/format conversion of software mixing are not available, so your application must use a sample format support by the hardware, and only one application can use the device at the same time.
how about the latency and performance between salsa and alsa?
This is the same as when using the "hw" device with alsa-lib. The purpose of salsa is to save memory.
HTH Clemens
After long time test. the test procedure is as the following steps:
- capture voice data as PCM data.
- encoded as amr-wb bit stream.
- decoded as PCM data from encoded bit stream.
- playback PCM data.
after 16 hours continue tests, there are some delay, about 800 mili seconds.
You did not specify between what two quantities you've measured the delay, but I guess you mean the relative positions of the playback and capture devices.
The speed of the devices is determined by the hardware. The playback and capture devices will run out of sync if they are not using the same clock. Are the capture and playback devices on different computers?
thank you very much. sorry, I don't write very clear. the codec loopback is test an arm platform. the position difference is between capture and playback. when I send an 'a' speech into mic, and after 800ms, the speaker will playback. after 16 houres the delay is existed. but after further test, the delay will be reset to almost less 200ms. I'm very wondering why. BTW, there are about two times snd_pcm_prepare in capture direction. what does snd_pcm_prepare actually do? I don't know the clock is sample rate or not. but the both direction are the same, 8k, 16k, etc.
is there any way to reduce the delay after long time test.
Measure the relative speed of the capture and playback devices, then resample accordingly (or just insert or drop a sample when needed).
this is a good question. in our case, the sample number is controlled by voice codec. codec will calculate the exactly sample numbers. if we know the exactly time delay from call snd_pcm_writei to hardware generate sound, we can decide how to steal sound samples. but the exactly time delay we couldn't know. BTW, both capture and playback are at the same sample rate, 8k, 16k, etc.
- If we want using salsa lib to replace the usage of alsa lib, what do we have to take care?
Plugins for sample rate/format conversion of software mixing are not available, so your application must use a sample format support by the hardware, and only one application can use the device at the same time.
so, it means if my application didn't need any particular format, like only 16bit LE, 1 channel, 16kHz and the hardware can provide such kind of format the plugins will pass the data from hardware to my application without any conversion? In other words, If my hardware can provide the format wich I want, the plugins will just use a little cpu to move data, and no conversion effort. is it or not?
Thank you very much.
Best Regards, Akio
participants (2)
-
Akio -
Clemens Ladisch