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