[linux-audio-dev] lowlatency test at linuxdevices

Michael Ost most at museresearch.com
Thu Sep 18 16:21:00 UTC 2003


An interesting historical sidenote on this came from of our programmers,
who was deep in the BeOS. He told me that their timeslice was 3 msecs
once everyone had 500 MHz machines. It was down to 1 msec for the never
released R6 version... back in, what 1999? 2000?

Open source is a bit slower to move, but at least it sticks around!

- mo

On Thu, 2003-09-18 at 10:27, Benno Senoner wrote:
> 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