[alsa-devel] my driver can't reproduce continuously

Takashi Iwai 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 ?

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


More information about the Alsa-devel mailing list