19 Apr
2014
19 Apr
'14
5:58 a.m.
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 mididings), 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.
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
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
# Remove all connections
echo "Stopping a2j..."
a2j_control stop
echo "Stopping Jackd to remove all connections..."
killall -9 -w jackdbus
killall -9 -w jackdbus
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
# 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
# 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 &
19 Apr
19 Apr
12:31 p.m.
On 04/19/2014 05:58 AM, Jonathan E Brickman wrote:
When I keep the schedtool prefixes, MIDI keyhits all
make it in and
synths all get their signal out through the sound card output.
That may be true for ALSA MIDI applications, but for jack applications
using schedtool is plain wrong.
You do not want to raise the priority of the application (think GUI or
UI) itself. You only want the audio+midi i/o of an app to have realtime
privileges. JACK does just that. With schedutils the GUI or application
itself is be able to preempt audio I/O.
You should have even better performance if you use schedtools only for
applications that use alsa. And ideally just get rid of all native ALSA
apps (most of the ones on your list do offer jack audio+midi), and use
the new jack-0.124.1 instead of a2jmidid.
When I don't, about one in 20-30 keyhits (and also
occasionally
key-ups) get lost.
Wow. If schedutils works around this, there must be something very odd
on your system, but hey. whatever works :)
I find the hack to use the dummy driver and always resample using
zita-a2j highly questionable. The timing of the dummy driver is
horrible. It just uses usleep() which waits _at_least_ the given time
(not at most). It's amazing that zita-ajbridge manages flatten this all
out without major distortion :)
The 'clock-source' configuration is misleading. The given clock is only
used for calculating the time of the last x-run and for the b0rked
built-in midi-drivers. It is not used in the dummy driver.
Anyway as last note: jack uses sched_FIFO which can only be preemted by
a another FIFO process with at least the same priority. Your schedtool
script uses sched_RR which can be preempted (context switch) by other RR
task (round robin time quantum), which is why it actually works: Those
apps still can't preempt jack. otherwise zita-j2a with a higher priority
than jack would cause all kind of priority inversions. yuck.
tl;dr: Rather get the new jack1 - with zalsa built it and a proper midi
driver and forget about schedutils.
2c,
robin
5:04 p.m.
Robin Gareus escribió:
On 04/19/2014 05:58 AM, Jonathan E Brickman
wrote:>> When I keep the schedtool prefixes, MIDI keyhits all make it in and
In my experiments with a Raspberry PI as a headless FX pedalboard+looper for live jamming
I don't use nohup/schedule commands on my scripts, and I've achieved an acceptable
RT system with really low latency. I'm constantly improving it anyway, but it seems
that disabling some services and tweaking jack1 is enough.
Hopefully I'll be releasing some scripts and apps when I can do some code cleanup to
release them properly.
BTW. Jonathan, nice and useful blog/notes. Thanks for sharing.
synths all get their signal out through the sound
card output. > That may be true for ALSA MIDI applications, but for jack applications
using schedtool is plain wrong.
You do not want to raise the priority of the application (think GUI or
UI) itself. You only want the audio+midi i/o of an app to have realtime
privileges. JACK does just that. With schedutils the GUI or application
itself is be able to preempt audio I/O.
You should have even better performance if you use schedtools only for
applications that use alsa. And ideally just get rid of all native ALSA
apps (most of the ones on your list do offer jack audio+midi), and use
the new jack-0.124.1 instead of a2jmidid.>> When I don't, about one in 20-30
keyhits (and also occasionally
key-ups) get lost.> Wow. If schedutils works
around this, there must be something very odd
on your system, but hey. whatever
works :)
I find the hack to use the dummy driver and always resample using
zita-a2j highly questionable. The timing of the dummy driver is
horrible. It just uses usleep() which waits _at_least_ the given time
(not at most). It's amazing that zita-ajbridge manages flatten this all
out without major distortion :)
The 'clock-source' configuration is misleading. The given clock is only
used for calculating the time of the last x-run and for the b0rked
built-in midi-drivers. It is not used in the dummy driver.
Anyway as last note: jack uses sched_FIFO which can only be preemted by
a another FIFO process with at least the same priority. Your schedtool
script uses sched_RR which can be preempted (context switch) by other RR
task (round robin time quantum), which is why it actually works: Those
apps still can't preempt jack. otherwise zita-j2a with a higher priority
than jack would cause all kind of priority inversions. yuck.
tl;dr: Rather get the new jack1 - with zalsa built it and a proper midi
driver and forget about schedutils.
2c,
robin
8:21 p.m.
New subject: Raspberry PI as a FX pedalboard and looper
In my experiments with a Raspberry PI as a headless FX pedalboard+looper for live jamming
I don't use nohup/schedule commands on my scripts, and I've achieved an acceptable
RT system with really low latency. I'm constantly improving it anyway, but it seems
that disabling some services and tweaking jack1 is enough.
Hopefully I'll be releasing some scripts and apps when I can do some code cleanup to
release them properly.
BTW. Jonathan, nice and useful blog/notes. Thanks for sharing.
Thanks, cscan. I am rather interested to hear that you are able to so much with your
R.P.! After I have the current rig in a nice functional configuration, I'll probably
try one of those, or possibly one of the powerful workalikes I read about in a recent web
excursion, I probably need the DSP cycles :-) What kind of audio I/O hardware are you
using, and are you using MIDI or OSC or something else for the pedal signal?
--
Jonathan E. Brickman
Ponderworthy Music | jeb@ponderworthy.com<mailto:jeb@ponderworthy.com> |
(785)233-9977 | http://ponderworthy.com
22 Apr
22 Apr
5:24 p.m.
New subject: Raspberry PI as a FX pedalboard and looper
2014-04-19 20:21 GMT+02:00 Jonathan E Brickman <jeb(a)ponderworthy.com>om>:
In my experiments with a Raspberry PI as a headless FX pedalboard+looper for
live jamming I don't use nohup/schedule commands on my scripts, and I've
achieved an acceptable RT system with really low latency. I'm constantly
improving it anyway, but it seems that disabling some services and tweaking
jack1 is enough.
Hopefully I'll be releasing some scripts and apps when I can do some code
cleanup to release them properly.
BTW. Jonathan, nice and useful blog/notes. Thanks for sharing.
Thanks, cscan. I am rather interested to hear that you are able to so much
with your R.P.! After I have the current rig in a nice functional
configuration, I'll probably try one of those, or possibly one of the
powerful workalikes I read about in a recent web excursion, I probably need
the DSP cycles :-) What kind of audio I/O hardware are you using, and are
you using MIDI or OSC or something else for the pedal signal?
--
Jonathan E. Brickman
Ponderworthy Music | jeb(a)ponderworthy.com | (785)233-9977 |
http://ponderworthy.com
Audio interface: Edirol UA25EX
... and a configurable pedalboard that triggers MIDI and OSC, although
right now I'm just using MIDI messages.
I'm considering contributing with my two modest cents in this an other
matters, releasing and freeing some
knowledge/code/processes/investigations, at least as I kind of big and
personal thanks to all the great people in this list, and of course in
FLOSS community as well.
It's not the first time recently that this subject of headless
musicstation shows up in here.
--
Carlos sanchiavedraz
* Musix GNU+Linux
http://www.musix.es
5:56 p.m.
New subject: Raspberry PI as a FX pedalboard and looper
Thanks, cscan.
I am rather interested to hear that you are able to so
much with your R.P.! After I have the current rig in a nice
functional configuration, I'll probably try one of those, or possibly
one of the powerful workalikes I read about in a recent web excursion,
I probably need the DSP cycles :-) What kind of audio I/O hardware
are you using, and are you using MIDI or OSC or something else for the
pedal
signal? Audio interface: Edirol UA25EX
... and a configurable pedalboard that triggers MIDI and OSC, although right
now I'm just using MIDI messages.
I'm considering contributing with my two modest cents in this an other
matters, releasing and freeing some
knowledge/code/processes/investigations, at least as I kind of big and
personal thanks to all the great people in this list, and of course in FLOSS
community as well.
It's not the first time recently that this subject of headless musicstation
shows up in here.
Definitely will be looking forward, Carlos!
J.E.B.
20 Apr
20 Apr
4:08 p.m.
On 04/19/2014 05:04 PM, csan wrote:
In my experiments with a Raspberry PI as a headless FX
pedalboard+looper for live jamming I don't use nohup/schedule commands on my scripts,
and I've achieved an acceptable RT system with really low latency. I'm constantly
improving it anyway, but it seems that disabling some services and tweaking jack1 is
enough.
Yay, another guitarist playing around with a RPi!
Hopefully I'll be releasing some scripts and apps
when I can do some code cleanup to release them properly.
That'd be great, please do so.
Jeremy
19 Apr
19 Apr
4:13 p.m.
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 \
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?
/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
# 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(a)lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-user
4:42 p.m.
On 04/19/2014 04:13 PM, Jeremy Jongepier wrote:
Why not use Jack2's built-in alsarawmidi driver?
because it [excuse my language] sucks. very bad timing & jitter.
For all linux versions of jack, except the latest version of jack1
(0.124) using a2jdmidi is highly recommended.
ciao,
robin
6:18 p.m.
On Sat, 2014-04-19 at 16:42 +0200, Robin Gareus wrote:
On 04/19/2014 04:13 PM, Jeremy Jongepier wrote:
In the past I used jack2's -Xalsarawmidi option to get rid of bad timing
and jitter. I can't speak for current jack1 and jack2, but some time ago
-Xalsarawmidi improved those things a lot compared to jack1, which
didn't provide this option and compared to jack2 without using this
option.
Are we speaking about the same alsarawmidi thingy? I'm thinking of
something like this:
jackd --sync -Xalsarawmidi -dalsa -r$sample_rate -p$frames_period
Regards,
Ralf
Why not use Jack2's built-in alsarawmidi
driver?
because it [excuse my language] sucks. very bad timing & jitter.
7:48 p.m.
New subject: JACK MIDI latency -- was Re: Concerning schedtool
On 04/19/2014 06:18 PM, Ralf Mardorf wrote:
On Sat, 2014-04-19 at 16:42 +0200, Robin Gareus wrote:
Indeed they're pretty close these days. That was not true last time I
measured it. a2jmidid still has a slight edge, here. Same latency as
alsarawmidi but less jitter.
jackd2 from git (ab409a65df).
measured with https://github.com/x42/jack_midi_latency
using a PreSonus 1818VSL on a thinkpad x60s. linux 3.2.35 SMP PREEMPT RT
======================
## jackd -S -dalsa -dhw:2 -r48000 -p64 -n2 -Xraw
JACK settings: samplerate: 48000, samples/period: 64
probable nominal jack latency: 128 [samples] = 2.67 [ms]
TOTAL: 10000 MIDI events sent+received.
min= 183 max= 209 range= 26 avg= 193.6 dev= 4.69 [samples]
min= 3.81 max= 4.35 range= 0.54 avg= 4.0 dev= 0.10 [ms]
0.00 .. 3.78 [ms]: 0
3.78 .. 3.80 [ms]: 2 #
3.80 .. 3.81 [ms]: 0
3.81 .. 3.83 [ms]: 13 #
3.83 .. 3.85 [ms]: 44 #
3.85 .. 3.86 [ms]: 127 #
3.86 .. 3.88 [ms]: 0
3.88 .. 3.89 [ms]: 142 #
3.89 .. 3.91 [ms]: 270 ##
3.91 .. 3.93 [ms]: 222 ##
3.93 .. 3.94 [ms]: 491 ####
3.94 .. 3.96 [ms]: 0
3.96 .. 3.98 [ms]: 4930 ###########################################
3.98 .. 3.99 [ms]: 263 ##
3.99 .. 4.01 [ms]: 174 #
4.01 .. 4.03 [ms]: 0
4.03 .. 4.04 [ms]: 159 #
4.04 .. 4.06 [ms]: 152 #
4.06 .. 4.07 [ms]: 612 ######
4.07 .. 4.09 [ms]: 200 ##
4.09 .. 4.11 [ms]: 0
4.11 .. 4.12 [ms]: 298 ###
4.12 .. 4.14 [ms]: 170 #
4.14 .. 4.16 [ms]: 188 #
4.16 .. 4.17 [ms]: 132 #
4.17 .. 4.19 [ms]: 0
4.19 .. 4.20 [ms]: 733 #######
4.20 .. 4.22 [ms]: 490 ####
4.22 .. 4.24 [ms]: 153 #
4.24 .. inf [ms]: 34 #
======================
## jackd -S -dalsa -dhw:2 -r48000 -p64 -n2
## a2jmidid -e
JACK settings: samplerate: 48000, samples/period: 64
probable nominal jack latency: 128 [samples] = 2.67 [ms]
TOTAL: 10000 MIDI events sent+received.
min= 184 max= 209 range= 25 avg= 193.0 dev= 4.09 [samples]
min= 3.83 max= 4.35 range= 0.52 avg= 4.0 dev= 0.09 [ms]
0.00 .. 3.80 [ms]: 0
3.80 .. 3.83 [ms]: 48 #
3.83 .. 3.85 [ms]: 73 #
3.85 .. 3.88 [ms]: 99 #
3.88 .. 3.91 [ms]: 131 #
3.91 .. 3.93 [ms]: 164 #
3.93 .. 3.96 [ms]: 6318 ############################################
3.96 .. 3.98 [ms]: 252 #
3.98 .. 4.01 [ms]: 174 #
4.01 .. 4.04 [ms]: 133 #
4.04 .. 4.06 [ms]: 906 #######
4.06 .. 4.09 [ms]: 223 #
4.09 .. 4.11 [ms]: 151 #
4.11 .. 4.14 [ms]: 96 #
4.14 .. 4.17 [ms]: 220 #
4.17 .. 4.19 [ms]: 623 ####
4.19 .. inf [ms]: 388 ###
======================
## jackd -S -dalsa -dhw:2 -r48000 -p64 -n2 -Xseq
interestingly has the lowest latency (one period less) but 3 times the
jitter.
JACK settings: samplerate: 48000, samples/period: 64
probable nominal jack latency: 128 [samples] = 2.67 [ms]
TOTAL: 10000 MIDI events sent+received.
min= 128 max= 179 range= 51 avg= 154.2 dev= 13.59 [samples]
min= 2.67 max= 3.73 range= 1.06 avg= 3.2 dev= 0.28 [ms]
0.00 .. 2.57 [ms]: 53 #
2.57 .. 2.69 [ms]: 542 ##############
2.69 .. 2.81 [ms]: 1834 ############################################
2.81 .. 2.93 [ms]: 1078 #############################
2.93 .. 3.05 [ms]: 764 ####################
3.05 .. 3.18 [ms]: 1750 #########################################
3.18 .. 3.30 [ms]: 887 ########################
3.30 .. 3.42 [ms]: 1164 ###############################
3.42 .. 3.54 [ms]: 1720 ########################################
3.54 .. 3.66 [ms]: 207 #####
3.66 .. 3.78 [ms]: 0
3.78 .. inf [ms]: 0
ciao,
robin
On 04/19/2014 04:13 PM, Jeremy Jongepier wrote:
In the past I used jack2's -Xalsarawmidi option to get rid of bad timing
and jitter. I can't speak for current jack1 and jack2, but some time ago
-Xalsarawmidi improved those things a lot compared to jack1, which
didn't provide this option and compared to jack2 without using this
option. Why not use Jack2's built-in alsarawmidi
driver?
because it [excuse my language] sucks. very bad timing & jitter.
20 Apr
20 Apr
3:49 a.m.
New subject: JACK MIDI latency -- was Re: Concerning schedtool
IIUC we are not talking about the same alsarawmidi.
On Sat, 2014-04-19 at 18:18 +0200, Ralf Mardorf wrote:
jackd --sync -Xalsarawmidi -dalsa -r$sample_rate
-p$frames_period
^^^^^ ^^^^^^^^^^^^^
On Sat, 2014-04-19 at 19:47 +0200, Robin Gareus wrote:
jackd -S -dalsa -dhw:2 -r48000 -p64 -n2 -Xraw
^^^^^^ ^^^^^
Take a look at an older thread:
From: Devin Anderson
To: Paul Davis
Cc: Ralf Mardorf, linux-audio-user(a)lists.linuxaudio.org
Subject: Re: [LAU] midi backend not working in qjackctl?
Date: Wed, 14 Mar 2012 10:00:50 -0700
On Wed, Mar 14, 2012 at 9:04 AM, Paul Davis <paul(a)linuxaudiosystems.com>
wrote:
On Wed, Mar 14, 2012 at 11:52 AM, Ralf Mardorf
<ralf.mardorf(a)alice-dsl.net> wrote:
The 'alsarawmidi' slave driver in JACK 2 does not have this problem.
It postpones the delivery of events based on the audio buffer size.
Back in April, when I requested MIDI latency/jitter test results for
the driver, I saw peak jitter results as low as 60 microseconds.
The 'seq' and 'raw' drivers attached to the ALSA audio driver still
suffer from this problem.
--
Devin Anderson
surfacepatterns (at) gmail (dot) com
blog - http://surfacepatterns.blogspot.com/
synthclone - http://synthclone.googlecode.com/
Especially in combination with Jack2's
-Xalsarawmidi you'll get zero
hw MIDI jitter, aka hard real-time.
I don't know if this is the new code that was added recently.
If its the old stuff then it absolutely is not zero jitter. You're
confused about the difference between "real time", "low latency" and
"jitter". The whole problem of the old code is that was absolutely
"deliver it as fast as possible" and that is precisely is what causes
jitter.
3:38 p.m.
New subject: JACK MIDI latency -- was Re: Concerning schedtool
On 04/20/2014 03:49 AM, Ralf Mardorf wrote:
IIUC we are not talking about the same alsarawmidi.
On Sat, 2014-04-19 at 18:18 +0200, Ralf Mardorf wrote:
^^^^^^
^^^^^
it prints
JackALSARawMidiDriver::Start - Starting 'alsarawmidi' driver.
JackALSARawMidiDriver::Start - starting ALSA thread ...
JackALSARawMidiDriver::Start - started ALSA thread.
as part of the startup message.
-Xraw is needed because otherwise I don't get any midi ports at all.
fPlaybackChannels and fCaptureChannels in
<jack2-source>/linux/alsarawmidi/JackALSARawMidiDriver.cpp are zero
otherwise.
Devin wrote:
> jackd --sync -Xalsarawmidi -dalsa
-r$sample_rate -p$frames_period
^^^^^ ^^^^^^^^^^^^^
On Sat, 2014-04-19 at 19:47 +0200, Robin Gareus wrote:
> > jackd -S -dalsa -dhw:2 -r48000 -p64 -n2 -Xraw when I requested MIDI latency/jitter test results for
the driver, I saw peak jitter results as low as 60 microseconds.
The jitter measurement here using alsarawmidi is 100 us stddev over 10K
events, 3 bytes each (using a USB2 device - details in prev email).
That's not far off from what Devin quoted, but without knowing what and
how he measured it, I can't comment on it.
ciao,
robin
3:49 p.m.
New subject: JACK MIDI latency -- was Re: Concerning schedtool
On 04/20/2014 03:38 PM, Robin Gareus wrote:
-Xraw is needed because otherwise I don't get any
midi ports at all.
fPlaybackChannels and fCaptureChannels in
<jack2-source>/linux/alsarawmidi/JackALSARawMidiDriver.cpp are zero
otherwise.
That's weird, it works for me (with a slightly old version of Jack2
though). How did you measure the MIDI jitter btw?
Thanks,
Jeremy
4 p.m.
New subject: JACK MIDI latency -- was Re: Concerning schedtool
On 04/20/2014 03:48 PM, Jeremy Jongepier wrote:
Hi Jeremy,
How did you measure the MIDI jitter btw?
see the OP for details
http://lists.linuxaudio.org/pipermail/linux-audio-user/2014-April/097296.ht…
in short:
get https://github.com/x42/jack_midi_latency
alike jack_delay: connect a cable from the physical midi-out back to
midi-in on your soundcard and run
./jack_midi_latency -i system:midi_capture_1 -o system:midi_playback_1
or similar, check jack_midi_latency --help, manually connecting the
ports works as well.
Cheers!
robin
4:05 p.m.
New subject: JACK MIDI latency -- was Re: Concerning schedtool
On 04/20/2014 03:59 PM, Robin Gareus wrote:
On 04/20/2014 03:48 PM, Jeremy Jongepier wrote:
Hi Jeremy,
Thanks a lot Robin! Overlooked the link, too much scanning, too little
reading :)
Jeremy
How did you measure the MIDI jitter btw?
see the OP for details
http://lists.linuxaudio.org/pipermail/linux-audio-user/2014-April/097296.ht…
in short:
get https://github.com/x42/jack_midi_latency
alike jack_delay: connect a cable from the physical midi-out back to
midi-in on your soundcard and run
./jack_midi_latency -i system:midi_capture_1 -o system:midi_playback_1
or similar, check jack_midi_latency --help, manually connecting the
ports works as well.
Cheers!
robin
4089
days inactive
4092
days old
linux-audio-user@lists.linuxaudio.org
15 comments
6 participants
participants (6)
-
Carlos sanchiavedraz -
csan
-
Jeremy Jongepier -
Jonathan E Brickman -
Ralf Mardorf -
Robin Gareus