[linux-audio-user] realtime-preempt-2.6.11-rc1-V0.7.35-01

[Eric Dantan Rzewnicki]

Jack O'Quin wrote:
> Eric Dantan Rzewnicki <eric at zhevny.com> writes:
>>but, ecasound doesn't get SCHED_FIFO that way, no?
>>(ecasound running w/pid 3764)
>>eric at 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 at 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.