>
> What "hundreds of thousand of lines"? I think your problem is that
> you think that if you use RTLinux then you have to do everything inside
> RTLinux. That's not the case at all. You do the part that can't have
> jitter there but the data processing is all down under Linux as it
> is today.
ALSA is 140000 lines of code and almost all driver code,
and the effort of porting (although some stuff could be reused using macros)
and mantaining 2 sets of drivers (the RTLinux one and the standard one)
is not negligible.
I CCed Jarsoslav and Abramo the two ALSA procect leaders, let's hear
his opinions about the two APIs.
Of course the same concepts apply to the framebuffer , DRI, and video4linux
folks.
I am talking about pure driver code not applications.
And notice that many audio application are streaming applications but not
low-latency ones.
for example when listening to an mp3, who cares if the sound comes out
10msecs after you pressed play or after 2secs ?
no one, because there is no realtime constraint. (a CD player will usually
take too about 1sec to start the music)
So ask all developer of non-realtime multimedia software: are they willing
to use the RTLinux interface only because the RT-apps need it ?
Or do you plan do supply two APIs (the RT and the non-RT one) in parallel.
What does happen when you want to use the two APIs concurrently ?
It becomes very very complicated and tricky to deal with all these issues,
and IMHO not worth the trouble.
>
> It's true that I'm not an expert in this area so my I'm completely wrong,
> educate me. My understanding is pretty basic - there are input channels
> and output channels and these have to be sampled at a constant rate, with
> no delays, right? And the basic issue is that if we are doing disk I/O
> (or whatever) then the deadline is not met, right?
the best example is a complex , (eg physical modelling) realtime MIDI
software synth:
you press a key on a MIDI keybard and want to hear your cool physical-modelling
string simulation with a 5msec keypress-to-audio-output latency.
the synth code is a nasty piece of code involving complex math using the FPU,
and in some cases needing large amounts of memory (to store samples and other
stuff).
It's almost a complete application (an engine without the GUI), and although you
can run it within the kernel (gigasampler for windows does so) as a RTLinux
module, it's not nice, because buggy code (who reviews this synth if it is
shipped as binary-only ? ) , tends to make your box unstable.
One of the reasons why I use Linux IS stability.
Regarding disk-IO that's another issue: since the disk is not a realtime device,
you have to buffer data using shared mem (lock-free fifo) and let a
lower-priority disk-thread to all the disk IO.
This is a well understood technique when doing streaming of data (in general
not only for audio) from/to disk.
(hdrbench uses this approach for example)
>
> And since you are insisting that ypu do not want to run in kernel mode,
> then I can assume that most of the work happens in user space, but the
> sampling happens in the drivers, right?
the sampling is done in the drivers but that is the minor part.
for example a harddisk recorder with the ability to run plugin-chains
has to execute several "third-party" modules in realtime and often
these could come in a binary-only form (assume a commercial reverb plugin).
That means you have to run ALL the stuff under RTLinux or ALL in userspace.
>
> If that's not right then please tell me how it works. If that is more or
> less right, then it seems to me to be trivial to open up a pipe to a real
> time process which does the sampling and away you go.
That will not work: as soon as you pipe data out from your RTLinux module
to a standard linux process, you will face the 100ms latency problem during
heavy disk I/O thus ruining the effective latencies completely.
So in your model , the only thing you could do in userspace would be the
GUI (sliders,knobs, control widgets etc), the rest would require running
as RTLinux module.
>
> On the other hand, if you are doing all the work in the kernel or in the
> drivers, then the portability argument goes away because you have to port
> all that glop to Windows/whatever.
The protability isn't an issue here, the main issue is:
- make life easy for the developer:
no new API required, no system lockups
during debugging / running the app
>
> My guess is that it is close to what I think it is and that you don't realize
> that the point of the RTLinux APIs is to give you a small amount of code that
> does exactly what you want when you want it and then passes the results out to
> exactly the same user level processing you would use today.
>
> So educate me, tell me what I don't understand.
no you are wrong about the "small amount of code" thing:
multimedia apps usually do
while(1) {
read_input_from_multimedia_devices() (*)
process_data() (or get/put data from/to disk using interthread communication)
write_output_to_multimedia_devices() (*)
}
process_data is mostly pure math work (eg doing the IDCTs when decoding a mpeg
movie) which can be run under RTLinux as well.
But why run all this complex stuff within the kernel ?
(*) notice that there are cases where the above read() or write() part is
missing. (eg an mpeg video player has ony the write() part, a framegrabbing
app only the read() part)
>
> > - target audience : how many of the of the millions of linux desktops have
> > RTLinux installed
>
> This is the same crock of sh*t that MIS directors used against Linux
> itself: "How many machines from Compaq come with Linux installed?"
>
> Of course the standard distributions don't have it, there aren't apps that
> need it yet. But you get busy and make some whizzy apps that work flawlessly
> under RTLinux to give you great sound and video and watch how fast Red Hat
> ships with RTLinux. Using the "it isn't shipping yet" argument is wacko -
> the same can be said for every new idea. If we used your logic, nothing
> new could _ever_ happen.
I agree in part, but this is the usual chicken-egg problem and I see the
way of "RTLinux ships on joe-sixpack desktop" full of hurdles:
One possilibity would be Linus saying , "ok let's integrate the RTLinux
patch into the mainstream kernel", but (correct me if I'm wrong)
I guess RTLinux touches very low-level parts (IRQ code), thus
require all kernel developers to adapt to the new model.
And obviously then there would be some people saying
"no I don't want a microkernel running on my webserver" bla bla bla.
(same argument could be applied to low latency , since someone will
come out with a benchmark saying "the low-latency kernel runs this
benchmark 0.1% slower than a plain linux kernel" )
>
> > The frustrating thing is that Ingo's patch although ugly, can cover
> > ALL realtime multimedia needs NOW
>
> Really? So you've done the analysis and testing to show that this is true
> for "ALL realtime multimedia needs NOW"? You know what, I don't believe that.
> Show me.
What should I say: in my previous post I said RT-audio is the most demanding
kind of multimedia, and since it works ok on Ingo's kernel , other multimedia
kinds will work just as well.
( eg. you can do dropout free video recording at 25-50FPS from a video4linux
device using Ingo's kernel (assuming you use a 2 threads model for doing disk
IO communication))
ALL was meant as "all stuff which can currently be done on Windows & Mac"
So if you invent some killer virtual reality application with head mounted
display and sensors which react in 100usecs and other sophisticaed stuff
then it's another story.
>
> > - too restrictive : problems with large memory needs,
> > working in kernelspace (do we really want to run COMPLEX apps within the
> > kernel space (a physical modelling synth) ? ,
>
> No, you don't, and nobody is telling you to do so. Just gather the data
> you need in the RT part and send it out to Linux just as you do today.
already answered, see above.
>
> [other complaints about young technology deleted]
>
> > So why should I use RTLinux which can do 20-50usec when 99.99% of cases can be
> > covered using and userspace app running SCHED_FIFO / mlock() because most
> > apps do not need <5msec latencies.
>
> Because RTLinux can give you what you need.
>
> Because it doesn't require you to hack up the kernel.
see it the other way: linux running on a 800MHz CPU and the kernel still
stalls your app for 100msecs sometime.
During that time the CPU can execute 40-80millions of instructions.
It is ridiculous that the OS is unable to give the CPU to our process
during that time.
>
> Because it is far more scalable and reliable.
yes , but it is overkill for us.
And the cost of using RTLinux (see all my bla bla) is not negligible.
>
> Because your approach is the same tired bag of mistakes that helped make
> other operating systems piles of sh*t.
read this:
http://www.mvista.com/white/leverage.html
I fully support their view, and I and many others which have actually played
around (by writing and using multimedia stuff) agree that it is the best way to
go.
Benno.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/