24 Jul
2003
24 Jul
'03
11:33 a.m.
All,
I haven't used kernel 2.5/2.6 for any audio stuff yet. I'm at the Linux
Symposium this week - do we have any requests or gripes with 2.6 that I can
relay to the core kernel guys? Audio is a workload they don't really test.
Tim
24 Jul
24 Jul
12:18 p.m.
On Thu, Jul 24, 2003 at 06:03:33AM -0700, Tim Hockin wrote:
I haven't used kernel 2.5/2.6 for any audio stuff
yet. I'm at the Linux
Symposium this week - do we have any requests or gripes with 2.6 that I can
relay to the core kernel guys? Audio is a workload they don't really test.
I'm not an expert at all, but I guess with the pre-empt patches in and
Andrew Morton's low latency patches, we are ok in the latency
department ?
We should (*should* cause we didn't test it yet) be ok wrt. latency, as
I hope that there are no more long held locks and most of the big kernel
lock is gone.
Any other things we can come up with ?
v
2:59 p.m.
Is there SCHED_FIFO style priority available in the new kernel, with its
new threading model? Realtime audio processing doesn't share the CPU
very well. The ear can pick out even the slightest glitches or delays.
So for Linux to be usable for audio applications or embedded audio
devices it needs something like SCHED_FIFO.
On Thu, 2003-07-24 at 06:03, Tim Hockin wrote:
All,
I haven't used kernel 2.5/2.6 for any audio stuff yet. I'm at the Linux
Symposium this week - do we have any requests or gripes with 2.6 that I can
relay to the core kernel guys? Audio is a workload they don't really test.
Tim
3:09 p.m.
On Jueves, 24 de Julio de 2003 17:46, Michael Ost wrote:
Is there SCHED_FIFO style priority available in the
new kernel, with its
new threading model? Realtime audio processing doesn't share the CPU
very well. The ear can pick out even the slightest glitches or delays.
So for Linux to be usable for audio applications or embedded audio
devices it needs something like SCHED_FIFO.
On Thu, 2003-07-24 at 06:03, Tim Hockin wrote:
> All,
>
> I haven't used kernel 2.5/2.6 for any audio stuff yet. I'm at the Linux
> Symposium this week - do we have any requests or gripes with 2.6 that I
> can relay to the core kernel guys? Audio is a workload they don't really
> test.
>
> Tim
Hi!
p9:/home/holborn/gmorgan/src# uname -a
Linux p9 2.6.0-test1 #5 mié jul 23 10:40:31 BST 2003 i686 GNU/Linux
p9:/home/holborn/gmorgan/src# ./gmorgan -l MisStyles.gms -b MisProgs.gmo -r
MisPat.gmp
gmorgan v0.07 - Copyright (c) 2003 Josep Andreu (Holborn)
SCHED_FIFO
SCHED_FIFO
p9:/# ps wlaxO+y
F UID PID PPID PRI NI VSZ RSS WCHAN STAT TTY TIME COMMAND
4 0 9375 5689 -51 0 31884 31880 schedu SL pts/1 0:01 ./gmorgan
-l MisStyles.gms -b MisProgs.gmo -r MisPat.gmp
5 0 9377 9376 -51 0 31884 31880 snd_se SL pts/1 0:00 ./gmorgan
-l MisStyles.gms -b MisProgs.gmo -r MisPat.gmp
Here runs .... i think :) debian sid.
Josep
25 Jul
25 Jul
7:38 a.m.
On Thursday 24 July 2003 13:46, Michael Ost wrote:
Is there SCHED_FIFO style priority available in the
new kernel, with its
new threading model? Realtime audio processing doesn't share the CPU
very well. The ear can pick out even the slightest glitches or delays.
So for Linux to be usable for audio applications or embedded audio
devices it needs something like SCHED_FIFO.
It is a posix standard, so it is unlikely to go away :)
Juan Linietsky
1:25 p.m.
On Thursday 24 July 2003 13:46, Michael Ost wrote:
It is optional and 95% of the applications don't need it. It is doomed :)
--ms
Is there SCHED_FIFO style priority available in
the new kernel, with its
new threading model? Realtime audio processing doesn't share the CPU
very well. The ear can pick out even the slightest glitches or delays.
So for Linux to be usable for audio applications or embedded audio
devices it needs something like SCHED_FIFO.
It is a posix standard, so it is unlikely to go away :)
7787
days inactive
7788
days old
linux-audio-dev@lists.linuxaudio.org
5 comments
6 participants
participants (6)
-
holborn -
Juan Linietsky -
Martijn Sipkema -
Michael Ost -
Tim Hockin -
Vincent Touquet