hw_pointer error message triggered without need

hw_pointer error message triggered without need

[Tobias Peters]

I'm using linux-2.4.22 with alsa drivers 0.9.7c. Sound card driver in 
use was intel 8x0 (but I doubt it's responsible in this case).

ALSA ../alsa-kernel/core/pcm_lib.c:216: Unexpected hw_pointer value
(stream = 0, delta: -255, max jitter = 256): wrong interrupt acknowledge?

If I understand the relevant code correctly, then this error message is 
triggered unnecessarily if the hardware buffer is only two periods in 
size.  It is triggered when the hardware pointer has already been 
increased by one sample since the last period completed.

Not so if there are more periods per buffer.

   Tobias





-------------------------------------------------------
This SF.net email is sponsored by OSDN developer relations
Here's your chance to show off your extensive product knowledge
We want to know what you know. Tell us and you have a chance to win $100
http://www.zoomerang.com/survey.zgi?HRPT1X3RYQNC5V4MLNSV3E54

Re: hw_pointer error message triggered without need

[Takashi Iwai]

At Tue, 21 Oct 2003 17:37:30 +0200,
Tobias Peters wrote:
> 
> I'm using linux-2.4.22 with alsa drivers 0.9.7c. Sound card driver in 
> use was intel 8x0 (but I doubt it's responsible in this case).
> 
> ALSA ../alsa-kernel/core/pcm_lib.c:216: Unexpected hw_pointer value
> (stream = 0, delta: -255, max jitter = 256): wrong interrupt acknowledge?
> 
> If I understand the relevant code correctly, then this error message is 
> triggered unnecessarily if the hardware buffer is only two periods in 
> size.  It is triggered when the hardware pointer has already been 
> increased by one sample since the last period completed.
> 
> Not so if there are more periods per buffer.

well, it's not unnecessary but too strict.
especially, if the hardware generates too late (often seen on onboard
chips), and if only two periods are used, this situation can happen.

i think delta < (runtime->period_size/2) would be enough to check the
negative (invalid) hwptr rather than delta < (runtime->buffer_size/2)
as it is.


Takashi


-------------------------------------------------------
This SF.net email is sponsored by OSDN developer relations
Here's your chance to show off your extensive product knowledge
We want to know what you know. Tell us and you have a chance to win $100
http://www.zoomerang.com/survey.zgi?HRPT1X3RYQNC5V4MLNSV3E54

Re: hw_pointer error message triggered without need

[Jaroslav Kysela]

On Tue, 21 Oct 2003, Takashi Iwai wrote:

> At Tue, 21 Oct 2003 17:37:30 +0200,
> Tobias Peters wrote:
> >
> > I'm using linux-2.4.22 with alsa drivers 0.9.7c. Sound card driver in
> > use was intel 8x0 (but I doubt it's responsible in this case).
> >
> > ALSA ../alsa-kernel/core/pcm_lib.c:216: Unexpected hw_pointer value
> > (stream = 0, delta: -255, max jitter = 256): wrong interrupt acknowledge?
> >
> > If I understand the relevant code correctly, then this error message is
> > triggered unnecessarily if the hardware buffer is only two periods in
> > size.  It is triggered when the hardware pointer has already been
> > increased by one sample since the last period completed.
> >
> > Not so if there are more periods per buffer.
>
> well, it's not unnecessary but too strict.
> especially, if the hardware generates too late (often seen on onboard
> chips), and if only two periods are used, this situation can happen.
>
> i think delta < (runtime->period_size/2) would be enough to check the
> negative (invalid) hwptr rather than delta < (runtime->buffer_size/2)
> as it is.

Nope. This check will be wrong because we will fall to the wrap point and
increase hw_ptr_base with buffer_size.

Looking to code, it seems that an interrupt was lost. Its quite impossible
to create a realiable check for lost interrupts when you have only two
periods in the midlevel code. Or the interrupt was generated too early.

Anyway, I think that we should leave the check as is for debugging
purposes (we should know that something is failing).

						Jaroslav

-----
Jaroslav Kysela <perex@suse.cz>
Linux Kernel Sound Maintainer
ALSA Project, SuSE Labs


-------------------------------------------------------
This SF.net email is sponsored by OSDN developer relations
Here's your chance to show off your extensive product knowledge
We want to know what you know. Tell us and you have a chance to win $100
http://www.zoomerang.com/survey.zgi?HRPT1X3RYQNC5V4MLNSV3E54

Re: hw_pointer error message triggered without need

[Takashi Iwai]

At Tue, 21 Oct 2003 19:24:04 +0200 (CEST),
Jaroslav wrote:
> 
> On Tue, 21 Oct 2003, Takashi Iwai wrote:
> 
> > At Tue, 21 Oct 2003 17:37:30 +0200,
> > Tobias Peters wrote:
> > >
> > > I'm using linux-2.4.22 with alsa drivers 0.9.7c. Sound card driver in
> > > use was intel 8x0 (but I doubt it's responsible in this case).
> > >
> > > ALSA ../alsa-kernel/core/pcm_lib.c:216: Unexpected hw_pointer value
> > > (stream = 0, delta: -255, max jitter = 256): wrong interrupt acknowledge?
> > >
> > > If I understand the relevant code correctly, then this error message is
> > > triggered unnecessarily if the hardware buffer is only two periods in
> > > size.  It is triggered when the hardware pointer has already been
> > > increased by one sample since the last period completed.
> > >
> > > Not so if there are more periods per buffer.
> >
> > well, it's not unnecessary but too strict.
> > especially, if the hardware generates too late (often seen on onboard
> > chips), and if only two periods are used, this situation can happen.
> >
> > i think delta < (runtime->period_size/2) would be enough to check the
> > negative (invalid) hwptr rather than delta < (runtime->buffer_size/2)
> > as it is.
> 
> Nope. This check will be wrong because we will fall to the wrap point and
> increase hw_ptr_base with buffer_size.

the problem is that this check is too strict when only two periods are
used.  since buffer_size/2 == period_size, if the update of hwptr is
delayed even for one sample, it won't pass.

> Looking to code, it seems that an interrupt was lost. Its quite impossible
> to create a realiable check for lost interrupts when you have only two
> periods in the midlevel code. Or the interrupt was generated too early.

there is a little difference between snd_pcm_update_hw_ptr() and
snd_pcm_update_hw_ptr_interrupt(), and this problem doesn't happen in
the former but only in the latter function, which is invoked by
snd_pcm_lib_write1().

in the former function, delta is the difference between the expected
pointer (lastptr + period_size) and the current pointer.  meanwhile,
in the latter function, delta is the difference between the last
pointer and the new pointer.
hence, the calculation of delta in the latter function can be easily
less than buffer_size/2 when nperiods = 2.

> Anyway, I think that we should leave the check as is for debugging
> purposes (we should know that something is failing).

sure, it's harmless message (as long as it comes from
snd_pcm_update_hw_ptr()) but too annoying.  there are too many
sloppy hardwares...


Takashi


-------------------------------------------------------
This SF.net email is sponsored by OSDN developer relations
Here's your chance to show off your extensive product knowledge
We want to know what you know. Tell us and you have a chance to win $100
http://www.zoomerang.com/survey.zgi?HRPT1X3RYQNC5V4MLNSV3E54

Re: hw_pointer error message triggered without need

[Manuel Jander]

Hallo,

There really something wrong. 

718, max jitter = 8192): wrong interrupt acknowledge?
ALSA sound/core/pcm_lib.c:157: Unexpected hw_pointer value (stream = 0,
delta: -297, max jitter = 1024): wrong interrupt acknowledge?
ALSA sound/core/pcm_lib.c:157: Unexpected hw_pointer value (stream = 0,
delta: -722, max jitter = 8192): wrong interrupt acknowledge?
ALSA sound/core/pcm_lib.c:157: Unexpected hw_pointer value (stream = 0,
delta: -301, max jitter = 1024): wrong interrupt acknowledge?
ALSA sound/core/pcm_lib.c:157: Unexpected hw_pointer value (stream = 0,
delta: -726, max jitter = 8192): wrong interrupt acknowledge?
ALSA sound/core/pcm_lib.c:157: Unexpected hw_pointer value (stream = 0,
delta: -305, max jitter = 1024): wrong interrupt acknowledge?
ALSA sound/core/pcm_lib.c:157: Unexpected hw_pointer value (stream = 0,
delta: -730, max jitter = 8192): wrong interrupt acknowledge?

How do you explain this ???

At first i would vote for eliminating that "-" since it leads one to
think into negative deltas, that really dones make any sense.

And why is the "max jitter" changing all the time ? And the delta is
smaller than the "max jitter", so why should it complain ??

I just want to know if me soundboard is smoking crack or what ?

Best Regards

Manuel Jander.

On Tue, 2003-10-21 at 13:55, Takashi Iwai wrote:
> At Tue, 21 Oct 2003 19:24:04 +0200 (CEST),
> Jaroslav wrote:
> > 
> > On Tue, 21 Oct 2003, Takashi Iwai wrote:
> > 
> > > At Tue, 21 Oct 2003 17:37:30 +0200,
> > > Tobias Peters wrote:
> > > >
> > > > I'm using linux-2.4.22 with alsa drivers 0.9.7c. Sound card driver in
> > > > use was intel 8x0 (but I doubt it's responsible in this case).
> > > >
> > > > ALSA ../alsa-kernel/core/pcm_lib.c:216: Unexpected hw_pointer value
> > > > (stream = 0, delta: -255, max jitter = 256): wrong interrupt acknowledge?
> > > >
> > > > If I understand the relevant code correctly, then this error message is
> > > > triggered unnecessarily if the hardware buffer is only two periods in
> > > > size.  It is triggered when the hardware pointer has already been
> > > > increased by one sample since the last period completed.
> > > >
> > > > Not so if there are more periods per buffer.
> > >
> > > well, it's not unnecessary but too strict.
> > > especially, if the hardware generates too late (often seen on onboard
> > > chips), and if only two periods are used, this situation can happen.
> > >
> > > i think delta < (runtime->period_size/2) would be enough to check the
> > > negative (invalid) hwptr rather than delta < (runtime->buffer_size/2)
> > > as it is.
> > 
> > Nope. This check will be wrong because we will fall to the wrap point and
> > increase hw_ptr_base with buffer_size.
> 
> the problem is that this check is too strict when only two periods are
> used.  since buffer_size/2 == period_size, if the update of hwptr is
> delayed even for one sample, it won't pass.
> 
> > Looking to code, it seems that an interrupt was lost. Its quite impossible
> > to create a realiable check for lost interrupts when you have only two
> > periods in the midlevel code. Or the interrupt was generated too early.
> 
> there is a little difference between snd_pcm_update_hw_ptr() and
> snd_pcm_update_hw_ptr_interrupt(), and this problem doesn't happen in
> the former but only in the latter function, which is invoked by
> snd_pcm_lib_write1().
> 
> in the former function, delta is the difference between the expected
> pointer (lastptr + period_size) and the current pointer.  meanwhile,
> in the latter function, delta is the difference between the last
> pointer and the new pointer.
> hence, the calculation of delta in the latter function can be easily
> less than buffer_size/2 when nperiods = 2.
> 
> > Anyway, I think that we should leave the check as is for debugging
> > purposes (we should know that something is failing).
> 
> sure, it's harmless message (as long as it comes from
> snd_pcm_update_hw_ptr()) but too annoying.  there are too many
> sloppy hardwares...
> 
> 
> Takashi
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by OSDN developer relations
> Here's your chance to show off your extensive product knowledge
> We want to know what you know. Tell us and you have a chance to win $100
> http://www.zoomerang.com/survey.zgi?HRPT1X3RYQNC5V4MLNSV3E54
> _______________________________________________
> Alsa-devel mailing list
> Alsa-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/alsa-devel
> 



-------------------------------------------------------
This SF.net email is sponsored by OSDN developer relations
Here's your chance to show off your extensive product knowledge
We want to know what you know. Tell us and you have a chance to win $100
http://www.zoomerang.com/survey.zgi?HRPT1X3RYQNC5V4MLNSV3E54

Re: hw_pointer error message triggered without need

[Tobias Peters]

Manuel Jander wrote:
> There really something wrong. 
> ALSA sound/core/pcm_lib.c:157: Unexpected hw_pointer value (stream = 0,
> delta: -297, max jitter = 1024): wrong interrupt acknowledge?

>>>>At Tue, 21 Oct 2003 17:37:30 +0200,
>>>>Tobias Peters wrote:
>>>>>ALSA ../alsa-kernel/core/pcm_lib.c:216: Unexpected hw_pointer value
>>>>>(stream = 0, delta: -255, max jitter = 256): wrong interrupt acknowledge?

Compare the line numbers, yours is a different error message.

The minus sign in the message I got is just fine, because the new 
hw_pointer value really is lesser than it was before.

   Tobias




-------------------------------------------------------
This SF.net email is sponsored by OSDN developer relations
Here's your chance to show off your extensive product knowledge
We want to know what you know. Tell us and you have a chance to win $100
http://www.zoomerang.com/survey.zgi?HRPT1X3RYQNC5V4MLNSV3E54

Re: hw_pointer error message triggered without need

[Takashi Iwai]

At Tue, 21 Oct 2003 22:00:33 -0400,
Manuel Jander wrote:
> 
> Hallo,
> 
> There really something wrong. 
> 
> 718, max jitter = 8192): wrong interrupt acknowledge?
> ALSA sound/core/pcm_lib.c:157: Unexpected hw_pointer value (stream = 0,
> delta: -297, max jitter = 1024): wrong interrupt acknowledge?
> ALSA sound/core/pcm_lib.c:157: Unexpected hw_pointer value (stream = 0,
> delta: -722, max jitter = 8192): wrong interrupt acknowledge?
> ALSA sound/core/pcm_lib.c:157: Unexpected hw_pointer value (stream = 0,
> delta: -301, max jitter = 1024): wrong interrupt acknowledge?
> ALSA sound/core/pcm_lib.c:157: Unexpected hw_pointer value (stream = 0,
> delta: -726, max jitter = 8192): wrong interrupt acknowledge?
> ALSA sound/core/pcm_lib.c:157: Unexpected hw_pointer value (stream = 0,
> delta: -305, max jitter = 1024): wrong interrupt acknowledge?
> ALSA sound/core/pcm_lib.c:157: Unexpected hw_pointer value (stream = 0,
> delta: -730, max jitter = 8192): wrong interrupt acknowledge?
> 
> How do you explain this ???

the hwptr is not updated properly.
> 
> At first i would vote for eliminating that "-" since it leads one to
> think into negative deltas, that really dones make any sense.
 
yes, it's a bit confusing, but minus makes sense because the delta
value (= new - old) is in fact negative.  in the calculation,
(old - new) is used to avoid the sign conversion, though.

> And why is the "max jitter" changing all the time ?

do they come from the same stream?

anyway, your code above is too old now.  the line doesn't correspond
to the latest version.  so i cannot say exactly.

> And the delta is
> smaller than the "max jitter", so why should it complain ??

it's not the comparison like delta > max_jitter.
it's the check for the overlap of the ring buffer.
the pcm routine tries to detect whether the hwptr moved across the
ring buffer boundary.  and for that, delta > -max_jitter is
performed.  since delta in the code is (old - new), the comparison is
reversed.

> I just want to know if me soundboard is smoking crack or what ?

if this comes from snd_pcm_update_hw_ptr_interrupt(), then it's a
serious problem.  if it comes from snd_pcm_update_hw_ptr(), it's
mostly harmless, as i wrote in the previous post.

the alsa pcm tries to update hwptr often, not only when the interrupts
are issued and snd_pcm_period_elapsed() is called.
(e.g. at each read or write call, or when RESET, FORWARD, REWIND,
HWSYNC or DELAY ioctl is used.)   this problem happens likely in such
a case, especially when interrupt handling is sloppy, or pointer
callback is not reliable.


Takashi


-------------------------------------------------------
This SF.net email is sponsored by OSDN developer relations
Here's your chance to show off your extensive product knowledge
We want to know what you know. Tell us and you have a chance to win $100
http://www.zoomerang.com/survey.zgi?HRPT1X3RYQNC5V4MLNSV3E54

Re: hw_pointer error message triggered without need

[Tobias Peters]

Takashi Iwai wrote:

>>>well, it's not unnecessary but too strict.

Yes.

> the problem is that this check is too strict when only two periods are
> used.  since buffer_size/2 == period_size, if the update of hwptr is
> delayed even for one sample, it won't pass.

This is exactly what happens in my case.

>>Anyway, I think that we should leave the check as is for debugging
>>purposes (we should know that something is failing).
> 
> 
> sure, it's harmless message (as long as it comes from
> snd_pcm_update_hw_ptr()) but too annoying.  there are too many
> sloppy hardwares...

