[alsa-devel] Voip Application with ALSA OSS Emulation ==> voice delay
Dear Sir:
Could you do me a favor?
Right now, we are using a arm box with linux kernel 2.6.14 to develop a voip solution. After the rtp connection was connected at first 20 secs, there is no delay. As the timing passing by, the delay will going longer and longer. After 16 houres, the delay will up to 12 secs. Because the alsa lib application can't detect any alsa device, we have no choice but only alsa oss emulation data path to using audio device. after tracing sound/core/oss/pcm_oss.c. we find some things.
1.in snd_pcm_oss_write() and in snd_pcm_oss_read(), there is a little slight difference. in snd_pcm_oss_write(), before and after snd_pcm_oss_write1() there are using up() and down() to protect snd_pcm_oss_write1(). but in snd_pcm_oss_read(), there is no protection. why doesn't use up() and down() to protect snd_pcm_oss_read1()?
2.after using printk to tracing runtime->oss.xxx fields in snd_pcm_oss_read1(), we got the data positions seem correct. and alignment very well. what should we have to check? where do we have to check?
3.in snd_pcm_oss_capture_position_fixup(), why using the following condition to check, if (*delay <= (snd_pcm_sframes_t)runtime->buffer_size)? why not using if (*delay <= (snd_pcm_sframes_t)runtime->period_size)?
because the following wrapping, frames = (*delay - runtime->buffer_size) + runtime->period_size - 1; frames /= runtime->period_size; frames *= runtime->period_size; using runtime->period_size, not runtime->buffer_size.
4.why using snd_pcm_oss_capture_position_fixup() in snd_pcm_oss_read3() not in snd_pcm_oss_read()?
5.the following url seem counter the same problems. http://blackfin.uclinux.org/gf/project/uclinux-dist/forum/? action=ForumBrowse&forum_id=39&_forum_action= ForumMessageBrowse&thread_id=22524
We will check the write direction to see the runtime->oss.xxx fields will act as the same read or not. Thanks in advance. Best Regards, Akio
Akio wrote:
Right now, we are using a arm box with linux kernel 2.6.14 to develop a voip solution. After the rtp connection was connected at first 20 secs, there is no delay. As the timing passing by, the delay will going longer and longer. After 16 houres, the delay will up to 12 secs.
If the sending and the receiving computers don't use the same clock, there will be a small difference in the sample rate. You have to measure this and adjust the data accordingly (by resampling or just adding/dropping some samples).
Because the alsa lib application can't detect any alsa device,
I'd guess that either the device nodes in /dev/snd/ or the configuration files in /use/share/alsa/ are missing.
HTH Clemens
Clemens Ladisch <cladisch <at> fastmail.net> writes:
Akio wrote:
Right now, we are using a arm box with linux kernel 2.6.14 to develop a voip solution. After the rtp connection was connected at first 20 secs, there is no delay. As the timing passing by, the delay will going longer and longer. After 16 hours, the delay will up to 12 secs.
If the sending and the receiving computers don't use the same clock, there will be a small difference in the sample rate. You have to measure this and adjust the data accordingly (by re-sampling or just adding/dropping some samples).
Thank you very much. I think the CPU power is so tight, there is no room to do that conversion.
Because the alsa lib application can't detect any alsa device,
I'd guess that either the device nodes in /dev/snd/ or the configuration files in /use/share/alsa/ are missing.
Could you can show me how to build the right structure to make alsa lib to work? May be this is the right way to void voice delay.
HTH Clemens
BTW, after many tests. I find the following combination that seems make the delay disappear in read direction, but in write direction, there will be some extra space been added. Right now, I find two points to suppress voice delay via the following method.
1. in sound/core/oss/pcm_oss.c, in snd_pcm_oss_read3(), mark the break branch which after snd_pcm_oss_capture_position_fixup(). the original code is like : ret = snd_pcm_oss_capture_position_fixup(); if (ret < 0) break;
to the following one: ret = snd_pcm_oss_capture_position_fixup(); //if (ret < 0) // break;
2.in snd_pcm_oss_capture_position_fixup(), change the delay calculation method. from the original one: if (*delay <= (snd_pcm_sframes_t)runtime->buffer_size) break; frames = (*delay - runtime->buffer_size) + runtime->period_size - 1; frames /= runtime->period_size; frames *= runtime->period_size;
to the following one: if (*delay <= (snd_pcm_sframes_t)runtime->period_size) break; frames = (((*delay + runtime->period_size - 1) / runtime->period_size)) * runtime->period_size;
Does the modification will cause other side effect or not? How to solve the extra space in write space?
Thanks in advance.
Best Regards, Akio
participants (2)
-
Akio -
Clemens Ladisch