[LAU] Concerning schedtool

[Jeremy Jongepier]

On 04/19/2014 05:58 AM, Jonathan E Brickman wrote:
> I gave it a royal tryout just now.  Below is sound-patch startup code, it's actually a mashup of most of my START-INITIAL script which runs at boot, and the first patch script which it calls.  When I keep the schedtool prefixes, MIDI keyhits all make it in and synths all get their signal out through the sound card output.  When I don't, about one in 20-30 keyhits (and also occasionally key-ups) get lost, and there are cutouts both at high load and very low loads.  Some may notice I have let the latency rise to 4; this too seems to be indicated for the loads I'm using, though if I were using just one light load (say, a simple Yoshimi patch), it could be ratcheted down a lot.  Oddly, it does appear that a different patch which calls just Fluidsynth, functions as a heavier load than three Yoshimis; it is true that Fluidsynth is itself using a rather big four-voiced soundfont.  I have another which right now is two Yoshimis plus the same Fluidsynth an octave lower (octave handled by mid
idings), that one is higher yet, but the setup and weights below are handling it well.
> 
> The relative weights are definitely guesses based on behavior. I just increase the weight of anything which misbehaves, until it makes it worse, then reverse :-)  I did find earlier tonight that I had neglected my limits.conf, so this is what I have set now, which allows those numbers below to actually work:
> 
> @audio          -       rtprio          95
> @audio          -       nice           -19
> @audio          -       memlock         512000
> 
> I'm not sure the nice is at all needed, but it doesn't seem to be harming anything.

Hello Jonathan,

It's not needed in a Linux audio context:
http://jackaudio.org/linux_rt_config

> 
> J.E.B.
> 
> ------
> 
> jack_control start
> 
> jack_control ds dummy
> jack_control dps capture 0
> jack_control dps playback 0
> jack_control dps rate 48000
> jack_control dps period 64
> jack_control eps realtime true
> jack_control eps realtime-priority 50

Why 50? Personally I'd set it to the highest possible value.

> jack_control eps clock-source 1
> 
> # Stop any running audio elements
> echo "Stop any running audio elements..."
> killall -9 -w yoshimi fluidsynth zita-j2a aj-snapshot calfjackhost non-mixer rakarrack mididings lashd
> killall -9 -w yoshimi fluidsynth zita-j2a aj-snapshot calfjackhost non-mixer rakarrack mididings lashd
> 

My 2 cents while not being a Bash expert (so shoot me if I do things
horribly wrong here):
---
apps=( yoshimi fluidsynth zita-j2a aj-snapshot calfjackhost non-mixer
rakarrack mididings lashd )

for a in "${apps[@]}"
do
  while pidof $a
  do
    killall -9 -w $a
  done
done
---
Like this you're sure the processes get killed and you don't need to add
double killall commands.

> # Remove all connections
> echo "Stopping a2j..."
> a2j_control stop
> echo "Stopping Jackd to remove all connections..."
> killall -9 -w jackdbus
> killall -9 -w jackdbus
---
while pidof jackdbus
  do
    killall -9 -w jackdbus
done
---
> jack_control stop
> echo "Starting Jackd..."
> jack_control start
> sleep 2
> 
> # Running a2j -- needful to use ALSA MIDI devices with
> # zita-a2j, which uses the 'dummy' driver in Jack
> echo "Starting a2jmidid..."
> a2j_control ehw
> a2j_control start
> 

Why not use Jack2's built-in alsarawmidi driver?

> # Start zita-j2a for audio out
> echo "Starting Zita..."
> nohup schedtool -R -p 80 -e zita-j2a -d hw:SB -r 48000 -p 64  &
> 
> # Start all relevant audio elements
> echo "Start all relevant audio elements..."
> nohup schedtool -R -p 75 -e mididings -f /home/jeb/Combine.py     \
>     > /home/jeb/LOGS/Combine.log &
> nohup schedtool -R -p 50 -e calfjackhost --client CalfSRO     \
>     eq12:SRO ! reverb:SRO ! Compressor:SRO             \
>     > /home/jeb/LOGS/calfjackhost-SRO.log &
> nohup schedtool -R -p 50 -e yoshimi -N YoshSRO1 -j \
>     -l /home/jeb/YOSHIMI/SROpart1.xmz  > /home/jeb/LOGS/Yoshimi-SRO1.log &
> nohup schedtool -R -p 50 -e yoshimi -N YoshSRO2 -j \
>     -l /home/jeb/YOSHIMI/SROpart2.xmz  > /home/jeb/LOGS/Yoshimi-SRO2.log &
> nohup schedtool -R -p 50 -e yoshimi -N YoshSRO3 -j \
>     -l /home/jeb/YOSHIMI/SROpart3.xmz  > /home/jeb/LOGS/Yoshimi-SRO3.log &
> sleep 2
> 

Why are you running all Yoshimi processes and the main JACK thread with
the same rtprio? Don't they get in each other way then? Or does that
only apply to SCHED_FIFO?

> # And lastly, create jackd connections using aj-snapshot
> echo "And lastly, create jackd connections using aj-snapshot..."
> cp /home/jeb/AJSRO.xml /home/jeb/AJRunning.xml
> nohup schedtool -R -p 75 -e aj-snapshot -d AJRunning.xml &
> 

Same question actually wrt to aj-snapshot running as a daemon and mididings.

And are you using rtirq-init? What other optimizations did you make on
your system? Just ftr (or call it plain braggin'), I can run a Qtractor
project with 14 ZynAddSubFX LV2 plugins and a handful of other plugins
(compression, reverb, eq) with similar JACK settings (-n3 -p64 -r48000).
But then I'm not sure if you're using multiple parts per Yoshimi
instance, it could well be you're using 48 parts that contain
instruments with lots of voices :)

Bye,

Jeremy

> 
> 
> 
> _______________________________________________
> Linux-audio-user mailing list
> Linux-audio-user at lists.linuxaudio.org
> http://lists.linuxaudio.org/listinfo/linux-audio-user
> 


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: OpenPGP digital signature
URL: <http://lists.linuxaudio.org/pipermail/linux-audio-user/attachments/20140419/a62d6c4e/attachment.pgp>