After printing the error message is printed, the function returns 
immediately. Can you confirm that this does not have negative side 
effects like dropped frames?

Besides, the error messages popping up in the console interfere visually 
with the text mode interface of the sound app that I use.

   Tobias




-------------------------------------------------------
This SF.net email is sponsored by OSDN developer relations
Here's your chance to show off your extensive product knowledge
We want to know what you know. Tell us and you have a chance to win $100
http://www.zoomerang.com/survey.zgi?HRPT1X3RYQNC5V4MLNSV3E54

Re: hw_pointer error message triggered without need

[Takashi Iwai]

At Wed, 22 Oct 2003 10:16:47 +0200,
Tobias Peters wrote:
> 
> >>Anyway, I think that we should leave the check as is for debugging
> >>purposes (we should know that something is failing).
> > 
> > 
> > sure, it's harmless message (as long as it comes from
> > snd_pcm_update_hw_ptr()) but too annoying.  there are too many
> > sloppy hardwares...
> 
> After printing the error message is printed, the function returns 
> immediately. Can you confirm that this does not have negative side 
> effects like dropped frames?

no, the hwptr must be updated correctly in
snd_pcm_update_hw_ptr_interrupt() anyway.

> Besides, the error messages popping up in the console interfere visually 
> with the text mode interface of the sound app that I use.

