* Re: Could you help me about the ALSA?
[not found] <6B947C8AC4195040A8C6876A496C644A07BAB641@BJ-MAIL-04.vimicro.com>
@ 2012-12-14 8:36 ` Jaroslav Kysela
2012-12-14 8:55 ` 答复: " Zhang wei
0 siblings, 1 reply; 7+ messages in thread
From: Jaroslav Kysela @ 2012-12-14 8:36 UTC (permalink / raw)
To: Zhang wei; +Cc: ALSA development
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.
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
^ permalink raw reply [flat|nested] 7+ messages in thread* 答复: Could you help me about the ALSA?
2012-12-14 8:36 ` Could you help me about the ALSA? Jaroslav Kysela
@ 2012-12-14 8:55 ` Zhang wei
2012-12-14 9:46 ` Jaroslav Kysela
0 siblings, 1 reply; 7+ messages in thread
From: Zhang wei @ 2012-12-14 8:55 UTC (permalink / raw)
To: Jaroslav Kysela; +Cc: ALSA development
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.
-----邮件原件-----
发件人: 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.
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
^ permalink raw reply [flat|nested] 7+ messages in thread* Re: 答复: Could you help me about the ALSA?
2012-12-14 8:55 ` 答复: " Zhang wei
@ 2012-12-14 9:46 ` Jaroslav Kysela
2012-12-14 10:46 ` Zhang wei
0 siblings, 1 reply; 7+ messages in thread
From: Jaroslav Kysela @ 2012-12-14 9:46 UTC (permalink / raw)
To: Zhang wei; +Cc: ALSA development
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
^ permalink raw reply [flat|nested] 7+ messages in thread* Could you help me about the ALSA?
2012-12-14 9:46 ` Jaroslav Kysela
@ 2012-12-14 10:46 ` Zhang wei
2012-12-14 11:01 ` Jaroslav Kysela
0 siblings, 1 reply; 7+ messages in thread
From: Zhang wei @ 2012-12-14 10:46 UTC (permalink / raw)
To: Jaroslav Kysela; +Cc: ALSA development
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
Yes,when buffer_size wraped the 'pos' is smallar than last one.If we
want to confirm the hw_base need to adjust there must be consider
another confidition:
hdelta = jiffies - runtime->hw_ptr_jiffies;
if (hdelta > runtime->hw_ptr_buffer_jiffies/2)
how to connect this code with checking unnormal interrupt(lost or
delayed)?
Why we can prove need to adjust the 'hw_base' when 'hdelta' >
hw_ptr_buffer_jiffies/2 ? the former represent the jiffier error between
this moment and last be here(maybe called from non-interrupt elpased()).
The later means the time spend on fill the buffer.Then compare them and
we will find if 'delta' is bigger means the DMA already fininshed a
period at least without notice the OS?
The compariation confused me.I can not get the relationship from the
result and what the information or clue is ignored by me? Please give me
some tips. Thank you.
^ permalink raw reply [flat|nested] 7+ messages in thread* Re: Could you help me about the ALSA?
2012-12-14 10:46 ` Zhang wei
@ 2012-12-14 11:01 ` Jaroslav Kysela
2012-12-16 14:13 ` l9jj
2012-12-17 2:09 ` Zhang wei
0 siblings, 2 replies; 7+ messages in thread
From: Jaroslav Kysela @ 2012-12-14 11:01 UTC (permalink / raw)
To: Zhang wei; +Cc: ALSA development
Date 14.12.2012 11:46, Zhang wei wrote:
> 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
>
>
>
> Yes,when buffer_size wraped the 'pos' is smallar than last one.If we
> want to confirm the hw_base need to adjust there must be consider
> another confidition:
>
> hdelta = jiffies - runtime->hw_ptr_jiffies;
>
> if (hdelta > runtime->hw_ptr_buffer_jiffies/2)
>
> how to connect this code with checking unnormal interrupt(lost or delayed)?
This condition is for the double interrupt acknowledge problems (see
comment). It makes sure, that the DMA buffer position was wrapped using
another external timing source. Indeed, it's mostly a lowlevel driver
fault to call this pointer update routine with the in_interrupt flag
when the period was not really elapsed.
> Why we can prove need to adjust the ‘hw_base’when ‘hdelta’>
> hw_ptr_buffer_jiffies/2 ? the former represent the jiffier error between
> this moment and last be here(maybe called from non-interrupt elpased()).
>
> The later means the time spend on fill the buffer.Then compare them and
> we will find if ‘delta’is bigger means the DMA already fininshed a
> period at least without notice the OS?
>
> The compariation confused me.I can not get the relationship from the
> result and what the information or clue is ignored by me? Please give me
> some tips. Thank you.
Please, study the comments again.
Jaroslav
--
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
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Could you help me about the ALSA?
2012-12-14 11:01 ` Jaroslav Kysela
@ 2012-12-16 14:13 ` l9jj
2012-12-17 2:09 ` Zhang wei
1 sibling, 0 replies; 7+ messages in thread
From: l9jj @ 2012-12-16 14:13 UTC (permalink / raw)
To: Jaroslav Kysela; +Cc: ALSA development, Zhang wei
>>
>>
>>
>> Yes,when buffer_size wraped the 'pos' is smallar than last one.If we
>> want to confirm the hw_base need to adjust there must be consider
>> another confidition:
>>
>> hdelta = jiffies - runtime->hw_ptr_jiffies;
>>
>> if (hdelta > runtime->hw_ptr_buffer_jiffies/2)
>>
>> how to connect this code with checking unnormal interrupt(lost or delayed)?
>
>This condition is for the double interrupt acknowledge problems (see
>comment). It makes sure, that the DMA buffer position was wrapped using
>another external timing source. Indeed, it's mostly a lowlevel driver
>fault to call this pointer update routine with the in_interrupt flag
>when the period was not really elapsed.
>
But,why alsa use the specific value 'runtime->hw_ptr_buffer_jiffies/2' to compare with hdelta than other?
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Could you help me about the ALSA?
2012-12-14 11:01 ` Jaroslav Kysela
2012-12-16 14:13 ` l9jj
@ 2012-12-17 2:09 ` Zhang wei
1 sibling, 0 replies; 7+ messages in thread
From: Zhang wei @ 2012-12-17 2:09 UTC (permalink / raw)
To: Jaroslav Kysela; +Cc: ALSA development
> Yes,when buffer_size wraped the 'pos' is smallar than last one.If we
> want to confirm the hw_base need to adjust there must be consider
> another confidition:
>
> hdelta = jiffies - runtime->hw_ptr_jiffies;
>
> if (hdelta > runtime->hw_ptr_buffer_jiffies/2)
>
> how to connect this code with checking unnormal interrupt(lost or
delayed)?
This condition is for the double interrupt acknowledge problems (see
comment). It makes sure, that the DMA buffer position was wrapped using
another external timing source. Indeed, it's mostly a lowlevel driver
fault to call this pointer update routine with the in_interrupt flag
when the period was not really elapsed.
Yes,I saw the comment and known the target of the pices of code and
known alsa use jiffies as another timing source to detect the wrap
situation,but I do not understand how to detect or check that case.In
other word,why does alsa use the value runtime->hw_ptr_buffer_jiffies/2
not runtime->hw_ptr_buffer_jiffies/3 or runtime->hw_ptr_buffer_jiffies/4
...?
--
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
^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2012-12-17 2:10 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <6B947C8AC4195040A8C6876A496C644A07BAB641@BJ-MAIL-04.vimicro.com>
2012-12-14 8:36 ` Could you help me about the ALSA? Jaroslav Kysela
2012-12-14 8:55 ` 答复: " Zhang wei
2012-12-14 9:46 ` Jaroslav Kysela
2012-12-14 10:46 ` Zhang wei
2012-12-14 11:01 ` Jaroslav Kysela
2012-12-16 14:13 ` l9jj
2012-12-17 2:09 ` Zhang wei
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).