[alsa-devel] Voip Application with ALSA OSS Emulation ==> voice delay
akioolin at gmail.com
Wed Aug 15 17:08:01 CEST 2007
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
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.
We will check the write direction to see the runtime->oss.xxx fields will
act as the same read or not. Thanks in advance.
More information about the Alsa-devel