> I suspect you are right. I'd also like to note that this is ground so
> thoroughly trodden that the grass is flat. Realtime schedulers are a well
> researched topic, it's just too bad that committees don't design them as well
> as engineers would.
>
> Thinking strictly about the needs of sound processing, what's needed is a
> guarantee of so much cpu time each time the timer fires, and a user limit to
> prevent cpu hogging. It's worth pondering the difference between that and
> rate-of-forward-progress. I suspect some simple improvements to the current
> scheduler can be made to do the job, and at the same time, avoid the
> priorty-based starvation issue that seems to have been practically mandated
> by POSIX.
I've been finally able to make my sound card to sing with 2.5 and I was
able to sh*t load my machine running RealPlay with the SOFTRR path :
http://www.xmailserver.org/linux-patches/softrr.html
I was not able to get a single skip. For many kind of applications it is
not strong real time that is needed. For example, in case on those
multimedia pps, I saw that they can live pretty happy with 10-20ms
latencies. The problem is that w/out living in the realtime priority even,
they can be sucked in by interactive tasks running they loong timeslice
multiple times. Plus-latencies of 100-150ms are very easy to get. Even if
the average latency, like graphs show, is very close to the expected one.
- Davide
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/