[Jackit-devel] Re: [PD-announce] Re: [linux-audio-dev] ANN: k_jack v0.0.0.5 and Mammut v0.15

[Paul Davis]

>> >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