this is likely because irq is not handled correctly when framebuffer
is switched.  the framebuffer is a bad source of irq blocking.


Takashi


-------------------------------------------------------
This SF.net email is sponsored by OSDN developer relations
Here's your chance to show off your extensive product knowledge
We want to know what you know. Tell us and you have a chance to win $100
http://www.zoomerang.com/survey.zgi?HRPT1X3RYQNC5V4MLNSV3E54

Re: hw_pointer error message triggered without need

[Tobias Peters]

Takashi Iwai wrote:
> At Wed, 22 Oct 2003 10:16:47 +0200,
> Tobias Peters wrote:
> > Besides, the error messages popping up in the console interfere visually 
> > with the text mode interface of the sound app that I use.
> 
> this is likely because irq is not handled correctly when framebuffer
> is switched.  the framebuffer is a bad source of irq blocking.

Framebuffer cannot be responsible in this case because I compiled the 
kernel without framebuffer support and I use plain 80x25 vga text screens. 

I do switch between 2 virtual consoles sometimes, but occurence of the 
error messages is completely uncorrelated to this switching.

The sound chip is most likely the one to blame. I just ask for a more 
graceful handling in the driver when the interupt is 1 sample too late. 

  Tobias




-------------------------------------------------------
This SF.net email is sponsored by OSDN developer relations
Here's your chance to show off your extensive product knowledge
We want to know what you know. Tell us and you have a chance to win $100
http://www.zoomerang.com/survey.zgi?HRPT1X3RYQNC5V4MLNSV3E54

