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 _______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxx http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
