> > You should investigate the problem more deeply before saying
> > "we do not want to port our code" ..
> >
> > Do you really think that the multimedia driver folks are willing to port
> > hundreds of thousand of lines to the RTLinux model and then mantain 2 sets of
> > APIs to satisfy the realtime multimedia folks ?
>
> 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.
You've been mostly on the mark (IMHO) about needless preemption and it's
evils. But here, you are missing something: The current linux system has
worstcase latency of 100+ms. This is insufficent for even the highest
levels of control in these audio applications.
The design of RTlinux is execlent for small portions of realtime code, the
type of stuff that you can prove is mathmatically correct. :) These audio
applications are nothing like this, hugh chanins of mathmatical filters,
with multiple inputs (some realtime, some disk based, etc).. This isn't a
magnetic berring, you can't simply decompose this stuff.
The fact is that 100ms worst case is unreasonable on modern hardware even
without any preemption.
If Linux could achieve worst case latencys on the order of 15-25ms (which
I believe should be possible without stupid preemption tricks
(i.e. fixing no optimal algorithms), then perhaps people could cope better
with implimenting the really hard stuff w/ RTlinux.
The second part is that as far as the audio people can tell, there is no
hope in sight for intergrating RTlinux nor for any distros. (Esp with
patent concerns, since there is no legally binding assurance that the
RTlinux patents will be free for GPLed things in perpetuaity), so they
made a reasonable guess that they might have some luck getting in Ingos
patches.
> 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?
>
> 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 not the hard part. Current Linux systems have no problem
responding to these interupt driven events.
> 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.
Then you need to do extensive processing on the input, perhaps store it on
disk, retreve related samples from disks, pass it through several layers
of modular software filters and spit the whole result back out the sound
driver... All within a few MS.
In order to meet the requirements, the entire set of software would need
to be implimented in RTlinux with the only exception being the user
interface. This is not made easy by the fact the the RTlinux.org site has
no examples of that level of complexity.
Perhaps it isn't unreasonable to impliment all the modular filters in
RTlinux, however, some signifacant work will be required to make such a
move acceptiable to the audio people.
> 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.
>
> 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.
[snip]
The problem is that this audio stuff isn't some stupid lab data capture
enviroment (which it seems is almost the entire userbase of
RTlinux).. They will require the bulk of their hard code to be written as
RT processes if they use RTlinux, and RTlinux stuff *IS* harder to
write/debug. While many of these coders are very talented, many more of
them are more intrested in their music and dealing with the fairly complex
locking potentials in hard realtime code is beyond the point that makes
coding fun.
-
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/