[alsa-devel] what is period_size, buffer_size and boundary size, i confuse them

[l9jj at 163.com]

thank you very much for your help. i got another question in the interface snd_pcm_update_hw_ptr0(). The reference code is below. (1)i know that the result of representation (hdelta * HZ) / runtime->rate means the delta jiffies which spend on moving the data from the new_hw_ptr to the old_hw_ptr in the dma buffer. (2)and the jdelta represents the interval jiffies between now and last time enter here.

(3)the question is why can we think there is more than one interrupt has lost across comparing the two variables size? (4)and if the compare idear setup that means one interrupt will take jdelta jiffies in time,so if someone is bigger it we can know that.is it true? (5)if the (4) is correct, why do not use the representation (runtime->period_size * HZ) / runtime->rate) as the interrupt interval, because it is fixed and the jdelta is not. (6)why plus the HZ/100 after jdelta and (runtime->period_size * HZ) / runtime->rate) ? for ensuring have enought time? HZ ==> 1 s HZ/1000 ===> 1 ms HZ/100 ===> 10 ms ? =================================reference code start ====================================> /* Skip the jiffies check for hardwares with BATCH flag. * Such hardware usually just increases the position at each IRQ, * thus it can't give any strange position. */if (runtime->hw.info & SNDRV_PCM_INFO_BATCH) goto no_jiffies_check; hdelta = delta; if (hdelta < runtime->delay) goto no_jiffies_check; hdelta -= runtime->delay; jdelta = jiffies - runtime->hw_ptr_jiffies; if (((hdelta * HZ) / runtime->rate) > jdelta + HZ/100) { delta = jdelta /(((runtime->period_size * HZ) / runtime->rate) + HZ/100); /* move new_hw_ptr according jiffies not pos variable */new_hw_ptr = old_hw_ptr; hw_base = delta; /* use loop to avoid checks for delta overflows *//* the delta value is small or zero in most cases */while (delta > 0) { new_hw_ptr += runtime->period_size; if (new_hw_ptr >= runtime->boundary) new_hw_ptr -= runtime->boundary; delta--; } /* align hw_base to buffer_size */hw_ptr_error(substream, "hw_ptr skipping! %s" "(pos=%ld, delta=%ld, period=%ld, " "jdelta=%lu/%lu/%lu, hw_ptr=%ld/%ld)\n", in_interrupt ? "[Q] " : "", (long)pos, (long)hdelta, (long)runtime->period_size, jdelta, ((hdelta * HZ) / runtime->rate), hw_base, (unsigned long)old_hw_ptr, (unsigned long)new_hw_ptr); /* reset values to proper state */delta = 0; hw_base = new_hw_ptr - (new_hw_ptr % runtime->buffer_size); } <======================================end =================================================== Best Regards.




在 2012-12-10 16:24:59, Clemens Ladisch <clemens at ladisch.de>写道:
l9jj at 163.com wrote:
> does  the variable buffer_size equal to  DMA size?

Yes.

> (2)how the pos>buffer_size will happen in the interface snd_pcm_update_hw_ptr0()?

It happens when your driver has a bug.  The .pointer callback always must
return value that is inside the DMA buffer.


Regards,
Clemens
_______________________________________________
Alsa-devel mailing list
Alsa-devel at alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel


l9jj at 163.com

 ——网易邮箱手机客户端——
-------------- next part --------------
A non-text attachment was scrubbed...
Name: emailtxt.txt
Type: application/octet-stream
Size: 2675 bytes
Desc: not available
URL: <http://mailman.alsa-project.org/pipermail/alsa-devel/attachments/20121210/998a7307/attachment.obj>