>> >k_jack performs okey. You dont have to run things with realtime priority. >> >> this is a joke, right? you **cannot** get reliably low latency >> performance on a linux system without SCHED_FIFO or SCHED_RR. i don't >> care how you write it, it just won't work. >> >Perhaps we have a different opinion about what is reliable performance >then. I dont care if I hear a click or a pop every second hour.
if you run an audio application and then a 4-way compile, or "locate" or even just startup a big application or drag a big window around the screen, then without SCHED_FIFO you will get dropouts every few seconds on any typical system. or have you found a way to avoid this? >> i find this all very upsetting. you write what appears from its name >> to be some kind of IPC library. you decide to test it out. instead of >> coming to jackit-devel and saying "i have this cool new library for >> IPC. what do you think about using this to fix some problems with >> JACK?", > >Oh sorry, I dont beleive the problem is with jacks IPC implementation >(that would be quite unlikely I imagine), but rather the alsa driver. Hmm, >guess I could be wrong, though. so wait. its not clear what you've done. did you rewrite the ALSA layer? >But, its fine for running freqtweak within pd, using 64 frames >code blocks, as a normal user. I'm not even near the ability >to that with jack. well, thats definitely a great reason to look at what you've done, but i'd find it much easier if you could describe what you've done. i've got a zillion things to do and reading a paragraph of descriptive text is a lot easier than trying to grasp a new approach from the source. --p
