At Fri, 24 Jul 2009 17:56:01 +0900, Kuninori Morimoto wrote:
Dear All
Underrun means that the driver is consuming data more quickly than aplay is able to provide it. This may mean that there's some system performance problem or it may be due to your driver is consuming data more quickly than it should and causing problems further up the stack.
I would like to ask about size of period, buffer.
In my environment, each data size are follows.
runtime->buffer_size = 8192 runtime->period_size = 2048 runtime->periods = 4 buffer_len = frames_to_bytes(runtime, runtime->buffer_size) = 32768 period_len = frames_to_bytes(runtime, runtime->period_size) = 8192
After sending period_len byte (=8192 byte = 2048 frame) I call snd_pcm_period_esapsed(). after that snd_pcm_update_hw_ptr_interrupt() is called. Is this correct ?
Correct.
Then, runtime->hw_ptr_base will be updated In this function. How is this hw_ptr_base renewed ?
At 4th snd_pcm_period_elapsed() call, buffer_size is added. Or, when the value returned from pointer callback is lapped to zero or such.
(snip)
why hw_prt_base update size is 8192 = buffer_size ?
please check hw_prt near <== **.
hw_prt_base = 0, hw_prt = 1856 hw_prt_base = 0, hw_prt = 1984 hw_prt_base = 8192, hw_prt = 8256 <== ** hw_prt_base = 8192, hw_prt = 8192
My rough guess is that your pointer callback returns a wrong value. The pointer callback is supposed to give the currently played position offset in a ring buffer, and ranged from 0 to buffer_size-1. When the first snd_pcm_period_elapsed() is called, it should be (ideally) pointing at period_size, at the succeeding calls, period_size*2, period_size*3, then 0 again.
Try to track the value returned from the pointer callback.
Takashi