Subject: Re: [linux-audio-dev] Lots about latency and disk i/o and JACK...
Another newcomer here with some questions.
On Karl's paper of latency measurements there was mentioned that the low-
About the low-latency patches, does anyone know what the Hard Hat Linux dist
Also about sound cards and drivers, what low-cost sound card / chipset you
Last, could someone write a FAQ for this list. What is JACK?, where is it
-Mikko Helin
Quoting Paul Davis <pbd_AT_Op.Net>:
> >After having read many of the threads going on here, it seems that a
-------------
This archive was generated by hypermail 2b28
: Wed Oct 03 2001 - 12:30:16 EEST
From: Mikko Helin (Mikko.Helin_AT_uta.fi)
Date: Wed Oct 03 2001 - 12:33:11 EEST
latency patches have actually little effect and the reasone for bad latency on
some systems is actually IDE. Could you actually tell as more about this,
should I get SCSI interface and systems for low-latency work? Also could you
explain why Windows system with IDE (with busmastering drivers/interface) and
ASIO drivers work well enough?
patches do? They seem to have some Open Source scheluder as well, and they are
big in embedded realtime systems anyway (suppose they know where they are
aiming at).
recommend for a beginner (don't want to put my EWS88MT to Linux PC yet)? I
think Paul some time ago gave credit to Trident chipset which seems to be
obsolete now. How about FM801 or CMI8738 chipsets?
needed?, can I use JACK with ALSA API? etc. questions are still a little bit
open to me.
helin_AT_uta.fi
> lot
> >of the problems we're facing with i/o latency and cached writes and the
> >like deal with the way the kernel handles the filesystem, and trying to
> >code around that might not be the best way in a free OS such as ours.
>
> we're not trying to code around it. thats a misunderstanding. the
> mechanisms are already there (though there are a few kernel patches
> that provide better ones; for example, the "doors" IPC mechanism is
> the lowest cost one around - it comes from Sun and is a GPL'ed patch
> for the kernel). the issue is how to marshall these mechanisms so that
> they can be used in a relatively easy way to do what we
> want. actually, even before that is the issue of "what do we want?",
> and after it also "and what does the API look like?"
>
> the reason Linux is attractive is that its a general purpose OS. its
> possible to design an OS purely for streaming media (BeOS heads off in
> this general direction, for example). if that was strictly necessary,
> we should do it. but its not - we can use the existing kernel
> mechanisms to do what we want (given the low latency patches and/or
> the preemptible kernel patch).
>
> >Linux and GNU always pride themselves on being modifiable by the people
> >who use them. So is it possible that, if we're having such a burden
> >coming up with decent algorithms
>
> we're not.
>
> > for working through these problems in
> >userland, maybe someone like Alan Cox or Linus Torvalds or their legion
> of
> >developers might be able to do something to the kernel itself that
> would
> >make things generally all-around easier for the whole audio developer
> >world?
>
> You assume that none of the people working on Linux audio are kernel
> hackers and that none of us have a history working on OS design ? :))
>
> --p
>
M. Helin
helin_AT_uta.fi