11 Jul
2005
11 Jul
'05
10:17 p.m.
Anyone have a good suggestion for a tutorial for making accurate
high-resolution high-priority clocks in C? I found some tutorials but
they were kinda old, so wondered if they might be out of date as to how
far real-time scheduling has come on linux. I want to be able to wake up
a pthread very accurately.
Thanks
Iain
12 Jul
12 Jul
9:39 a.m.
Can you quantify how "high-resolution" you need, i.e. what accuracy?
The Linux kernel does not have support (yet) for resolution above
100Hz or 1000Hz, depending on your hardware platform.
There is some work going on into high resolution timers patches, but
integration of that is still far off I think.
--
Martin
---------------------------------------------------------------------------
30 years from now GNU/Linux will be as redundant a term as UNIX/MERT is
today. - Martin Habets
---------------------------------------------------------------------------
On Mon, Jul 11, 2005 at 05:15:37PM -0700, Iain Duncan wrote:
Anyone have a good suggestion for a tutorial for
making accurate
high-resolution high-priority clocks in C? I found some tutorials but
they were kinda old, so wondered if they might be out of date as to how
far real-time scheduling has come on linux. I want to be able to wake up
a pthread very accurately.
Thanks
Iain
1:02 p.m.
On Tue, 2005-07-12 at 12:19 +0100, Martin Habets wrote:
Can you quantify how "high-resolution" you
need, i.e. what accuracy?
The Linux kernel does not have support (yet) for resolution above
100Hz or 1000Hz, depending on your hardware platform.
There is some work going on into high resolution timers patches, but
integration of that is still far off I think.
There's actually an active LKML thread about this now, some people want
to regress HZ to 250. I'm of course violently opposed, but I seem to be
losing the argument. Please chime in if you care about this.
Lee
5:55 p.m.
>Can you quantify how "high-resolution"
you need, i.e. what accuracy?
>The Linux kernel does not have support (yet) for resolution above
>100Hz or 1000Hz, depending on your hardware platform.
>
>There is some work going on into high resolution timers patches, but
>integration of that is still far off I think.
That sounds like it would be useful for more than just audio, ie
robotics, any embedded linux apps, etc.
There's actually an active LKML thread about this
now, some people want
to regress HZ to 250. I'm of course violently opposed, but I seem to be
losing the argument. Please chime in if you care about this.
I would be happy to do so. I'm not familiar with LKML, how would you
suggest I do so? Is it appropriate to subscribe just to place my vote on
that issue?
Thanks
Iain
13 Jul
13 Jul
2:21 p.m.
Am Dienstag, 12. Juli 2005 21:53 schrieb Iain Duncan:
That sounds like it would be useful for more than just
audio, ie
robotics, any embedded linux apps, etc.
In realtime critical applications people prefer RTLinux or the RTAI extension
to the kernel for periods and scheduling latencies in the low microseconds
range (<30 microseconds worst case scheduling latency on recent x86
hardware).
Ralf
5:14 p.m.
In realtime critical applications people prefer
RTLinux or the RTAI extension
to the kernel for periods and scheduling latencies in the low microseconds
range (<30 microseconds worst case scheduling latency on recent x86
hardware).
I've often wondered about that. Why are those sorts of kernels
inappropriate for audio? ( Just out of curiousity. )
Thanks
Iain
5:22 p.m.
On Wed, 2005-07-13 at 12:12 -0700, Iain Duncan wrote:
what device drivers do you think they can run?
In realtime
critical applications people prefer RTLinux or the RTAI extension
to the kernel for periods and scheduling latencies in the low microseconds
range (<30 microseconds worst case scheduling latency on recent x86
hardware).
I've often wondered about that. Why are those sorts of kernels
inappropriate for audio? ( Just out of curiousity. ) 
8:29 p.m.
On Wed, Jul 13, 2005 at 03:22:42PM -0400, Paul Davis wrote:
On Wed, 2005-07-13 at 12:12 -0700, Iain Duncan wrote:
what device drivers do you
think they can run?
ALSA (or some other driver infrastructure and drivers) would have to be
ported to those environments. Or a new infrastructure and drivers for
sound cards would have to be written from scratch.
--
Eric Dantan Rzewnicki | Systems Administrator
Technical Operations Division | Radio Free Asia
2025 M Street, NW | Washington, DC 20036 | 202-530-4900
CONFIDENTIAL COMMUNICATION
This e-mail message is intended only for the use of the addressee and
may contain information that is privileged and confidential. Any
unauthorized dissemination, distribution, or copying is strictly
prohibited. If you receive this transmission in error, please contact
network(a)rfa.org.
In
realtime critical applications people prefer RTLinux or the RTAI extension
to the kernel for periods and scheduling latencies in the low microseconds
range (<30 microseconds worst case scheduling latency on recent x86
hardware).
I've often wondered about that. Why are those sorts of kernels
inappropriate for audio? ( Just out of curiousity. ) 
27 Sep
27 Sep
7:57 p.m.
Actually, we had a summer intern port an OSS driver for us for both RTLinuxPro and
RTLinuxFree as test project and connect it to a CD player. It was pretty simple.
I'll release both projects in the next couple of weeks.
On Wed, Jul 13, 2005 at 03:22:42PM -0400, Paul Davis wrote:
On Wed, 2005-07-13 at 12:12 -0700, Iain Duncan wrote:
what device drivers do you think they can run?
--
---------------------------------------------------------
Victor Yodaiken
Finite State Machine Labs: The RTLinux Company.
www.fsmlabs.com www.rtlinux.com
1+ 505 838 9109
In
realtime critical applications people prefer RTLinux or the RTAI extension
to the kernel for periods and scheduling latencies in the low microseconds
range (<30 microseconds worst case scheduling latency on recent x86
hardware).
I've often wondered about that. Why are those sorts of kernels
inappropriate for audio? ( Just out of curiousity. )
13 Jul
13 Jul
5:24 p.m.
On Wed, 2005-07-13 at 12:12 -0700, Iain Duncan wrote:
Too heavy. Those systems are designed for things like machine control
where the machine gets damaged if you miss a deadline. A few hundred
microseconds is good enough for audio, and it only has to be at least as
reliable as the rest of your gear.
Lee
In realtime
critical applications people prefer RTLinux or the RTAI extension
to the kernel for periods and scheduling latencies in the low microseconds
range (<30 microseconds worst case scheduling latency on recent x86
hardware).
I've often wondered about that. Why are those sorts of kernels
inappropriate for audio? ( Just out of curiousity. )
8:31 p.m.
Aha, thanks Lee and Paul, that explains that!
Iain.
Lee Revell wrote:
On Wed, 2005-07-13 at 12:12 -0700, Iain Duncan wrote:
Too heavy. Those systems are designed for things like machine control
where the machine gets damaged if you miss a deadline. A few hundred
microseconds is good enough for audio, and it only has to be at least as
reliable as the rest of your gear.
Lee
In
realtime critical applications people prefer RTLinux or the RTAI extension
to the kernel for periods and scheduling latencies in the low microseconds
range (<30 microseconds worst case scheduling latency on recent x86
hardware).
I've often wondered about that. Why are those sorts of kernels
inappropriate for audio? ( Just out of curiousity. )
6786
days inactive
6864
days old
linux-audio-dev@lists.linuxaudio.org
10 comments
7 participants
participants (7)
-
Eric Dantan Rzewnicki -
Iain Duncan -
Lee Revell -
Martin Habets -
Paul Davis -
Ralf Beck -
Victor Yodaiken