Re: hw_pointer error message triggered without need

[Takashi Iwai]

At Thu, 23 Oct 2003 09:31:12 +0200 (CEST),
Tobias Peters wrote:
> 
> Takashi Iwai wrote:
> > At Wed, 22 Oct 2003 10:16:47 +0200,
> > Tobias Peters wrote:
> > > Besides, the error messages popping up in the console interfere visually 
> > > with the text mode interface of the sound app that I use.
> > 
> > this is likely because irq is not handled correctly when framebuffer
> > is switched.  the framebuffer is a bad source of irq blocking.
> 
> Framebuffer cannot be responsible in this case because I compiled the 
> kernel without framebuffer support and I use plain 80x25 vga text screens. 
> 
> I do switch between 2 virtual consoles sometimes, but occurence of the 
> error messages is completely uncorrelated to this switching.
 
sure, the VT-switching is not only the source of lock irq blocking...

> The sound chip is most likely the one to blame. I just ask for a more 
> graceful handling in the driver when the interupt is 1 sample too late. 

try the cvs version.  it's less strict now.
(and note that it's a "debug" message, appearing only when you compile
with debug option.)


Takashi


-------------------------------------------------------
This SF.net email is sponsored by: The SF.net Donation Program.
Do you like what SourceForge.net is doing for the Open
Source Community?  Make a contribution, and help us add new
features and functionality. Click here: http://sourceforge.net/donate/

Re: hw_pointer error message triggered without need

[Jaroslav Kysela]

On Tue, 21 Oct 2003, Takashi Iwai wrote:

> > > well, it's not unnecessary but too strict.
> > > especially, if the hardware generates too late (often seen on onboard
> > > chips), and if only two periods are used, this situation can happen.
> > >
> > > i think delta < (runtime->period_size/2) would be enough to check the
> > > negative (invalid) hwptr rather than delta < (runtime->buffer_size/2)
> > > as it is.
> >
> > Nope. This check will be wrong because we will fall to the wrap point and
> > increase hw_ptr_base with buffer_size.
>
> the problem is that this check is too strict when only two periods are
> used.  since buffer_size/2 == period_size, if the update of hwptr is
> delayed even for one sample, it won't pass.
>
> there is a little difference between snd_pcm_update_hw_ptr() and
> snd_pcm_update_hw_ptr_interrupt(), and this problem doesn't happen in
> the former but only in the latter function, which is invoked by
> snd_pcm_lib_write1().
>
> in the former function, delta is the difference between the expected
> pointer (lastptr + period_size) and the current pointer.  meanwhile,
> in the latter function, delta is the difference between the last
> pointer and the new pointer.
> hence, the calculation of delta in the latter function can be easily
> less than buffer_size/2 when nperiods = 2.
>
> > Anyway, I think that we should leave the check as is for debugging
> > purposes (we should know that something is failing).
>
> sure, it's harmless message (as long as it comes from
> snd_pcm_update_hw_ptr()) but too annoying.  there are too many
> sloppy hardwares...

I've tried to reduce the debugging output for some conditions where
periods is a small value. In this case, it's really difficult to determine
which pointer is bad.

						Jaroslav

-----
Jaroslav Kysela <perex@suse.cz>
Linux Kernel Sound Maintainer
ALSA Project, SuSE Labs


-------------------------------------------------------
This SF.net email is sponsored by OSDN developer relations
Here's your chance to show off your extensive product knowledge
We want to know what you know. Tell us and you have a chance to win $100
http://www.zoomerang.com/survey.zgi?HRPT1X3RYQNC5V4MLNSV3E54

Re: hw_pointer error message triggered without need

[Takashi Iwai]

At Wed, 22 Oct 2003 12:58:53 +0200 (CEST),
Jaroslav wrote:
> 
> On Tue, 21 Oct 2003, Takashi Iwai wrote:
> 
> > > > well, it's not unnecessary but too strict.
> > > > especially, if the hardware generates too late (often seen on onboard
> > > > chips), and if only two periods are used, this situation can happen.
> > > >
> > > > i think delta < (runtime->period_size/2) would be enough to check the
> > > > negative (invalid) hwptr rather than delta < (runtime->buffer_size/2)
> > > > as it is.
> > >
> > > Nope. This check will be wrong because we will fall to the wrap point and
> > > increase hw_ptr_base with buffer_size.
> >
> > the problem is that this check is too strict when only two periods are
> > used.  since buffer_size/2 == period_size, if the update of hwptr is
> > delayed even for one sample, it won't pass.
> >
> > there is a little difference between snd_pcm_update_hw_ptr() and
> > snd_pcm_update_hw_ptr_interrupt(), and this problem doesn't happen in
> > the former but only in the latter function, which is invoked by
> > snd_pcm_lib_write1().
> >
> > in the former function, delta is the difference between the expected
> > pointer (lastptr + period_size) and the current pointer.  meanwhile,
> > in the latter function, delta is the difference between the last
> > pointer and the new pointer.
> > hence, the calculation of delta in the latter function can be easily
> > less than buffer_size/2 when nperiods = 2.
> >
> > > Anyway, I think that we should leave the check as is for debugging
> > > purposes (we should know that something is failing).
> >
> > sure, it's harmless message (as long as it comes from
> > snd_pcm_update_hw_ptr()) but too annoying.  there are too many
> > sloppy hardwares...
> 
> I've tried to reduce the debugging output for some conditions where
> periods is a small value. In this case, it's really difficult to determine
> which pointer is bad.

thanks, the code looks better than my hack.

yes, it's difficult to guess the wrap in the case nperiods <= 2.
we must trust that interrupts are enough fast not to bring the
critical delays.


Takashi


-------------------------------------------------------
This SF.net email is sponsored by OSDN developer relations
Here's your chance to show off your extensive product knowledge
We want to know what you know. Tell us and you have a chance to win $100
http://www.zoomerang.com/survey.zgi?HRPT1X3RYQNC5V4MLNSV3E54