8 Apr
2005
8 Apr
'05
11:24 a.m.
Dear friends,
I am porting pxa audio driver to rtlinux (rtlinux
pro). I am mainly using pxa-ac97.c &
pxa-audio.c(eliminated sound_core.c). I will try to
register to two devices /dev/dsp and /dev/mixer in
that. Since RTlinux kernel api are not much documented
it seems very difficult to port dma and
synchronization.
Is it possible to use dma in rtlinux(since it needs
dynamic memory allocation).
I am sending the source code. can anybody tell me how
to port this.
Nobin Mathew
__________________________________
Do you Yahoo!?
Yahoo! Personals - Better first dates. More second dates.
http://personals.yahoo.com
8 Apr
8 Apr
3:37 p.m.
On Fri, 2005-04-08 at 06:24 -0700, nobin matthew wrote:
I am porting pxa audio driver to rtlinux (rtlinux
pro). I am mainly using pxa-ac97.c &
pxa-audio.c(eliminated sound_core.c). I will try to
register to two devices /dev/dsp and /dev/mixer in
that. Since RTlinux kernel api are not much documented
it seems very difficult to port dma and
synchronization.
Is it possible to use dma in rtlinux(since it needs
dynamic memory allocation).
I am sending the source code. can anybody tell me how
to port this.
Personally I think you're wasting your time. Ingo's RT preempt patches
let you do hard realtime with Linux using the existing driver base.
Good luck,
Lee
5:17 p.m.
On Fri, 2005-04-08 at 12:37, Lee Revell wrote:
On Fri, 2005-04-08 at 06:24 -0700, nobin matthew
wrote:
I'm not sure why he's trying to do this because for audio the latest
patched kernels appear to be more than adequate. That said, I don't
think you can get a guaranteed 15 microsecond interrupt response with
anyone's patches to the standard kernel. I wouldn't call what we have
now hard real-time. More like soft real-time. Maybe when MontaVista
gets done...
Jan
I am porting pxa audio driver to rtlinux
(rtlinux
pro). I am mainly using pxa-ac97.c &
pxa-audio.c(eliminated sound_core.c). I will try to
register to two devices /dev/dsp and /dev/mixer in
that. Since RTlinux kernel api are not much documented
it seems very difficult to port dma and
synchronization.
Is it possible to use dma in rtlinux(since it needs
dynamic memory allocation).
I am sending the source code. can anybody tell me how
to port this.
Personally I think you're wasting your time. Ingo's RT preempt patches
let you do hard realtime with Linux using the existing driver base.
5:30 p.m.
On Fri, 2005-04-08 at 09:24 -0500, Jan Depner wrote:
Hard realtime has nothing to do with how short the deadlines are, it's
about being able to *guarantee* that you can meet some deadline, IOW the
ability to guarantee that every code path in the kernel is
deterministic. And the RT preempt kernel absolutely can do hard
realtime, down to about 50 usecs (which is the length of time the timer
interrupt, the longest non preemptible path in the kernel, takes to
run).
Right now all the work that various people have done to enable hard
realtime on Linux is being ported to the RT preempt kernel. When
MontaVista and others get all their patches in we should be able to meet
even smaller RT constraints.
Lee
Personally I
think you're wasting your time. Ingo's RT preempt patches
let you do hard realtime with Linux using the existing driver base.
I'm not sure why he's trying to do this because for audio the latest
patched kernels appear to be more than adequate. That said, I don't
think you can get a guaranteed 15 microsecond interrupt response with
anyone's patches to the standard kernel. I wouldn't call what we have
now hard real-time. More like soft real-time. Maybe when MontaVista
gets done...
5:45 p.m.
On Fri, 2005-04-08 at 14:30, Lee Revell wrote:
On Fri, 2005-04-08 at 09:24 -0500, Jan Depner wrote:
Hard realtime has nothing to do with how short the deadlines are, it's
about being able to *guarantee* that you can meet some deadline, IOW the
ability to guarantee that every code path in the kernel is
deterministic. And the RT preempt kernel absolutely can do hard
realtime, down to about 50 usecs (which is the length of time the timer
interrupt, the longest non preemptible path in the kernel, takes to
run).
I do know what hard real-time is - I used to do hard real-time
airborne magnetics/navigation data acquisition systems. That's why I
said guaranteed. You can get 15 microsecond guaranteed out of RT-Linux
though (depending on the hardware of course). However, I'll believe 50
microseconds when I see it run for 30 days doing fairly high bandwidth
data acquisition. BTW, where did you see someone say that they were
guaranteeing 50 microsecond interrupt response? I'd like to read up on
that.
Personally I think you're wasting your time. Ingo's RT preempt patches
let you do hard realtime with Linux using the existing driver base.
I'm not sure why he's trying to do this because for audio the latest
patched kernels appear to be more than adequate. That said, I don't
think you can get a guaranteed 15 microsecond interrupt response with
anyone's patches to the standard kernel. I wouldn't call what we have
now hard real-time. More like soft real-time. Maybe when MontaVista
gets done... Right now all the work that various people have done
to enable hard
realtime on Linux is being ported to the RT preempt kernel. When
MontaVista and others get all their patches in we should be able to meet
even smaller RT constraints.
That's what I'm hoping for. I could probably live with 50
microseconds for most things but there are some systems that require
better.
Jan
6:06 p.m.
On Fri, 2005-04-08 at 09:52 -0500, Jan Depner wrote:
I do know what hard real-time is - I used to do
hard real-time
airborne magnetics/navigation data acquisition systems. That's why I
said guaranteed. You can get 15 microsecond guaranteed out of RT-Linux
though (depending on the hardware of course). However, I'll believe 50
microseconds when I see it run for 30 days doing fairly high bandwidth
data acquisition. BTW, where did you see someone say that they were
guaranteeing 50 microsecond interrupt response? I'd like to read up on
that.
Yup, 15 usecs is about the hardware limit, the difference is in the
non-preemptability of the timer ISR which runs for 30 usecs or so. At
one time this was preemptible with Ingo's patch, but had to be changed
back as it's not fully debugged.
There have been many, many LKML threads on it over the past few months.
This one has references to the determinism of the system:
http://article.gmane.org/gmane.linux.kernel/257329
Basically the RT preempt kernel achieves determinism by making every
code path in the kernel preemptible, except for a few like the scheduler
(and timer ISR, for now) that fundamentally can't be made preemptible,
and those few code paths can be analyzed to ensure that they execute in
constant time. This is achieved by turning all spinlocks into priority
inheriting mutexes.
It's still not considered ready for prime time, but this is definitely
the direction that hard RT on Linux is moving. It definitely appears
that this will obsolete RTLinux (and MontaVista Linux, eventually).
Lee
6:29 p.m.
Lee Revell <rlrevell(a)joe-job.com> writes:
Basically the RT preempt kernel achieves determinism
by making every
code path in the kernel preemptible, except for a few like the scheduler
(and timer ISR, for now) that fundamentally can't be made preemptible,
and those few code paths can be analyzed to ensure that they execute in
constant time. This is achieved by turning all spinlocks into priority
inheriting mutexes.
That's interesting, I didn't know that. So, it seems Ingo's patchset
really *is* hard-RT.
It's still not considered ready for prime time,
but this is definitely
the direction that hard RT on Linux is moving. It definitely appears
that this will obsolete RTLinux (and MontaVista Linux, eventually).
I'll be surprised to see full hard-RT integrated into the base kernel.
But, maybe as a Kconfig option some day.
Meanwhile, keep up the good work...
--
joq
6:49 p.m.
On Fri, 2005-04-08 at 15:33 -0500, Jack O'Quin wrote:
Lee Revell <rlrevell(a)joe-job.com> writes:
Yup, and the whole thing started with Paul's post to LKML last year to
the effect that "2.6 latency sucks".
Basically the RT preempt kernel achieves
determinism by making every
code path in the kernel preemptible, except for a few like the scheduler
(and timer ISR, for now) that fundamentally can't be made preemptible,
and those few code paths can be analyzed to ensure that they execute in
constant time. This is achieved by turning all spinlocks into priority
inheriting mutexes.
That's interesting, I didn't know that. So, it seems Ingo's patchset
really *is* hard-RT. I'll be surprised to see full hard-RT integrated
into the base kernel.
But, maybe as a Kconfig option some day.
Linus has not said much about it, but I think this is the plan.
Lee
5:47 p.m.
I'm not sure why he's trying to do this
because for audio the latest
patched kernels appear to be more than adequate. That said, I don't
think you can get a guaranteed 15 microsecond interrupt response with
anyone's patches to the standard kernel. I wouldn't call what we have
true, but the problem with RTLinux is that you can get that kind of
response there either if your app involves stuff that runs in the
normal Linux kernel controlled space. to get that response, everything
has to be done within the RT-part of RTLinux, which is *not* a
POSIX-like development environment, for the simple reason that it
offers normal Linux as well :)
victor and i have spoken on the phone a few times about this (we used
to debate a lot on rec.talk.politics back in the mid-90s, and had
similar life aspirations). i just don't see it happening for anything
except a dedicated flat-front-panel embedded system. and given
Receptor/Plugzilla, perhaps not even then.
--p
6:28 p.m.
On Fri, 2005-04-08 at 14:51, Paul Davis wrote:
Actually, I don't think that it's necessary for what we're doing. I
was strictly speaking of doing serious hard real-time with the RT-Linux
microkernel (or VXWorks if you've got the bucks).
Jan
I'm not
sure why he's trying to do this because for audio the latest
patched kernels appear to be more than adequate. That said, I don't
think you can get a guaranteed 15 microsecond interrupt response with
anyone's patches to the standard kernel. I wouldn't call what we have
true, but the problem with RTLinux is that you can get that kind of
response there either if your app involves stuff that runs in the
normal Linux kernel controlled space. to get that response, everything
has to be done within the RT-part of RTLinux, which is *not* a
POSIX-like development environment, for the simple reason that it
offers normal Linux as well :)
victor and i have spoken on the phone a few times about this (we used
to debate a lot on rec.talk.politics back in the mid-90s, and had
similar life aspirations). i just don't see it happening for anything
except a dedicated flat-front-panel embedded system. and given
Receptor/Plugzilla, perhaps not even then.
5:47 p.m.
Jan Depner <eviltwin69(a)cableone.net> writes:
On Fri, 2005-04-08 at 12:37, Lee Revell wrote:
> Personally I think you're wasting your time. Ingo's RT preempt patches
> let you do hard realtime with Linux using the existing driver base.
I'm not sure why he's trying to do this
because for audio the
latest patched kernels appear to be more than adequate. That said,
I don't think you can get a guaranteed 15 microsecond interrupt
response with anyone's patches to the standard kernel. I wouldn't
call what we have now hard real-time. More like soft real-time.
Maybe when MontaVista gets done...
Agreed.
The Linux kernel will always be "soft" realtime. They can never
*guarantee* specific interrupt response latencies, because too much
kernel code can come along later and mess it all up by disabling
interrupts or holding locks.
What many people overlook is that for most practical purposes, soft-RT
is what they really want. Hard-RT is only appropriate for a few
specialized imbedded systems.
Thanks to the hard work of Ingo, Lee and many other folks, recent
Linux kernels provide excellent soft-RT, right out of the box. With
Ingo's RT preempt patches, the results are world-class. There will
always be "two steps forward, one step back" regressions, but those
fixes keep getting migrated into the base kernel, and the general
trend is quite encouraging.
--
joq
6:32 p.m.
On Fri, 2005-04-08 at 14:50, Jack O'Quin wrote:
Jan Depner <eviltwin69(a)cableone.net> writes:
Please, don't think I was being disparaging. I am absolutely
thrilled with the kernel work that has been going on. This thing
rocks! The last I heard (from contractors working for us who were doing
soft real-time on - shudder - Windoze) M$ can only get you to about 30
milliseconds.
Jan
On Fri, 2005-04-08 at 12:37, Lee Revell wrote:
> Personally I think you're wasting your time. Ingo's RT preempt patches
> let you do hard realtime with Linux using the existing driver base.
I'm not sure why he's trying to do
this because for audio the
latest patched kernels appear to be more than adequate. That said,
I don't think you can get a guaranteed 15 microsecond interrupt
response with anyone's patches to the standard kernel. I wouldn't
call what we have now hard real-time. More like soft real-time.
Maybe when MontaVista gets done...
Agreed.
The Linux kernel will always be "soft" realtime. They can never
*guarantee* specific interrupt response latencies, because too much
kernel code can come along later and mess it all up by disabling
interrupts or holding locks.
What many people overlook is that for most practical purposes, soft-RT
is what they really want. Hard-RT is only appropriate for a few
specialized imbedded systems.
Thanks to the hard work of Ingo, Lee and many other folks, recent
Linux kernels provide excellent soft-RT, right out of the box. With
Ingo's RT preempt patches, the results are world-class. There will
always be "two steps forward, one step back" regressions, but those
fixes keep getting migrated into the base kernel, and the general
trend is quite encouraging.
6:47 p.m.
On Fri, 2005-04-08 at 10:39 -0500, Jan Depner wrote:
Please, don't think I was being disparaging.
I am absolutely
thrilled with the kernel work that has been going on. This thing
rocks! The last I heard (from contractors working for us who were doing
soft real-time on - shudder - Windoze) M$ can only get you to about 30
milliseconds.
I didn't think so, I was just pointing out that Linux is quite close to
being able to do hard RT OOTB. Many people don't realize it yet...
Anyway 30ms seems excessive... what kind of soft RT app was that? The
ASIO drivers I used to use go down to 2.6 ms, which doesn't work well, I
have to use ~5ms. But that requires tuning the system carefully.
As bad as that sounds now, until recently you could get 30ms dropouts on
a Linux system...
Lee
6:57 p.m.
On Fri, 2005-04-08 at 15:47, Lee Revell wrote:
On Fri, 2005-04-08 at 10:39 -0500, Jan Depner wrote:
IIRC part of it was servicing IRIG-B interrupts. The rest was just
serial port interrupts. It was a pretty simple thing otherwise they
would have had to use a hard real-time system of some sort. I tried to
get them to go with Linux but got shot down.
Jan
Please, don't think I was being
disparaging. I am absolutely
thrilled with the kernel work that has been going on. This thing
rocks! The last I heard (from contractors working for us who were doing
soft real-time on - shudder - Windoze) M$ can only get you to about 30
milliseconds.
I didn't think so, I was just pointing out that Linux is quite close to
being able to do hard RT OOTB. Many people don't realize it yet...
Anyway 30ms seems excessive... what kind of soft RT app was that? The
ASIO drivers I used to use go down to 2.6 ms, which doesn't work well, I
have to use ~5ms. But that requires tuning the system carefully.
7:24 p.m.
On Fri, Apr 08, 2005 at 11:04:29AM -0500, Jan Depner wrote:
IIRC part of it was servicing IRIG-B interrupts.
The easiest way to input IRIG-B is as an audio signal via a
soundcard, and use a software decoder. That was one my first
jobs when I joined Alcatel Space more than 10 years ago :-)
We are still using that code -- it takes less than 0.1% of
available CPU on today's systems, and provides sub-microsecond
accuracy.
--
FA
7:55 p.m.
On Fri, 2005-04-08 at 16:25, Fons Adriaensen wrote:
On Fri, Apr 08, 2005 at 11:04:29AM -0500, Jan Depner
wrote:
That's about the time frame that we started using them. Most
everything now is time tagged at the sensor so it's much less of a
problem than it used to be.
Jan
IIRC part of it was servicing IRIG-B interrupts.
The easiest way to input IRIG-B is as an audio signal via a
soundcard, and use a software decoder. That was one my first
jobs when I joined Alcatel Space more than 10 years ago :-)
We are still using that code -- it takes less than 0.1% of
available CPU on today's systems, and provides sub-microsecond
accuracy.
7228
days inactive
7228
days old
linux-audio-dev@lists.linuxaudio.org
15 comments
6 participants
participants (6)
-
Fons Adriaensen -
Jack O'Quin -
Jan Depner -
Lee Revell -
nobin matthew -
Paul Davis