Messages in this thread | | | From | Juhana Sadeharju <> | Subject | Re: [alsa-devel] Re: preempting I/O (audio latency + making X more responsive) | Date | Fri, 20 Aug 1999 16:26:26 +0300 |
| |
>From: Benno Senoner <sbenno@gardena.net> > >Mingo demonstrated that it's possible to achieve <4.3ms audio latency on a PII >box, on high disk I/O load. >( Will post soon nice large GIFs on my page to show the exciting results)
A source code would be a good one because it saves time even we choose a slightly different way to implement it. My plan was to give disk process higher priority so that disk process is always suspended by read(), write() or by waiting new tasks. What do you think how this differs from your suggestion?
>Therefore IMHO the best solution is to have some disk I/O thread which >does the I/O for the audio thread using large buffers.
But loading large buffers blocks the disk usage from other audio streams? What about making the large buffers fragmented so that fragments of different buffers are interleaved in loading/writing? Using small buffers might increase the load of the audio engine and thus fragmented large buffers might be a good compromise.
>With the 2 threads method, the only concern is I/O bandwidth, the latency >problems are solved by the large buffers.
I think that is a bit incorrect. I suspect large buffers blocks the system from reading multiple files simultaneously. Latency is increased by preloading the audio. Preloading is possible if we have a sequence data or an editlist, but if we get a MIDI note, then preloading is not possible unless we preload a bit about every possible audiofile the MIDI instrument might use. If we allow MIDI instruments to use audiofiles on disk, we should use the same latency in any audiofile instruments -- and more, in any instrument even if they don't use disk -- so that we don't get jitter between instruments. This sequencing latency naturally lessens the performance requirements, I guess.
>You should always use mlockall() for realtime processes.
I see a slight misunderstanding here and there. I mean, if some non-audio software starts to swap or to read disk, then it might block the RT audio disk readings/writings. I cannot lock those third party processes but the kernel could freeze their disk usage if my RT audio software wants to use disk. Prioriticing disk usage and making it preemptive would help. But can a DMA transfer be interrupted? Kernel would stop the current disk read (by non-RT process) and give the DMA to RT process.
The disk and the audio RT process would sleep when they wait data and at that time, could any other process start some large disk reading. That disk reading should be interrupted as soon as possible.
>It would be nice to hear some comments from the XFree86 people.
I would like to hear them too, please.
Yours,
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/
| |