[linux-audio-dev] lowlatency test at linuxdevices

Benno Senoner sbenno at gardena.net
Thu Sep 18 13:43:00 UTC 2003


Paul Davis wrote:

> I hope this is not true:
> 
> "Embedded systems often need to poll hardware or do other tasks on a
> fixed schedule. POSIX timers make it easy to arrange any task to get
> scheduled periodically. The clock that the timer uses can be set to
> tick at a rate a fine as one kilohertz, so that software engineers can
> control the scheduling of tasks with precision."

> The promise of the high-res timer patch was usec resolution, not msec.
> This would be a great loss. Does anybody know any more?

Yes unfortunately it is true what they say in the article.
The current timer resolution is 1msec (HZ = 1024, so to be precise
the resolution is (1/1024) sec).

In short the story is as follows: Linus accepted the
POSIX 1003.1b Section 14 (Clocks and Timers) API in kernel 2.6
but not yet it's implementation 
(patches available here http://high-res-timers.sourceforge.net/ ).

This means that applications using the POSIX 1003.1b timer API can
specify timing values nanosecond resolution but for now only 
msec resolution is provided.
But when the Linus & co will let in the kernel the high-res
 timer implementation, those apps will instantly be able to achieve
higher resolution without recompilation etc.

Yes usec resolution would be handy for some audio apps but I for
now I am happy of being able to achieve msec resolution in MIDI playback
without resorting to the RTC device which cannot easily be shared.


PS: in the article they talk about 4500usec worst case scheduling
latency (= 4.5msec), seems a bit disappointing.
 I'm curious what they mean with worst case,
 which kind of test suites they used etc.
2.4 + some LL patches let you reliably work with sub 3msec BTW.

Benno


-------------------------------------------------
This mail sent through http://www.gardena.net



More information about the Linux-audio-dev mailing list