[alsa-devel] my driver can't reproduce continuously
tiwai at suse.de
Fri Jul 24 11:32:39 CEST 2009
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 ?
> 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
> 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.
More information about the Alsa-devel