Messages in this thread | | | From | Juhana Sadeharju <> | Subject | Re: [linux-audio-dev] lowish-latency patch and toolchain | Date | Sat, 8 Jul 2000 23:33:26 +0300 |
| |
>From: "Khimenko Victor" <khim@sch57.msk.ru> >>>doing silly things, the scheduling latency is reliably 4 milliseconds on >>>a 500MHz machine. Very occasionally reaches 7 millisecs. It has been > >> Lets talk about 7 ms latency only -- 4 ms is useless information in audio >> software which has to be 101% reliable. > >Sorry. It was said 1000 times already but I can repeat once more just for you: >101% reliability => HARD real time => RTLinux. Period. If you NEED 101%
Forget that 101%. The most above quote tells me that scheduling latency is practically reliable with 10 ms latency (while taking account those not-to-do's). If only 7 ms peaks are observed, it looks 101% reliable to me.
It would be very silly to talk that Linux would have 1 ms latency if it reaches it only once a week. Get the point? Lets not talk about 4 ms latency but 7 ms from practical point.
Development point is that 4 ms is reached at most of the time and somehow we should get those 7 ms occasional latencies away. Remember, this was the situation before Ingo's patch, and I'm sure we reach the reliable 4 ms latency.
>> That is poor compared to earlier results 2.5 ms. > >It can be expected. There NO WAY IN HELL to include Ingo's original patch >in kernel, so stop talking about it already. It REALLY starting to look like
I was not suggesting that. We should look at a possible good way to solve this problem. I'm not happy with 4 ms audio-I/O latency, but it could be reached. I'm willing to dig in to this mess just in case more people means more suggestions, at least in this case.
>-- cut -- >My guess is you'll be digging yourself in deeper and deeper, >sprinkling random hacks in random places, as Linus put it. >-- cut --
My own audio code design is a far from a hack. Everything is very well organized, well thought. I would like to see if I'm able to say my opinion in kernel's low-latency matters from non-hacker's point of view.
>Huh ? What's "the most important points of how kernel works" ???
How about telling what are those 6 points where the patch additionally schedules? A good start. You don't need to give me a full lecture.
>Basically Ingo added extra scheduling everywhere where it looked right >on first glance without deep investigation - with just few benchmarks >(AFAIK anyway).
Yep. I would like to see more scientific analysis, and would like to help on that.
>Since there are MUCH less pre-emption points.
Were they choosed the same way than Ingo choosed his points? Empirically based on a program analyser whatever...? If yes, we at least have a way to improve if this patch is ignored as well.
Yes, I think Ingo's patch is kludge, and wonder if this new one is another kludge.
>I'm not sure if it's possible for Linux kernel at all (it's really easy >do draw principal diagram of dataflow in linux but what it'll buy you?
Hey, I just wanted a short cut for understanding the issues related to low-latency audio, not the full lecture on kernel design.
Juhana
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |