>And as I mentioned a few times, the authors have neither the inclination
>nor the ability to do that, because they are not kernel hackers. The
>realtime LSM was written by users (not developers) of the kernel, to
>solve a specific real world problem. No one ever claimed it was the
>correct solut
>RT-LSM introduces architectural problems in the form of bogus API. And
that may be true of LSM, but not RT-LSM in particular. RT-LSM doesn't
introduce *any* API whatsoever - it simply allows software to call
various existing APIs (mostly from POSIX) and have them not fail as
result of not being r
>introduced. See devfs. And I think the adoption barrier thing is a red
>herring as well: the current users are by and large compiling their
>own RT-tuned kernels.
not true. most people are using kernels built for specialized distros
or addons, such as CCRMA, Demudi, Ubuntu, or dyne:bolic.
--p
-
[ the best solution is ]
[ my preferred solution is ... ]
[ it would be better if ... ]
[ this is a kludge and it should be done instead like ... ]
did nobody read what andrew wrote and what JOQ pointed out?
after weeks of debating this, no other conceptual solution emerged
that d
>that might be all well and good, but i believe you still dont understand
>my point: for yield_to() to work the target task _needs to be running_.
correct, i did not understand. perhaps Con didn't either. my idea was
related to:
>in theory it would be possible to add two new syscalls: sys_suspen
>(it would be cleaner to use POSIX semaphores for this, but you mentioned
>the requirement for the mechanism to work on 2.4 kernels too - pthread
>spinlocks will work inter-process on 2.4 too, and will schedule nicely.)
can't work. pthread interprocess spinlocks are hopelessly non-RT safe
in 2.4/l
>> yield_to(tid) should not be too hard to implement. Ingo? What do you
>> think?
>
>i dont really like it - it's really the wrong interface to use. Futexes
>are a much better locking/signalling interface. yield_to() would not be
i agree in principle, and i was suprised to see Con express this
tho
>This is a bit off topic, but I'm interested in applications that are
>more driven by time and has abstraction closer to that in a pure way.
>A lot of audio kits tend to be overly about DSP and not about time.
>This is difficult to explain, but what I'm referring to here is ideally
>the next genera
>As Ingo said in an earlier a post, with a little ingenuity this problem
>can be solved in user space. The programs in question can be setuid
>root so that they can set RT scheduling policy BUT have their
>permissions set so that they only executable by owner and group with the
>group set to a
>It's clever that they do that, but additional control is needed in the
>future. jackd isn't the most sophisticate media app on this planet (not
>too much of an insult :)) and the demands from this group is bound to
Actually, JACK probably is the most sophisticated media *framework* on
the planet,
>Yup, modern must be the key. Even Ingo can't help my little ole PIII/500
>with YMF-740C. Dang thing can't handle -p64 (alsa rejects that, causing
>jackd to become terminally upset), and it can't even handle 4 clients at
>SCHED_FIFO despite latest/greatest RT preempt kernel without xruns.
>
>B
>The idea is to get equivalent performance to SCHED_FIFO. The results
>show that much, and it is 100 times better than unprivileged
>SCHED_NORMAL. The fact that this is an unoptimised normal desktop
>environment means that the conclusion we _can_ draw is that SCHED_ISO is
>as good as SCHED_FIFO
>> "Jack" == Jack O'Quin <[EMAIL PROTECTED]> writes:
>
>
>Jack> Looks like we need to do another study to determine which
>Jack> filesystem works best for multi-track audio recording and
>Jack> playback. XFS looks promising, but only if they get the latency
>Jack> right. Any experience with t
>That's discouraging about reiserfs. Is it version 3 or 4? Earlier
>versions showed good realtime responsiveness for audio testers. It
>had a reputation for working much better at lower latency than ext3.
over on #ardour last week, we saw appalling performance from
reiserfs. a 120GB filesystem
14 matches
Mail list logo
