Jack O'Quin wrote: > Eric Dantan Rzewnicki <eric@xxxxxxxxxx> writes: >>but, ecasound doesn't get SCHED_FIFO that way, no? >>(ecasound running w/pid 3764) >>eric@audiobox:~$ chrt -p 3764 >>pid 3764's current scheduling policy: SCHED_OTHER >>pid 3764's current scheduling priority: 0 >>or does ecasound's jack thread run inside jackd and not show up in ps >>output? > It runs inside of ecasound, but is not the main thread. It will > probably have an ID of 3766 or 3767 in your example. > The `ps' output is screwy for threads. Try something like... > $ ps -eo pid,tid,class,rtprio,ni,pri,comm | grep ecasound hmm ... odd. It doesn't show up in ps axf, or in the line you suggest. jack's various threads do, though. I'm wondering if ecasound is having the same problem creating sched_fifo threads that jack has when LD_ASSUME_KERNEL isn't set. anyway, ardour works with jack on my system, so I think this is something specific to my script or to ecasound. Ah ... I forgot to export LD_ASSUME_KERNEL in my script. Duh. now i see many ecasound threads: eric@audiobox:~$ for i in `seq 4824 4830`;do chrt -p $i;done pid 4824's current scheduling policy: SCHED_OTHER pid 4824's current scheduling priority: 0 pid 4825's current scheduling policy: SCHED_FIFO pid 4825's current scheduling priority: 90 pid 4826's current scheduling policy: SCHED_OTHER pid 4826's current scheduling priority: 0 pid 4827's current scheduling policy: SCHED_OTHER pid 4827's current scheduling priority: 0 pid 4828's current scheduling policy: SCHED_FIFO pid 4828's current scheduling priority: 50 pid 4829's current scheduling policy: SCHED_OTHER pid 4829's current scheduling priority: 0 pid 4830's current scheduling policy: SCHED_FIFO pid 4830's current scheduling priority: 89 But, there is still nasty noise coming from the analogueOsc plugin and (or?) ecasound's amplify and filter effects. I had similar noise in the past, but that was only when moving sliders to control effects. This noise is different ... keeps going when the parameters aren't being manipulated. I think it might be an ecasound issue rather than a kernel issue. I'll see if I can narrow that down tomorrow. Thanks for your help today, Eric Rz.
