Possible alsa-driver poll timeout bug

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

Possible alsa-driver poll timeout bug

Bastian Blankenburg
Hi,

I was searching for the source of the flood of jackd messages reading

delay of XXX usecs exceeds estimated spare time of YYY; restart ...

I get these messages when using jackd with my Edirol UA25 USB audio
device. As I understand, this happens when the polling of the ALSA audio
buffer takes too long?

Looking at the call of "poll" in drivers/alsa/alsa_driver.c, I saw that
it is called with a timeout given by driver->poll_timeout. This is
initialized with

driver->poll_timeout = (int) floor (1.5f * driver->period_usecs);

However the manpage of poll reads that the timeout shall be given in
milliseconds. Thus the above statement sets driver->poll_timeout to be
1500 times the period time. Shouldn't it really be

driver->poll_timeout = (int) floor (0.0015f * driver->period_usecs);

instead? I changed it to this value, then got a small number of

ALSA: poll time out, polled for XXX usecs

messages and still a big number of the above delay messages. At least
this told me that audio data in the alsa buffer was ready most times,
but the actual polling took too long. So the timeout in poll seems to be
ignored if data is available and only affect the case where no data is
available until the timeout?

Just for the record, I was finally able to solve the issue by fiddling
with PCI latencies. I used to set the USB IRQ to very high latency and
everything else to a small one. Setting the USB IRQ latency also to a
smaller value made it work. My guess is: not so much data is transferred
during one interrupt, and so the poll of the ALSA audio buffer returns
quicker. Is this correct?

Best,
Bastian



-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
Reply | Threaded
Open this post in threaded view
|

Re: Possible alsa-driver poll timeout bug

Lee Revell
On Tue, 2005-07-19 at 19:04 +0200, Bastian Blankenburg wrote:
> Hi,
>
> I was searching for the source of the flood of jackd messages reading
>
> delay of XXX usecs exceeds estimated spare time of YYY; restart ...

What kernel version?

Lee



-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
Reply | Threaded
Open this post in threaded view
|

Re: Possible alsa-driver poll timeout bug

Bastian Blankenburg
On Di, 2005-07-19 at 14:21 -0400, Lee Revell wrote:
> On Tue, 2005-07-19 at 19:04 +0200, Bastian Blankenburg wrote:
> > Hi,
> >
> > I was searching for the source of the flood of jackd messages reading
> >
> > delay of XXX usecs exceeds estimated spare time of YYY; restart ...
>
> What kernel version?
>

First I tried 2.6.12 with realtime-preemt patch V0.7.50-19, V0.7.50.43,
V0.7.51-16, V0.7.51-24 and V0.7.51-30, realtime preemt enabled and
hardware and software interrupt threaded. Using different combinations
of realtime priorities and renicing of the IRQ threads handling the USB
and RTC (with all others being lower priority) varied the interval and
number of the delay exceeding spare time messages. Also the different
versions of the realtime preemption patch gave varying results using
otherwise the same configuration.

I am now using the ck3 patch, for the staircase scheduler, to get more
deterministic results. xruns do not seem to be a problem with all these
patches, I see them only very rarely with 128 frames per period and 3
periods. However the delay messages never went away until I lowered the
pci bus latency setting for the USB. With this setting, running jackd
with -p64 -n3 causes a flood of ALSA poll timeout messages (with my
jackd patch described in the original post). Running with -p128 -n2
causes a lot of delay exceeding spare time messages again.



-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
Reply | Threaded
Open this post in threaded view
|

Re: Possible alsa-driver poll timeout bug

Lee Revell
On Wed, 2005-07-20 at 01:05 +0200, Bastian Blankenburg wrote:
> I am now using the ck3 patch, for the staircase scheduler, to get more
> deterministic results. xruns do not seem to be a problem with all these
> patches, I see them only very rarely with 128 frames per period and 3
> periods. However the delay messages never went away until I lowered the
> pci bus latency setting for the USB. With this setting, running jackd
> with -p64 -n3 causes a flood of ALSA poll timeout messages (with my
> jackd patch described in the original post). Running with -p128 -n2
> causes a lot of delay exceeding spare time messages again.

"delay exceeded estimated spare time" should really never happen, it
means that JACK got woken up late, but the ALSA layer did not detect the
problem.

This is almost always due to a driver bug.  Try reporting the problem to
the linux-usb-devel people.

Lee



-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
Reply | Threaded
Open this post in threaded view
|

Re: Possible alsa-driver poll timeout bug

Bastian Blankenburg
Am Dienstag, den 19.07.2005, 23:34 -0400 schrieb Lee Revell:

> "delay exceeded estimated spare time" should really never happen, it
> means that JACK got woken up late, but the ALSA layer did not detect the
> problem.

OK, but can you please tell me what the problem that ALSA should detect
actually is then? I'm not familiar with ALSA internals and interrupt
handling stuff. As far as I can see from the jack source, the consumed
time for the call of poll is measured and stored in delayed_usecs. This
is tested against engine->spare_usecs to decide whether to print out the
delay message or not. I don't see that it necessarily means that jack
woke up late, it is also possible that poll took too long.

> This is almost always due to a driver bug.  Try reporting the problem to
> the linux-usb-devel people.

Will do this once I understand the situation better.



-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
Reply | Threaded
Open this post in threaded view
|

Re: Possible alsa-driver poll timeout bug

Alfons Adriaensen
On Wed, Jul 20, 2005 at 12:55:26PM +0200, Bastian Blankenburg wrote:

> Am Dienstag, den 19.07.2005, 23:34 -0400 schrieb Lee Revell:
>
> > "delay exceeded estimated spare time" should really never happen, it
> > means that JACK got woken up late, but the ALSA layer did not detect the
> > problem.

> OK, but can you please tell me what the problem that ALSA should detect
> actually is then? I'm not familiar with ALSA internals and interrupt
> handling stuff. As far as I can see from the jack source, the consumed
> time for the call of poll is measured and stored in delayed_usecs. This
> is tested against engine->spare_usecs to decide whether to print out the
> delay message or not. I don't see that it necessarily means that jack
> woke up late, it is also possible that poll took too long.

That't the same thing really, since JACK waits on the poll().

With usb, it could be that there is no problem from ALSA's POV. IIRC,
ALSA requests to be woken up by the usb driver every four milliseconds.
This produces a jitter of up to 4 ms on the period wakeups as seen by
JACK (or any other ALSA client, but most couldn't care less). You can
easily verify this by printing out the error signal in JACK's DLL.

Now if your period is 5.333 ms (256 frames at 48 kHz), and a 4 ms jitter
range, you don't need much extra delay to fail the test.

The problem here is that JACK expects wakeups at regular intervals, and
the current usb driver is not capable of delivering these as a result
of the 4 ms granularity. For shorter period sizes (256 or less) ALSA
should really request an usb transfer per millisecond.
 
--
FA



-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
Reply | Threaded
Open this post in threaded view
|

Re: Possible alsa-driver poll timeout bug

Bastian Blankenburg
Am Mittwoch, den 20.07.2005, 13:50 +0200 schrieb Alfons Adriaensen:

> That't the same thing really, since JACK waits on the poll().

Hmm, I thought the wakeup time would be the time when
[alsa_]driver->nt_run_cycle is called, since that is what happens next
after ALSA signalled the driver thread, no? In this case it's not the
same, since poll() is called only after that. So you probably mean the
time when engine->run_cycle is called?

> With usb, it could be that there is no problem from ALSA's POV. IIRC,
> ALSA requests to be woken up by the usb driver every four milliseconds.
> This produces a jitter of up to 4 ms on the period wakeups as seen by
> JACK (or any other ALSA client, but most couldn't care less). You can
> easily verify this by printing out the error signal in JACK's DLL.
>
> Now if your period is 5.333 ms (256 frames at 48 kHz), and a 4 ms jitter
> range, you don't need much extra delay to fail the test.
>
> The problem here is that JACK expects wakeups at regular intervals, and
> the current usb driver is not capable of delivering these as a result
> of the 4 ms granularity. For shorter period sizes (256 or less) ALSA
> should really request an usb transfer per millisecond.

This cannot be true, as I am able to record with -p128 (< 2.7 ms input
latency) without glitches once I tuned IRQ latencies.



-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
Reply | Threaded
Open this post in threaded view
|

Re: Possible alsa-driver poll timeout bug

Alfons Adriaensen
On Wed, Jul 20, 2005 at 02:42:44PM +0200, Bastian Blankenburg wrote:

> This cannot be true, as I am able to record with -p128 (< 2.7 ms input
> latency) without glitches once I tuned IRQ latencies.

There's no contradiction, and it's easy to verify.

--
FA

 


-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel