Another newcomer here with some questions. On Karl's paper of latency measurements there was mentioned that the low- 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?
About the low-latency patches, does anyone know what the Hard Hat Linux dist 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). Also about sound cards and drivers, what low-cost sound card / chipset you 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? Last, could someone write a FAQ for this list. What is JACK?, where is it needed?, can I use JACK with ALSA API? etc. questions are still a little bit open to me. -Mikko Helin [EMAIL PROTECTED] Quoting Paul Davis <[EMAIL PROTECTED]>: > >After having read many of the threads going on here, it seems that a > 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 [EMAIL PROTECTED]
