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

Jack O'Quin wrote:
> Eric Dantan Rzewnicki <eric@email-addr-hidden> writes:
>>but, ecasound doesn't get SCHED_FIFO that way, no?
>>(ecasound running w/pid 3764)
>>eric@email-addr-hidden:~$ 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@email-addr-hidden:~$ 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.
Received on Mon Jan 17 04:15:22 2005