Chris Turner wrote:
With the smaller buffering / stricter monitoring requirements, scheduling deadlines become more of an issue as dropouts start to occur, which is also possibly 'less acceptable' in the 'professional' case (this is very use-case-dependent), and things may or may not be compounded by heavy data processing, etc.
undetected dropouts in a pro audio environment are not acceptable. you don't want lose a single sample when you record audio and at least you want to know if dropouts occur.
From the research / discussions on the LAD list, it seems like the 'consumer' OS's (Windows, MacOS "classic", OS-X) have some kind of special scheduler hooks or API's for these kinds of scenarios (DirectSound, CoreAudio, etc) and that this is a 'hard problem' (TM)
It is a hard problem (thats my impression from reading the Linux audio mailing lists). If I were a musician or pro audio user, I would buy an Apple only for CoreAudio, although Linux is now a much better audio platform than it was some years ago.
If you want to run pro audio software (on BSD) you want to run a jack server. Has anyone tried to port jackd or jackdmp to Dragonfly? Is there any chance that it can run low-latency (64 samples / 48khz = 1.3 ms)?
