Re: 答复: Could you help me about the ALSA?

[Jaroslav Kysela <perex@perex.cz>]

Date 14.12.2012 09:55, Zhang wei wrote:
> Thank you very much.
> 
> But if the OS lost or delayed some interrupt(s) the variable
> hw_ptr_interrupt will smaller than it should be,because delayed update
> it from last time enter the interrupt.so the
> 
> delta = runtime->hw_ptr_interrupt + runtime->period_size;
> 
> should be smaller than new_hw_ptr.

The current 'pos' value from the driver can be smaller (buffer_size
wrap) than last one. The new_hw_ptr can be lower than delta in this case.

					Jaroslav

> 
>  
> 
> -----邮件原件-----
> 发件人: Jaroslav Kysela [mailto:perex@perex.cz]
> 发送时间: 2012年12月14日 16:36
> 收件人: Zhang wei
> 抄送: ALSA development
> 主题: Re: Could you help me about the ALSA?
> 
>  
> 
> Date 14.12.2012 09:07, Zhang wei wrote:
> 
>> Good afternoon .
> 
>> 
> 
>> Excuse me if I disturb you, I found your contact information from the
> 
>> alsa-devel
> 
>> http://mailman.alsa-project.org/pipermail/alsa-devel/2010-August/030605.html
> 
>> .
> 
>> 
> 
>> Recently I am studying the alsa-driver and the code blocked me which
> 
>> from the function snd_pcm_update_hw_ptr0inthe pcm_lib.c.
> 
>> 
> 
>> =====================start==============================è
> 
>> 
> 
>>          if (in_interrupt) {
> 
>> 
> 
>>                    /* we know that one period was processed */
> 
>> 
> 
>>                    /* delta = "expected next hw_ptr" for in_interrupt !=
> 
>> 0 */
> 
>> 
> 
>>                    delta = runtime->hw_ptr_interrupt +
> runtime->period_size;
> 
>> 
> 
>>                    if (delta > new_hw_ptr) {
> 
>> 
> 
>>                             /* check for double acknowledged interrupts */
> 
>> 
> 
>>                             hdelta = jiffies - runtime->hw_ptr_jiffies;
> 
>> 
> 
>>                             if (hdelta >
> runtime->hw_ptr_buffer_jiffies/2) {
> 
>> 
> 
>>                                      hw_base += runtime->buffer_size;
> 
>> 
> 
>>                                      if (hw_base >= runtime->boundary)
> 
>> 
> 
>>                                                hw_base = 0;
> 
>> 
> 
>>                                      new_hw_ptr = hw_base + pos;
> 
>> 
> 
>>                                      goto __delta;
> 
>> 
> 
>>                             }
> 
>> 
> 
>>                    }
> 
>> 
> 
>>          }
> 
>> 
> 
>> ç================end=================================
> 
>> 
> 
>> I’ve already read your mail but I still do not understand your intend. I
> 
>> know the target of the pices of code is prevent the variable hw_ptr and
> 
>> hw_base delayed update from some kind of case .so my question is
> 
>> 
> 
>> (1)     how could happen on delta>new_hw_ptr? And why?
> 
>> 
> 
>> (2)     Why we can conclue the hw_ptr crossed the boundary of
> 
>> buffer_size when hdelta>runitme->hw_ptr_jiffies/2? What principle we
> 
>> based on?
> 
>  
> 
> The interrupts can be lost or delayed in some cases (small period sizes
> 
> etc.). So you need to check for these situations. The driver returns
> 
> only position in the ring buffer without count of "cross" points, so we
> 
> need to trace these situations using another clock source (like system
> 
> clock).
> 
>  
> 
>                        Jaroslav
> 
>  
> 
> -- 
> 
> Jaroslav Kysela <perex@perex.cz>
> 
> Linux Kernel Sound Maintainer
> 
> ALSA Project; Red Hat, Inc.
> 


-- 
Jaroslav Kysela <perex@perex.cz>
Linux Kernel Sound Maintainer
ALSA Project; Red Hat, Inc.
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel