Subject: Re: [linux-audio-dev] lowish-latency patch and toolchain
From: yodaiken_AT_fsmlabs.com
Date: Tue Jul 11 2000 - 14:27:27 EEST
On Tue, Jul 11, 2000 at 12:30:30PM +0300, Juhana Sadeharju wrote:
> Sorry, I wasn't talking about 2.4 or any else version. This is just
> a problem which should be solved because nobody goes to RTLinux.
Ladies and Gentlemen:
I'm not begging for RTLinux users, we have many already, however, I do
want to point out to you that if you need reliable worst case timing,
you need a RTOS and Linux is not that.
More and more technologies depend on hard realtime, but
it is very difficult to work in the hard realtime paradigm -- especially
because we are so used to "get more memory and a faster processor" and
letting the OS mask resource conflicts.
> I'm waiting not only for the low-latency patch, but also for prioriticed
> disks (filesystem?) so that audio/video application gets quaranteed bandwidth,
> and also soft-RT support to XFree so that signal level meters and key
> presses, for example, can get higher priority than any other X operation.
One problem with "soft realtime" is
that is is very easy to embed contradictory demands in soft
realtime. What's irritating about programming in a hard realtime environment
is that it forces you to clearly define what you can and cannot wait for and
what system timing must be. So, in RTLinux, if you request that a thread
be run ever 50 microseconds, you get it, if your thread takes 100 microseconds
to complete, your program will either crash the system or be aborted dependig
on how you setup debug. But "soft realtime" allows one to make vague
requirements like
prioritized disk
audio/video gets guaranteed bancwidth
signal meters get higher priority
keypress gets higher priority
If this is to mean anything at all, you have to add up times and
see if it can work. When does X get to do housecleaning? What happens
if the "prioritized disk" needs time at the same moment that the user
presses a key? What happens when the paging mechanism needs to free
pages while the audio/video get guaranteed bandwidth?
A pile of local optimizations may easily lead to global pessimization.
> Since putting simple if's to the extra scheduling points is simply not
> a good idea, would it give an opportunity to make larger parts of the
> kernel changeable: a kernel section specially designed for audio/video
> use.
What you need to define first is what your actual
timing needs are and then you look for a method to get them.
-- --------------------------------------------------------- Victor Yodaiken FSMLabs: www.fsmlabs.com www.rtlinux.com FSMLabs is a servicemark and a service of VJY Associates L.L.C, New Mexico.
This archive was generated by hypermail 2b28 : Tue Jul 11 2000 - 14:59:21 EEST