4 ms·
Current OS's are fundamentally unsuitable for audiowork. macOS < Windows < Linux < other OS. None of them really do real-time processing. It's really bad, I wa
by adamnemecek 7y ago
Current OS's are fundamentally unsuitable for audiowork. macOS < Windows < Linux < other OS. None of them really do real-time processing.
It's really bad, I want a new OS where I can actually tell the scheduler what to do.
Also, check out this music composition app I'm launching soon http://ngrid.io http://ngrid.io.
- tfolbrecht 7y agoWhy is the realtime Linux patchset + Jack audio server insuffecient for what you do?
- adamnemecek 7y agoA patchset is not an OS. Like I can make it work for myself but good luck making it work for users.
- iainmerrick 7y agoI thought you wanted it for yourself, though? If you wanted something that lots of other people could use, in principle you could make your own Linux distribution with a particular set of patches.
- adamnemecek 7y agoYou can't expect people to use your os.
- osamagirl69 7y agoThe linuxCNC project[1] is a distribution based on the real time kernel extensions for debian for real time cnc machine control. It used to be possible to get few-us guaranteed latency, but with modern multicore machines you are stuck with about 100us due to the way the caching works. Still plenty fast enough for audio! [1] http://linuxcnc.org/ http://linuxcnc.org/
- tfolbrecht 7y agoGood point, I've been down that rabbit hole myself.
- jancsika 7y agoCarefully-worded question: If OP is describing a single monolithic music production application, how does "+ Jack audio server" make the system more appropriate for meeting soft-realtime scheduling deadlines?
- smallstepforman 7y agoYou may want to look into the "Media OS", aka BeOS and it's derivative Haiku. The Media Kit API is a monster, but it was specifically designed to allow fast transfer of buffers between nodes using kernel API's in order to achieve the best possible performance time guarantees. On 90's hardware their latency was/is lower than latency on all desktop oriented computer systems today on 20+ year newer hardware. Disclaimer - i'm working on a Haiku native media editor (video and audio) and the latency is excellent.
- TylerE 7y agoDefine “lower than”. I can achieve <4ms on Windows with decent ASIO drivers.
- slx26 7y agoI really admire the discipline of programmers that work seriously on real-time code... but indeed, at the end of the day, they all depend on the OS and everything else that might be running on it for the code to behave as real-time as expected. Sure, they can set the threads to high priority and all that, but... it's still not as good as one would like. And that's not even for hard real-time. On the other hand, I can't really expect regular OS's to implement a "real-time" mode or something like that. As much as I'd like it, I feel it would be so complex and fundamentally incompatible with the way those OS's work! (and then I also start thinking about power management, external factors affecting hardware, etc). I hope the future proves me wrong. Given how much people works on audio and plays videogames on those OS's, the current situation is kind of sad.
- RossBencina 7y agoI'm not sure you want to tell the scheduler what to do. Probably you just want a real-time scheduler that you can depend on for real-time work. One approach is to use a real-time kernel underneath Linux. Bela does this with the Xenomai kernel: https://github.com/BelaPlatform/Bela/wiki/What-is-Bela%3F https://github.com/BelaPlatform/Bela/wiki/What-is-Bela%3F
- throwaway40324 7y agoI just signed up. Is this a single dev (just you) project? Or, do you forsee hiring in the future?