14 Jul
2010
14 Jul
'10
3:23 p.m.
Hi :)
my PCI MIDI devices passed the alsa-midi-latency-test always with < 1.01
ms, on several Linux, with several kernels and graphic drivers. It's
audible that this can't be true. I was sceptic, when my USB MIDI passed
with around 2 ms, because recordings did show that there is much more
latency for the USB MIDI, when using Linux, just Windows is able to do
such less jitter on my machine, see the archives. I won't install
Windows again to compare the PCI MIDI. This computer can do better, but
MIDI fails for Linux. This comparison is just for testing the abilities
of the hardware.
Please test yourself what I did today and you'll be able to here it too.
It isn't just audible for gifted musicians, you'll really here that the
FluidSynth DSSI Kick and the Kick played by an external MIDI drum module
will be played one after another, but in unison. Note that I tested,
that this drum module still is 100% ok.
Please read the test and do the same as I did.
I decided to do the audio MIDI jitter test with 64 Studio 3.3 alpha. I
kept the proprietary 'nvidia' driver, even if the 'nv' driver, used by
64 Studio 3.0 beta, seems to cause x*10 µm less jitter.
First I checked the package 'rt-irq'. It's version 20090810-0ubuntu1
(karmic) and regarding to diff, I didn't over installed the current
version before. On Rui's download page http://www.rncbc.org/jack/ the
current version is 20090920.
I installed a dummy package rtirq-init_20090920_all.deb and updated both
rtirq files.
For /etc/default/rtirq I edited
line 30 from
RTIRQ_NAME_LIST="rtc snd usb i8042"
to
RTIRQ_NAME_LIST="rtc snd i8042"
line 33 from
RTIRQ_PRIO_HIGH=90
to
RTIRQ_PRIO_HIGH=98
I fixed the MIDI adaptor cable by screws to the 16:0 device and used the
audio IOs of the same card. It's the card with IRQ 20. Envy24 Control
automatically chose this card.
After shutdown and startup I did perform the ALSA MIDI latency test.
$ su -c "poff dsl-provider"
$ su -c "cpufreq-selector -g performance"
^C
$ cd /etc/init.d
$ ./rtirq status
PID CLS RTPRIO NI PRI %CPU STAT COMMAND
386 FF 95 - 135 0.0 S< irq/8-rtc0
1140 FF 90 - 130 0.0 S< irq/21-ICE1712
1137 FF 89 - 129 0.0 S< irq/20-ICE1712
379 FF 85 - 125 0.0 S< irq/1-i8042
378 FF 84 - 124 0.1 S< irq/12-i8042
102 FF 50 - 90 0.0 S< irq/9-acpi
565 FF 50 - 90 0.0 S< irq/14-ide0
570 FF 50 - 90 0.0 S< irq/16-ohci_hcd
587 FF 50 - 90 0.0 S< irq/22-ahci
597 FF 50 - 90 0.0 S< irq/19-ehci_hcd
598 FF 50 - 90 0.0 S< irq/22-ohci1394
601 FF 50 - 90 0.0 S< irq/17-ohci_hcd
603 FF 50 - 90 0.0 S< irq/18-ohci_hcd
606 FF 50 - 90 0.0 S< irq/17-ohci_hcd
609 FF 50 - 90 0.0 S< irq/18-ohci_hcd
932 FF 50 - 90 0.0 S< irq/7-parport0
1634 FF 50 - 90 0.3 S< irq/18-nvidia
1946 FF 50 - 90 0.0 S< irq/26-eth0
4 FF 49 - 89 0.0 S< sirq-high/0
5 FF 49 - 89 0.0 S< sirq-timer/0
6 FF 49 - 89 0.0 S< sirq-net-tx/0
7 FF 49 - 89 0.0 S< sirq-net-rx/0
8 FF 49 - 89 0.0 S< sirq-block/0
9 FF 49 - 89 0.0 S< sirq-tasklet/0
10 FF 49 - 89 0.0 S< sirq-sched/0
11 FF 49 - 89 0.0 S< sirq-hrtimer/0
12 FF 49 - 89 0.0 S< sirq-rcu/0
18 FF 49 - 89 0.0 S< sirq-high/1
19 FF 49 - 89 0.0 S< sirq-timer/1
20 FF 49 - 89 0.0 S< sirq-net-tx/1
21 FF 49 - 89 0.0 S< sirq-net-rx/1
22 FF 49 - 89 0.0 S< sirq-block/1
23 FF 49 - 89 0.3 S< sirq-tasklet/1
24 FF 49 - 89 0.0 S< sirq-sched/1
25 FF 49 - 89 0.0 S< sirq-hrtimer/1
26 FF 49 - 89 0.0 S< sirq-rcu/1
$ su -c "chgrp audio /dev/hpet"
$ su -c "sysctl -w dev.hpet.max-user-freq=64"
$ su -c "modprobe snd-hrtimer"
$ alsa-midi-latency-test -l
Port Client name Port name
14:0 Midi Through Midi Through Port-0
16:0 TerraTec EWX24/96 TerraTec EWX24/96 MIDI
20:0 TerraTec EWX24/96 TerraTec EWX24/96 MIDI
$ alsa-midi-latency-test -Rrw=5 -i16:0 -o16:0
alsa-midi-latency-test 0.0.3
set_realtime_priority(SCHED_FIFO, 99).. done.
clock resolution: 0.000000001 s
sample; latency_ms; latency_ms_worst
0; 1.07; 1.07
9999; 1.00; 1.07
latency distribution:
1.0 - 1.1 ms: 9994
##################################################
1.1 - 1.2 ms: 6 #
SUCCESS
best latency was 0.99 ms
worst latency was 1.07 ms, which is great.
$ alsa-midi-latency-test -Rrw=5 -i16:0 -o16:0
alsa-midi-latency-test 0.0.3
set_realtime_priority(SCHED_FIFO, 99).. done.
clock resolution: 0.000000001 s
sample; latency_ms; latency_ms_worst
0; 1.06; 1.06
timeout: there seems to be no connection between ports 16:0 and 16:0
I didn't check any connections, but run the test again. I've got no idea
what's wrong, when I get those timeouts. The adaptor cable with
opto-coupler is a brand new non self made one and the timeout can happen
for both cards, my old card S/N 00xxxxx with an Envy24 chip not by
Terratec and the new second hand card from Ebay S/N 04xxxxx with an
Envy24 chip by Terratec.
I didn't compare all the other chips, but the board's layouts don't
differ.
When doing the audio MIDI test the MIDInterface did work without missing
data.
$ alsa-midi-latency-test -Rrw=5 -i16:0 -o16:0
alsa-midi-latency-test 0.0.3
set_realtime_priority(SCHED_FIFO, 99).. done.
clock resolution: 0.000000001 s
sample; latency_ms; latency_ms_worst
0; 1.06; 1.06
5727; 1.06; 1.06
9999; 1.01; 1.06
latency distribution:
1.0 - 1.1 ms: 9992
##################################################
1.1 - 1.2 ms: 8 #
SUCCESS
best latency was 0.99 ms
worst latency was 1.06 ms, which is great.
Compared to the test done with the old setup
http://lists.64studio.com/pipermail/64studio-users/2010-July/004537.html
nothing did change.
$ jackd -Rch -dalsa -dhw:0 -r96000 -p1024 -n2
jackdmp 1.9.5
no message buffer overruns
no message buffer overruns
JACK server starting in realtime mode with priority 10
creating alsa driver ... hw:0|hw:0|1024|2|96000|0|0|nomon|swmeter|-|
32bit
Using ALSA driver ICE1712 running on card 0 - TerraTec EWX24/96 at
0xcf00, irq 20
configuring for 96000Hz, period = 1024 frames (10.7 ms), buffer = 2
periods
ALSA: final selected sample format for capture: 32bit integer
little-endian
ALSA: use 2 periods for capture
ALSA: final selected sample format for playback: 32bit integer
little-endian
ALSA: use 2 periods for playback
$ qtractor
Version: 0.4.6
Build: Jun 3 2010 15:26:56
JACK Session support disabled.
A Yamaha DX7 was directly connected to hw MIDI in and an Alesis D4 was
directly connected to hw MIDI out. The analog audio IOs from the sound
card and the main outs from the Alesis D4 were connected to a Behringer
UB2442FX-Pro. So, valid home recording equipment, without any critical
stuff. Excepted to the limit for the sound quality, there shouldn't be
any issues caused by this setup.
For the MIDI audio test's LXDE session I'm running GNOME terminal tab 1
JACK2, tab 2 Qtractor. Evolution offline + this Email opened for writing
to the lists. Envy24 Control and nothing else.
For Qtractor I switched from queue timer (resolution) 'system timer
(1000 Hz)' to 'HR timer (1000000000 Hz)' and restarted Qtractor.
1.
I disconnected all audio connections for JACK and connected hw MIDI in
to hw MIDI out. Live I played forefinger left hand kick, thumb left hand
snare and forefinger right hand ride.
To get an impression for the latency I connected the DX7 MIDI out
directly to the D4 MIDI in and then I reconnected to the PCI card.
The difference is alarming :(.
Yamaha DX7 --> Alesis D4 results in a 100% musical groove.
Yamaha DX7 --> PC --> Alesis D4 results in extreme latency, it's hardly
possible to keep on grooving. This never ever is a latency of just 1 ms,
I'm sure the ALSA MIDI latency test is mistaken. Even a MIDI thru chain
by several MIDI devices won't cause such bad latency.
2.
I disconnected all ALSA MIDI connections. I disconnected the DX7 from
the hw interface.
Qtractor was connected to hw MIDI out, while hw MIDI out still was
connected to the D4.
3.
After adding a MIDI track I added a MIDI clip (from bar 2 to bar 4, 4/4,
120BPM) with those notes:
Time_____Note_____V._Duration
2.01.000 (36) C 1 64 0.00.240
2.02.000 (37) C#1 64 0.00.240
2.02.480 (36) C 1 64 0.00.240
2.03.480 (37) C#1 64 0.00.240
2.04.000 (36) C 1 64 0.00.240
2.04.480 (37) C#1 64 0.00.240
2.04.720 (36) C 1 64 0.00.240
3.01.000 (36) C 1 64 0.00.240
3.01.480 (37) C#1 64 0.00.240
3.02.480 (36) C 1 64 0.00.240
3.03.240 (36) C 1 64 0.00.240
3.03.480 (37) C#1 64 0.00.240
3.04.000 (36) C 1 64 0.00.240
3.04.480 (37) C#1 64 0.00.240
Loop play for hw MIDI by Qtractor is a disaster, hence I copied and
paste repeated it 39 times, pasted with the grid set to beat. The
'rhythm' then was from bar 2 to bar 82.
4.
After adding a second MIDI track, I copied all clips from the first to
the new track.
The second track isn't for hw MIDI, but FluidSynth DSSI.
I connected Qtractor audio out to system playback.
Before I could play with the hw MIDI track muted, Qtractor crashed.
I opened a third tab for the GNOME terminal and tried to kill Qtractor
without success.
$ su
# pidof qtractor
4173
# kill 4173
# killall qtractor
# killall -9 -w qtractor
^C
# killall -9 qtractor
I stopped JACK.
[...]
JackAudioDriver::ProcessAsync Process error
JackEngine::XRun: client = Qtractor was not run: state = 1
JackAudioDriver::ProcessAsync Process error
JackEngine::XRun: client = Qtractor was not run: state = 1
JackAudioDriver::ProcessAsync Process error
JackEngine::XRun: client = Qtractor was not run: state = 1
JackAudioDriver::ProcessAsync Process error
JackEngine::XRun: client = Qtractor was not run: state = 1
JackAudioDriver::ProcessAsync Process error
JackAudioDriver::ProcessAsync Process error
^Cjack main caught signal 2
Unknown error...
FATAL: exception not rethrown
Aborted
But ...
# killall -9 qtractor
didn't work.
FWIW the Alesis D4 was set up to
NOTE: 036 C1
Kik/43: Slammin'
PITCH: +1.00
VOL: 99
PAN: <>
OUTPUT: MAIN
MODE: MULTI
NOTE: 037 C#1
Snr/92: Big Stik
PITCH: +1.00
VOL: 85
PAN: <>
OUTPUT: MAIN
MODE: MULTI
CHANNEL: 01
As usual for 64 Studio 3.3 alpha several restarts resulted with issues.
I had to turn the computer off and on.
1.
Started GNOME terminal tab 1.
su -c "poff dsl-provider"
2.
Started Evolution in offline mode and opened this Email.
3.
GNOME terminal tab 1
$ su -c "cpufreq-selector -g performance"
Password:
^Cspinymouse@64studio:~su -c "chgrp audio /dev/hpet"
I wonder why Ctrl + C is needed after running cpufreq-selector.
For Lucid it's the same.
$ su -c "sysctl -w dev.hpet.max-user-freq=64"
$ su -c "modprobe snd-hrtimer"
$ jackd -Rch -dalsa -dhw:0 -r96000 -p1024 -n2
4.
Opened a second tab for GNOME terminal.
$ qtractor /mnt/music/all-in-one_supplier/PCI_MIDI_test.qtr
HR timer still is selected.
The hw MIDI track is muted.
The FluidSynth DSSI MIDI track is ready to play.
FluidSynth is using 808Set.sf2.
Qtractor audio out was connected to system playback and system capture
was auto-connected to Qtractor audio in. I now disabled auto connect,
but kept this audio connections, resp. I had to manually restore them,
perhaps disabling auto connect, did disconnect them.
I had to disconnect and manually restore Qtractor MIDI out, because it
didn't connect to the 16:0 EWX 24/96 as stored, but to the 20:0 EWX
24/96.
5.
I launched Envy24 Control.
6.
I pushed play for Qtractor transport.
I stopped it.
Set up gain for FluidSynth from the default -14 dB to 0 dB.
Played again.
Unmuted the hw MIDI track.
The notes played by the soundfont and by the D4 are fluctuating between
completely being out of sync and between being played unison.
I stopped playing.
RESULT
THE PCI MIDI INTERFACE WITH AN ALSA-MIDI-TEST-LATENCY RESULT OF < 1.1 ms
IS COMPLETELY USELESS TO MAKE MUSIC, BUT 'GREAT'.
AND IT'S AUDIBLE THAT THERE IS MUCH MORE JITTER BUT 1.1 ms.
Any hints how to solve this are welcome.
What information is needed?
Cheers!
Ralf
14 Jul
14 Jul
3:45 p.m.
On 07/14/2010 03:23 PM, Ralf Mardorf wrote:
[..]
AND IT'S AUDIBLE THAT THERE IS MUCH MORE JITTER BUT 1.1 ms.
Any hints how to solve this are welcome.
Did you try to start jackd with -p64 instead of -p1024
using JACK-midi, I've encountered a similar issue with fluidsynth always
synchronizing note-start/ends to jack cycles.
Simply lowering the frames-per-period got me playing again so I did not
check if it's related to JACK-midi or FluidSynth 1.1.1 in general.
ciao,
robin
--
Robin Gareus mail: robin(a)gareus.org
site: http://gareus.org/ chat: xmpp:rgareus@ik.nu
blog: http://rg42.org/ lab : http://citu.fr/
Public Key at http://pgp.mit.edu/
Fingerprint : 7107 840B 4DC9 C948 076D 6359 7955 24F1 4F95 2B42
4:22 p.m.
Hi Robin :)
On Wed, 2010-07-14 at 15:44 +0200, Robin Gareus wrote:
On 07/14/2010 03:23 PM, Ralf Mardorf wrote:
A good argument, because when I made tests in the past for the USB MIDI,
things become better at >= -p256 (when I had this Windows test install
latency for the EWX 24/96 audio was less high than for Linux). The
problem here is, that I need at least -p512 and even than I'm not safe
regarding to issues for JACK audio, that's why I used -p1024 instead of
-p512. For a test -p64 should work, but when recording music I would
need to increase it step by step until a minimum of -p512.
IIRC when I did tests for the USB MIDI with -p64 or even -p125 (I'm not
sure) it theoretically did work, but this isn't a solution, because at
some point JACK audio will fail.
[..]
AND IT'S AUDIBLE THAT THERE IS MUCH MORE JITTER BUT 1.1 ms.
Any hints how to solve this are welcome.
Did you try to start jackd with -p64 instead of -p1024 using JACK-midi, I've encountered a similar issue
with fluidsynth always
synchronizing note-start/ends to jack cycles.
Simply lowering the frames-per-period got me playing again so I did not
check if it's related to JACK-midi or FluidSynth 1.1.1 in general.
At least FluidSynth DSSI (host is Qtractor) is able to play in unison
with any DSSI or virtual ALSA MIDI and JACK MIDI (-Xseq) synth on my
machine. Just 'in unison' for virtual synth to hw synth there sometimes
is more delay, but just an early reflection like effect.
Note! It was hard to groove when I connected the master keyboard to ALSA
hw MIDI in --> DIRECTLY TO --> ALSA hw MIDI out and this to a 100% ok
drum module. Directly connecting the master keyboard to the drum module
there were no issues.
I need to do something else now, but I take time off. From Friday
(perhaps earlier) until next Sunday noon I could spend the whole days
for this MIDI issue only.
Resume:
I assume that -p64 would solve this 'looooooong early reflection like
effect/async', but then hard disk recording will become impossible.
The target is, that Linux at least replace the Atari ST as sequencer +
an analog 4-Track machine synced by SMPTE. With -p64 4-track recoding
would become impossible.
'Read you later' today or at the latest on Friday.
Cheers!
Ralf
5:31 p.m.
On 07/14/2010 04:22 PM, Ralf Mardorf wrote:
Aha, by this we can infer that your problem is ALSA or kernel/timing
related.
To verify this, take everything up from there (eg. qtractor, fluidsynth)
out of the picture for now.
1) Use 'amidiplay' to send a some midi-song directly to your
drum-module. -> Is there still audible jitter?
2) Do you have a Hardware MIDI Sequencer? Have it play a simple
metronome beat and dump incoming MIDI-messages. See if the timestamps of
each midi-note-on message are identically spaced.
'aseqdump' (at least version 1.0.22 which I currently use) does not
print timing-info, 'kmidimon' does.
Hi Robin :)
On Wed, 2010-07-14 at 15:44 +0200, Robin Gareus wrote:
I'm sorry; don't understand that. Are you getting [audio] x-runs or what
is the problem using -p64 (or even -p32)?
I was hinting that the audible midi-jitter could be a result of
midi-messages getting 'quantizied' to jack-periods.
A JACK-MIDI app which does not honor 'jack_midi_event_t->time' but
simply processes all queued midi-events on each jack_process_callback()
will result in the symptoms you describe (snare & kick on the same
beat). One example of such an app is "a2j".
On 07/14/2010 03:23 PM, Ralf Mardorf wrote:
A good argument, because when I made tests in the past for the USB MIDI,
things become better at >= -p256 (when I had this Windows test install
latency for the EWX 24/96 audio was less high than for Linux). The
problem here is, that I need at least -p512 and even than I'm not safe
regarding to issues for JACK audio, that's why I used -p1024 instead of
-p512. For a test -p64 should work, but when recording music I would
need to increase it step by step until a minimum of -p512. [..]
AND IT'S AUDIBLE THAT THERE IS MUCH MORE JITTER BUT 1.1 ms.
Any hints how to solve this are welcome.
Did you try to start jackd with -p64 instead of -p1024 IIRC when I did tests for the USB MIDI with -p64 or
even -p125 (I'm not
sure) it theoretically did work, but this isn't a solution, because at
some point JACK audio will fail.
How does it fail? x-runs?
JACKd works quite robust here with the UA25 and FA101 at 64fpp.
using
JACK-midi, I've encountered a similar issue with fluidsynth always
synchronizing note-start/ends to jack cycles.
Simply lowering the frames-per-period got me playing again so I did not
check if it's related to JACK-midi or FluidSynth 1.1.1 in general.
At least FluidSynth DSSI (host is Qtractor) is able to play in unison
with any DSSI or virtual ALSA MIDI and JACK MIDI (-Xseq) synth on my
machine. Just 'in unison' for virtual synth to hw synth there sometimes
is more delay, but just an early reflection like effect.
Note! It was hard to groove when I connected the master keyboard to ALSA
hw MIDI in --> DIRECTLY TO --> ALSA hw MIDI out and this to a 100% ok
drum module. Directly connecting the master keyboard to the drum module
there were no issues. I need to do something else now, but I take time off.
From Friday
(perhaps earlier) until next Sunday noon I could spend the whole days
for this MIDI issue only.
Resume:
I assume that -p64 would solve this 'looooooong early reflection like
effect/async', but then hard disk recording will become impossible.
The target is, that Linux at least replace the Atari ST as sequencer +
an analog 4-Track machine synced by SMPTE. With -p64 4-track recoding
would become impossible.
I'm pretty sure that you can get a stable 64fpp setup, but one thing at
a time. let's keep this thread to MIDI just now.
'Read you later' today or at the latest on
Friday.
enjoy a good long week-end.
Cheers!
Ralf
ciao,
robin
--
Robin Gareus mail: robin(a)gareus.org
site: http://gareus.org/ chat: xmpp:rgareus@ik.nu
blog: http://rg42.org/ lab : http://citu.fr/
Public Key at http://pgp.mit.edu/
Fingerprint : 7107 840B 4DC9 C948 076D 6359 7955 24F1 4F95 2B42
7:58 p.m.
On Wed, 2010-07-14 at 17:30 +0200, Robin Gareus wrote:
All kinds of dropouts, even the left and right channel seem to get out
of phase. Just running FluidSynth DSSI playing a kick and a rim-shot was
without audible failure at -p16, but I'm sure I won't be able to do
multi-trach recording with -p16.
Have a nice weekend too.
I'll spend the weekend for Linux audio.
Cheers!
Ralf
On 07/14/2010 04:22 PM, Ralf Mardorf wrote:
Yes there are lapse, even if there should be no messages about xruns.
Hi Robin :)
On Wed, 2010-07-14 at 15:44 +0200, Robin Gareus wrote:
I'm sorry; don't understand that. Are you getting [audio] x-runs or what
is the problem using -p64 (or even -p32)? On 07/14/2010 03:23 PM, Ralf Mardorf wrote:
A good argument, because when I made tests in the past for the USB MIDI,
things become better at >= -p256 (when I had this Windows test install
latency for the EWX 24/96 audio was less high than for Linux). The
problem here is, that I need at least -p512 and even than I'm not safe
regarding to issues for JACK audio, that's why I used -p1024 instead of
-p512. For a test -p64 should work, but when recording music I would
need to increase it step by step until a minimum of -p512. [..]
AND IT'S AUDIBLE THAT THERE IS MUCH MORE JITTER BUT 1.1 ms.
Any hints how to solve this are welcome.
Did you try to start jackd with -p64 instead of -p1024 I was hinting that the audible midi-jitter could be a
result of
midi-messages getting 'quantizied' to jack-periods.
It seems to be like that. Take a look at my email with the
subject:
Correlation of alsa -p value and hw
MIDI jitter
A JACK-MIDI app which does not honor
'jack_midi_event_t->time' but
simply processes all queued midi-events on each jack_process_callback()
will result in the symptoms you describe (snare & kick on the same
beat). One example of such an app is "a2j".
I did use Qtractor, but had the same issue when using Rosegarden a long
time ago. But we are talking about ALSA MIDI to the hardware
MIDInterface?!
IIRC when I
did tests for the USB MIDI with -p64 or even -p125 (I'm not
sure) it theoretically did work, but this isn't a solution, because at
some point JACK audio will fail.
How does it fail? x-runs?
JACKd works quite robust here with the UA25 and FA101 at 64fpp.
Aha, by this we can infer that your problem is ALSA or kernel/timing
related.
To verify this, take everything up from there (eg. qtractor, fluidsynth)
out of the picture for now.
1) Use 'amidiplay' to send a some midi-song directly to your
drum-module. -> Is there still audible jitter?
On a todo list, but there seems to be a correlation to JACK audio.
using
JACK-midi, I've encountered a similar issue with fluidsynth always
synchronizing note-start/ends to jack cycles.
Simply lowering the frames-per-period got me playing again so I did not
check if it's related to JACK-midi or FluidSynth 1.1.1 in general.
At least FluidSynth DSSI (host is Qtractor) is able to play in unison
with any DSSI or virtual ALSA MIDI and JACK MIDI (-Xseq) synth on my
machine. Just 'in unison' for virtual synth to hw synth there sometimes
is more delay, but just an early reflection like effect.
Note! It was hard to groove when I connected the master keyboard to ALSA
hw MIDI in --> DIRECTLY TO --> ALSA hw MIDI out and this to a 100% ok
drum module. Directly connecting the master keyboard to the drum module
there were no issues.
2) Do you have a Hardware MIDI Sequencer? Have it play a simple
metronome beat and dump incoming MIDI-messages. See if the timestamps of
each midi-note-on message are identically spaced.
C64 and Atari ST are stable, but there are some issues for e.g the
monitor. My VGA isn't slow enough for the Atari. I'll try to do it with
the broken SM124.
'aseqdump' (at least version 1.0.22 which I
currently use) does not
print timing-info, 'kmidimon' does.
Thank you for your effort :).
I need to do something else now, but I take time
off. From Friday
(perhaps earlier) until next Sunday noon I could spend the whole days
for this MIDI issue only.
Resume:
I assume that -p64 would solve this 'looooooong early reflection like
effect/async', but then hard disk recording will become impossible.
The target is, that Linux at least replace the Atari ST as sequencer +
an analog 4-Track machine synced by SMPTE. With -p64 4-track recoding
would become impossible.
I'm pretty sure that you can get a stable 64fpp setup, but one thing at
a time. let's keep this thread to MIDI just now. 'Read you later' today or at the latest
on Friday.
enjoy a good long week-end. Cheers!
Ralf
ciao,
robin
9:43 p.m.
On 07/14/2010 07:58 PM, Ralf Mardorf wrote:
All kinds of dropouts, even the left and right channel seem to get out
of phase. Just running FluidSynth DSSI playing a kick and a rim-shot was
without audible failure at -p16, but I'm sure I won't be able to do
multi-trach recording with -p16.
The idea is to remove all correlations. Otherwise it's very hard to find
the problem.
It looks like you're chasing [at least] two different issues:
1) ALSA / hardware jitter
2) qtractor/fluidsynth timing/sync
Don't even start JACKd. just use 'aplaymidi'.
or 'ametro' http://perso.wanadoo.es/plcl/ametro/ametro-en.html
You can also just use 'arecordmidi' and open it later in an editor.
And finally:
External-Keyboard or Sequencer -> PC -> External-Synth
Use 'aconnect' or 'aconnectgui' to connect MIDI-in -> MIDI-out.
There should be some latency but no recognizable jitter.
If these 3 (amidiplay, amidirecord, ALSA midi-thru) do not work as
expected, all other tests that mix external-hardware and software will
be [more or less] useless.
Thank you for your effort :).
Have a nice weekend too.
I wish I could.
It's only just Wednesday here, even though it's Bastille day.
On Wed, 2010-07-14 at 17:30 +0200, Robin Gareus
wrote:
It turned out I was using an ancient version of "a2j".
On 07/14/2010 04:22 PM, Ralf Mardorf wrote:
Yes there are lapse, even if there should be no messages about xruns.
Hi Robin :)
On Wed, 2010-07-14 at 15:44 +0200, Robin Gareus wrote:
I'm sorry; don't understand that. Are you getting [audio] x-runs or what
is the problem using -p64 (or even -p32)? On 07/14/2010 03:23 PM, Ralf Mardorf wrote:
> [..]
> AND IT'S AUDIBLE THAT THERE IS MUCH MORE JITTER BUT 1.1 ms.
>
> Any hints how to solve this are welcome.
Did you try to start jackd with -p64 instead of -p1024
A good argument, because when I made tests in the past for the USB MIDI,
things become better at >= -p256 (when I had this Windows test install
latency for the EWX 24/96 audio was less high than for Linux). The
problem here is, that I need at least -p512 and even than I'm not safe
regarding to issues for JACK audio, that's why I used -p1024 instead of
-p512. For a test -p64 should work, but when recording music I would
need to increase it step by step until a minimum of -p512. I was hinting that the audible midi-jitter could
be a result of
midi-messages getting 'quantizied' to jack-periods.
It seems to be like that. Take a look at my email with the
subject:
Correlation of alsa -p value and hw
MIDI jitter
> A JACK-MIDI app which does not honor 'jack_midi_event_t->time' but
> simply processes all queued midi-events on each jack_process_callback()
> will result in the symptoms you describe (snare & kick on the same
> beat). One example of such an app is "a2j". I did use Qtractor, but had the same issue when using
Rosegarden a long
time ago. But we are talking about ALSA MIDI to the hardware
MIDInterface?!
Originally i was only talking about JACK-MIDI apps.
IIRC when I did tests for the USB MIDI with -p64 or
even -p125 (I'm not
sure) it theoretically did work, but this isn't a solution, because at
some point JACK audio will fail.
How does it fail? x-runs?
JACKd works quite robust here with the UA25 and FA101 at 64fpp.
Aha, by this we can infer that your problem is ALSA or kernel/timing
related.
To verify this, take everything up from there (eg. qtractor, fluidsynth)
out of the picture for now.
1) Use 'amidiplay' to send a some midi-song directly to your
drum-module. -> Is there still audible jitter?
On a todo list, but there seems to be a correlation to JACK audio. using
JACK-midi, I've encountered a similar issue with fluidsynth always
synchronizing note-start/ends to jack cycles.
Simply lowering the frames-per-period got me playing again so I did not
check if it's related to JACK-midi or FluidSynth 1.1.1 in general.
At least FluidSynth DSSI (host is Qtractor) is able to play in unison
with any DSSI or virtual ALSA MIDI and JACK MIDI (-Xseq) synth on my
machine. Just 'in unison' for virtual synth to hw synth there sometimes
is more delay, but just an early reflection like effect.
Note! It was hard to groove when I connected the master keyboard to ALSA
hw MIDI in --> DIRECTLY TO --> ALSA hw MIDI out and this to a 100% ok
drum module. Directly connecting the master keyboard to the drum module
there were no issues. 2) Do you have
a Hardware MIDI Sequencer? Have it play a simple
metronome beat and dump incoming MIDI-messages. See if the timestamps of
each midi-note-on message are identically spaced.
C64 and Atari ST are stable, but there are some issues for e.g the
monitor. My VGA isn't slow enough for the Atari. I'll try to do it with
the broken SM124.
> 'aseqdump' (at least version 1.0.22 which I currently use) does not
> print timing-info, 'kmidimon' does. I need to do something else now, but I take time off.
From Friday
(perhaps earlier) until next Sunday noon I could spend the whole days
for this MIDI issue only.
Resume:
I assume that -p64 would solve this 'looooooong early reflection like
effect/async', but then hard disk recording will become impossible.
The target is, that Linux at least replace the Atari ST as sequencer +
an analog 4-Track machine synced by SMPTE. With -p64 4-track recoding
would become impossible.
I'm pretty sure that you can get a stable 64fpp setup, but one thing at
a time. let's keep this thread to MIDI just now. 'Read you later' today or at the latest
on Friday.
enjoy a good long week-end. I'll spend the weekend for Linux audio.
Cheers!
Ralf
Cheers!
Ralf
ciao,
robin
10:08 p.m.
On Wed, 2010-07-14 at 21:42 +0200, Robin Gareus wrote:
You can also just use 'arecordmidi' and open it later in an editor.
And finally:
External-Keyboard or Sequencer -> PC -> External-Synth
Use 'aconnect' or 'aconnectgui' to connect MIDI-in -> MIDI-out.
There should be some latency but no recognizable jitter.
If these 3 (amidiplay, amidirecord, ALSA midi-thru) do not work as
expected, all other tests that mix external-hardware and software will
be [more or less] useless.
ALSA MIDI thru definitive has audible latency. I played live testing
this. I can't say if it was stable latency or jitter.
Do you know the psychological effect, when you try to sing, while you
just can here your vocals with much delay?
You will lose timing.
amidiplay can play MIDI files for two MIDI channels? Note! It's not easy
to notice this jitter, when there isn't a reference, e.g. you try to
groove live or a bass by a software synth should be in sync with
external drums. Just listening to one source with jitter just works for
a short time, than you become unable for hours to notice a bad timing.
But you always will notice this issues for real work, e.g. when first
recording an external bass and than recording the external bass drum
etc..
Thank you for your effort :).
Have a nice weekend too.
I wish I could.
It's only just Wednesday here, even though it's Bastille day.
Here it's Wednesday too ... when I said I've got time from Friday to
Sunday for Linux only, I was talking about the da after tomorrow :D.
Btw. I assume that the max. time difference on earth won't be days ;).
A thunder-storm put a spoke in my wheel .. I shouldn't be online now :D.
Cheers!
Ralf
On 07/14/2010 07:58 PM, Ralf Mardorf wrote:
All kinds of dropouts, even the left and right channel seem to get out
of phase. Just running FluidSynth DSSI playing a kick and a rim-shot was
without audible failure at -p16, but I'm sure I won't be able to do
multi-trach recording with -p16.
The idea is to remove all correlations. Otherwise it's very hard to find
the problem.
It looks like you're chasing [at least] two different issues:
1) ALSA / hardware jitter
2) qtractor/fluidsynth timing/sync
Don't even start JACKd. just use 'aplaymidi'.
or 'ametro' http://perso.wanadoo.es/plcl/ametro/ametro-en.html
There might be another strange behaviour. IIRC when I recorded audio
from external MIDI devices (when I used my USB MIDI in the past), some
waveforms were recorded, before the MIDI event should be played.
I need to test this again.
Btw. I used Qtractor, that didn't had a latency compensation that might
work bad, hence all MIDI events should have (positive) delay, but
negative delay for recordings. When doing the test today I even didn't
notice if always the virtual or the external drum sounds were later or
if it does change, far less that I was able to hear if there was just
delay or negative delay, I didn't record anything and it's hard to hear
those details, it's easier to hear that something isn't in timeing.
On Wed, 2010-07-14 at 17:30 +0200, Robin Gareus
wrote:
It turned out I was using an ancient version of "a2j".
On 07/14/2010 04:22 PM, Ralf Mardorf wrote:
Yes there are lapse, even if there should be no messages about xruns.
Hi Robin :)
On Wed, 2010-07-14 at 15:44 +0200, Robin Gareus wrote:
> On 07/14/2010 03:23 PM, Ralf Mardorf wrote:
>> [..]
>> AND IT'S AUDIBLE THAT THERE IS MUCH MORE JITTER BUT 1.1 ms.
>>
>> Any hints how to solve this are welcome.
>
> Did you try to start jackd with -p64 instead of -p1024
A good argument, because when I made tests in the past for the USB MIDI,
things become better at >= -p256 (when I had this Windows test install
latency for the EWX 24/96 audio was less high than for Linux). The
problem here is, that I need at least -p512 and even than I'm not safe
regarding to issues for JACK audio, that's why I used -p1024 instead of
-p512. For a test -p64 should work, but when recording music I would
need to increase it step by step until a minimum of -p512.
I'm sorry; don't understand that. Are you getting [audio] x-runs or what
is the problem using -p64 (or even -p32)? I was hinting that the audible midi-jitter could
be a result of
midi-messages getting 'quantizied' to jack-periods.
It seems to be like that. Take a look at my email with the
subject:
Correlation of alsa -p value and hw
MIDI jitter
> A JACK-MIDI app which does not honor 'jack_midi_event_t->time' but
> simply processes all queued midi-events on each jack_process_callback()
> will result in the symptoms you describe (snare & kick on the same
> beat). One example of such an app is "a2j". I did use Qtractor, but had the same issue when
using Rosegarden a long
time ago. But we are talking about ALSA MIDI to the hardware
MIDInterface?!
Originally i was only talking about JACK-MIDI apps.
IIRC when I did tests for the USB MIDI with -p64 or
even -p125 (I'm not
sure) it theoretically did work, but this isn't a solution, because at
some point JACK audio will fail.
How does it fail? x-runs?
JACKd works quite robust here with the UA25 and FA101 at 64fpp.
On a todo list, but there seems to be a correlation to JACK audio. > using JACK-midi, I've encountered a
similar issue with fluidsynth always
> synchronizing note-start/ends to jack cycles.
>
> Simply lowering the frames-per-period got me playing again so I did not
> check if it's related to JACK-midi or FluidSynth 1.1.1 in general.
At least FluidSynth DSSI (host is Qtractor) is able to play in unison
with any DSSI or virtual ALSA MIDI and JACK MIDI (-Xseq) synth on my
machine. Just 'in unison' for virtual synth to hw synth there sometimes
is more delay, but just an early reflection like effect.
Note! It was hard to groove when I connected the master keyboard to ALSA
hw MIDI in --> DIRECTLY TO --> ALSA hw MIDI out and this to a 100% ok
drum module. Directly connecting the master keyboard to the drum module
there were no issues.
Aha, by this we can infer that your problem is ALSA or kernel/timing
related.
To verify this, take everything up from there (eg. qtractor, fluidsynth)
out of the picture for now.
1) Use 'amidiplay' to send a some midi-song directly to your
drum-module. -> Is there still audible jitter? 2) Do you
have a Hardware MIDI Sequencer? Have it play a simple
metronome beat and dump incoming MIDI-messages. See if the timestamps of
each midi-note-on message are identically spaced.
C64 and Atari ST are stable, but there are some issues for e.g the
monitor. My VGA isn't slow enough for the Atari. I'll try to do it with
the broken SM124.
> 'aseqdump' (at least version 1.0.22 which I currently use) does not
> print timing-info, 'kmidimon' does. I need to do something else now, but I take time off.
From Friday
(perhaps earlier) until next Sunday noon I could spend the whole days
for this MIDI issue only.
Resume:
I assume that -p64 would solve this 'looooooong early reflection like
effect/async', but then hard disk recording will become impossible.
The target is, that Linux at least replace the Atari ST as sequencer +
an analog 4-Track machine synced by SMPTE. With -p64 4-track recoding
would become impossible.
I'm pretty sure that you can get a stable 64fpp setup, but one thing at
a time. let's keep this thread to MIDI just now. 'Read you later' today or at the latest
on Friday.
enjoy a good long week-end.
> I'll spend the weekend for Linux audio.
>
>>
>>> Cheers!
>>>
>>> Ralf
>>
>> ciao,
>> robin
>
> Cheers!
>
> Ralf
>
3:52 p.m.
Ralf Mardorf wrote:
1.
I disconnected all audio connections for JACK and connected hw MIDI in
to hw MIDI out.
Is this connection through JACK or through ALSA, i.e., does it show up
in the output of "aconnect -l"? From what I understand, JACK's sample-
synchronous timing always adds latency, and might add period-related
jitter depending on the implementation.
Yamaha DX7 --> Alesis D4 results in a 100% musical
groove.
Yamaha DX7 --> PC --> Alesis D4 results in extreme latency,
With a single MIDI loopback cable, the latency test program tests
a "PC --> PC" connection. A more realistic test would be
"PC1 --> PC2 --> PC1" (or just one PC if it has two inputs and two
outputs).
Regards,
Clemens
4:53 p.m.
On Wed, Jul 14, 2010 at 9:52 AM, Clemens Ladisch <clemens(a)ladisch.de> wrote:
Is this connection through JACK or through ALSA, i.e.,
does it show up
in the output of "aconnect -l"? From what I understand, JACK's sample-
synchronous timing always adds latency, and might add period-related
jitter depending on the implementation.
the good stuff adds 1 JACK period of latency to whatever the ALSA
sequencer's direct delivery + the driver does, and zero jitter.
--p
5:21 p.m.
On Wed, 2010-07-14 at 10:53 -0400, Paul Davis wrote:
On Wed, Jul 14, 2010 at 9:52 AM, Clemens Ladisch
<clemens(a)ladisch.de> wrote:
I'm able to confirm this.
If I play a virtual JACK MIDI instrument and a virtual ALSA MIDI
instrument, 'in unison' is 'in unison'.
I dunno if there is any measurable latency or jitter, but there's no
audible latency or audible jitter and no visible jitter for audio
recordings of those virtual instruments.
- Ralf
Offline now
Is this connection through JACK or through ALSA,
i.e., does it show up
in the output of "aconnect -l"? From what I understand, JACK's sample-
synchronous timing always adds latency, and might add period-related
jitter depending on the implementation.
the good stuff adds 1 JACK period of latency to whatever the ALSA
sequencer's direct delivery + the driver does, and zero jitter.
--p
5:24 p.m.
On Wed, 2010-07-14 at 17:21 +0200, Ralf Mardorf wrote:
On Wed, 2010-07-14 at 10:53 -0400, Paul Davis wrote:
PS: Not me playing, Qtractor is playing those instruments for me.
On Wed, Jul 14, 2010 at 9:52 AM, Clemens Ladisch
<clemens(a)ladisch.de> wrote:
I'm able to confirm this.
If I play a virtual JACK MIDI instrument and a virtual ALSA MIDI
instrument, 'in unison' is 'in unison'.
I dunno if there is any measurable latency or jitter, but there's no
audible latency or audible jitter and no visible jitter for audio
recordings of those virtual instruments.
- Ralf Is this connection through JACK or through ALSA,
i.e., does it show up
in the output of "aconnect -l"? From what I understand, JACK's sample-
synchronous timing always adds latency, and might add period-related
jitter depending on the implementation.
the good stuff adds 1 JACK period of latency to whatever the ALSA
sequencer's direct delivery + the driver does, and zero jitter.
--p
Offline now
5:27 p.m.
On Wed, 2010-07-14 at 17:24 +0200, Ralf Mardorf wrote:
On Wed, 2010-07-14 at 17:21 +0200, Ralf Mardorf
wrote:
> On Wed, 2010-07-14 at 10:53 -0400, Paul Davis wrote:
> > On Wed, Jul 14, 2010 at 9:52 AM, Clemens Ladisch <clemens(a)ladisch.de>
wrote:
> > > Is this connection through JACK or through ALSA, i.e., does it show up
> > > in the output of "aconnect -l"? From what I understand,
JACK's sample-
> > > synchronous timing always adds latency, and might add period-related
> > > jitter depending on the implementation.
> >
> > the good stuff adds 1 JACK period of latency to whatever the ALSA
PPS:
A misunderstanding by me?
> > sequencer's direct delivery + the driver
does, and zero jitter.
Is there JACK MIDI for hw MIDI too, but only for virtual synth?
- Ralf
*Offline now*
5:40 p.m.
On 07/14/2010 05:27 PM, Ralf Mardorf wrote:
On Wed, 2010-07-14 at 17:24 +0200, Ralf Mardorf
wrote:
No, JACK-MIDI is a protocol in software.
There are bridges to hardware which go connect either via ALSA-sequencer
or raw-ALSA interface to the MIDI hardware.
JACKd itself includes those bridges (-Xseq, -Rraw) and there are also
stand-alone apps (fi a2jmidi_bridge, a2jmidid,..) which can do the same.
On Wed, 2010-07-14 at 17:21 +0200, Ralf Mardorf
wrote:
> On Wed, 2010-07-14 at 10:53 -0400, Paul Davis wrote:
>> On Wed, Jul 14, 2010 at 9:52 AM, Clemens Ladisch <clemens(a)ladisch.de>
wrote:
>>> Is this connection through JACK or through ALSA, i.e., does it show up
>>> in the output of "aconnect -l"? From what I understand, JACK's
sample-
>>> synchronous timing always adds latency, and might add period-related
>>> jitter depending on the implementation.
>>
>> the good stuff adds 1 JACK period of latency to whatever the ALSA
PPS:
A misunderstanding by me?
>> sequencer's direct delivery + the
driver does, and zero jitter.
Is there JACK MIDI for hw MIDI too, but only for virtual synth? - Ralf
*Offline now*
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev(a)lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev
5:11 p.m.
On Wed, 2010-07-14 at 15:52 +0200, Clemens Ladisch wrote:
I've got 1 USB MIDI and two PCI MIDI by 2 Terratec EWX 24/96 Envy24
based sound cards. I'll avoid to ever connect the USB MIDI to my machine
again (as I'll avoid to install ever a Windows to it again ;).
Next month I could buy another MIDI adaptor cable and run
alsa-midi-latency-test by using both PCI cards.
I bring myself to connect the USB MIDI one more time ;).
64 Studio 3.3 alpha
$ su -c "poff dsl-provider"
$ su -c "cpufreq-selector -g performance"
$ uname -a
Linux 64studio 2.6.31-2-multimedia-amd64 #1 SMP PREEMPT RT Thu Oct 1
16:14:20 BST 2009 x86_64 GNU/Linux.
$ alsa-midi-latency-test -l
Port Client name Port name
14:0 Midi Through Midi Through Port-0
16:0 TerraTec EWX24/96 TerraTec EWX24/96 MIDI
20:0 USB Device 0x170b:0x11 USB Device 0x170b:0x11 MIDI 1
24:0 TerraTec EWX24/96 TerraTec EWX24/96 MIDI
########################################################################
### ONE OF THE PCI CARDS
########################################################################
$ alsa-midi-latency-test -Rrw=5 -i16:0 -o16:0
Ralf Mardorf wrote:
Qtractor at the moment is ALSA MIDI only and I even didn't use the -Xseq
bridge.
1.
I disconnected all audio connections for JACK and connected hw MIDI in
to hw MIDI out.
Is this connection through JACK or through ALSA, i.e., does it show up
in the output of "aconnect -l"? From what I understand, JACK's sample-
synchronous timing always adds latency, and might add period-related
jitter depending on the implementation. Yamaha DX7
--> Alesis D4 results in a 100% musical groove.
Yamaha DX7 --> PC --> Alesis D4 results in extreme latency,
With a single MIDI loopback cable, the latency test program tests
a "PC --> PC" connection. A more realistic test would be
"PC1 --> PC2 --> PC1" (or just one PC if it has two inputs and two
outputs). alsa-midi-latency-test 0.0.3
set_realtime_priority(SCHED_FIFO, 99).. done.
clock resolution: 0.000000001 s
sampling 10000 midi latency values - please wait ...
press Ctrl+C to abort test
sample; latency_ms; latency_ms_worst
0; 1.05; 1.05
787; 1.06; 1.06
1227; 1.06; 1.06
8738; 1.07; 1.07
9999; 1.00; 1.07
done.
latency distribution:
...
1.0 - 1.1 ms: 9992
##################################################
1.1 - 1.2 ms: 8 #
SUCCESS
best latency was 0.99 ms
worst latency was 1.07 ms, which is great.
########################################################################
### THE USB MIDI WITH AN UNLUCKY ENTRY FOR THE RTIRQ SCRIPT
########################################################################
Usually I keep Rui's entries for the script.
$ cat /etc/default/rtirq | grep RTIRQ
RTIRQ_NAME_LIST="rtc snd i8042"
RTIRQ_PRIO_HIGH=98
RTIRQ_PRIO_DECR=5
RTIRQ_RESET_ALL=0
RTIRQ_NON_THREADED="rtc snd"
# RTIRQ_HIGH_LIST="timer"
$ alsa-midi-latency-test -Rrw=5 -i20:0 -o20:0
alsa-midi-latency-test 0.0.3
set_realtime_priority(SCHED_FIFO, 99).. done.
clock resolution: 0.000000001 s
sampling 10000 midi latency values - please wait ...
press Ctrl+C to abort test
sample; latency_ms; latency_ms_worst
0; 2.21; 2.21
9999; 1.99; 2.21
done.
latency distribution:
...
1.9 - 2.0 ms: 2 #
2.0 - 2.1 ms: 9997
##################################################
...
2.2 - 2.3 ms: 1 #
SUCCESS
best latency was 1.95 ms
worst latency was 2.21 ms, which is great.
########################################################################
### PCI MIDI out --> USB MIDI in
########################################################################
$ alsa-midi-latency-test -Rrw=5 -i20:0 -o16:0
alsa-midi-latency-test 0.0.3
set_realtime_priority(SCHED_FIFO, 99).. done.
clock resolution: 0.000000001 s
sampling 10000 midi latency values - please wait ...
press Ctrl+C to abort test
sample; latency_ms; latency_ms_worst
0; 2.03; 2.03
186; 2.04; 2.04
2726; 2.04; 2.04
9999; 1.99; 2.04
done.
latency distribution:
...
1.9 - 2.0 ms: 2 #
2.0 - 2.1 ms: 9998
##################################################
SUCCESS
best latency was 1.92 ms
worst latency was 2.04 ms, which is great.
########################################################################
### USB MIDI out --> PCI MIDI in
########################################################################
$ alsa-midi-latency-test -Rrw=5 -i16:0 -o20:0
alsa-midi-latency-test 0.0.3
set_realtime_priority(SCHED_FIFO, 99).. done.
clock resolution: 0.000000001 s
sampling 10000 midi latency values - please wait ...
press Ctrl+C to abort test
sample; latency_ms; latency_ms_worst
0; 1.14; 1.14
1; 1.93; 1.93
2; 1.99; 1.99
5; 2.00; 2.00
6; 2.00; 2.00
13; 2.01; 2.01
22; 2.03; 2.03
36; 2.03; 2.03
51; 2.03; 2.03
65; 2.03; 2.03
265; 2.04; 2.04
1160; 2.04; 2.04
2267; 2.07; 2.07
9999; 1.96; 2.07
done.
latency distribution:
...
1.1 - 1.2 ms: 1 #
...
1.9 - 2.0 ms: 31 #
2.0 - 2.1 ms: 9967
##################################################
2.1 - 2.2 ms: 1 #
SUCCESS
best latency was 1.14 ms
worst latency was 2.07 ms, which is great.
$ cd /etc/init.d
$ ./rtirq status
PID CLS RTPRIO NI PRI %CPU STAT COMMAND
388 FF 95 - 135 0.0 S< irq/8-rtc0
1119 FF 90 - 130 0.0 S< irq/21-ICE1712
1115 FF 89 - 129 0.0 S< irq/20-ICE1712
381 FF 85 - 125 0.0 S< irq/1-i8042
380 FF 84 - 124 0.0 S< irq/12-i8042
102 FF 50 - 90 0.0 S< irq/9-acpi
539 FF 50 - 90 0.0 S< irq/16-ohci_hcd
588 FF 50 - 90 0.0 S< irq/19-ehci_hcd
590 FF 50 - 90 0.0 S< irq/22-ahci
601 FF 50 - 90 0.0 S< irq/14-ide0
603 FF 50 - 90 0.0 S< irq/17-ohci_hcd
604 FF 50 - 90 0.0 S< irq/22-ohci1394
608 FF 50 - 90 0.0 S< irq/18-ohci_hcd
611 FF 50 - 90 0.0 S< irq/17-ohci_hcd
614 FF 50 - 90 0.0 S< irq/18-ohci_hcd
943 FF 50 - 90 0.0 S< irq/7-parport0
1670 FF 50 - 90 0.2 S< irq/18-nvidia
1984 FF 50 - 90 0.0 S< irq/26-eth0
4 FF 49 - 89 0.0 S< sirq-high/0
5 FF 49 - 89 0.0 S< sirq-timer/0
6 FF 49 - 89 0.0 S< sirq-net-tx/0
7 FF 49 - 89 0.0 S< sirq-net-rx/0
8 FF 49 - 89 0.0 S< sirq-block/0
9 FF 49 - 89 0.0 S< sirq-tasklet/0
10 FF 49 - 89 0.0 S< sirq-sched/0
11 FF 49 - 89 0.0 S< sirq-hrtimer/0
12 FF 49 - 89 0.0 S< sirq-rcu/0
18 FF 49 - 89 0.0 S< sirq-high/1
19 FF 49 - 89 0.0 S< sirq-timer/1
20 FF 49 - 89 0.0 S< sirq-net-tx/1
21 FF 49 - 89 0.0 S< sirq-net-rx/1
22 FF 49 - 89 0.0 S< sirq-block/1
23 FF 49 - 89 0.2 S< sirq-tasklet/1
24 FF 49 - 89 0.0 S< sirq-sched/1
25 FF 49 - 89 0.0 S< sirq-hrtimer/1
26 FF 49 - 89 0.0 S< sirq-rcu/1
- Ralf
Regards,
Clemens
7:56 p.m.
New subject: Tests directly routing pc's midi-in to midi-out (was: Re: ALSA MIDI latency test results are far away from reality)
You're posting a lot of information, but I'm going to ask some stupid questions
anyway - just trying not to jump to conclusions before getting a crystal-clear
picture of your setup.
On Wed, Jul 14, 2010 at 03:23:03PM +0200, Ralf Mardorf wrote:
1.
I disconnected all audio connections for JACK and connected hw MIDI in
to hw MIDI out. connected the DX7 MIDI out directly to the D4 MIDI in and
then I reconnected to the PCI card.
The difference is alarming :(.
Yamaha DX7 --> Alesis D4 results in a 100% musical groove.
Yamaha DX7 --> PC --> Alesis D4 results in extreme latency
So here you're directly routing the MIDI IN to the MIDI OUT, and experiencing
latency. Are you using JACK here, or directly ALSA? In other words, are you
connecting 'in' to 'out' in the qjackctl 'MIDI' tab or in the
'ALSA' tab?
Regards,
Arnout
8:09 p.m.
New subject: Tests directly routing pc's midi-in to midi-out (was: Re: ALSA MIDI latency test results are far away from reality)
On Wed, 2010-07-14 at 19:56 +0200, Arnout Engelen wrote:
You're posting a lot of information, but I'm
going to ask some stupid questions
anyway - just trying not to jump to conclusions before getting a crystal-clear
picture of your setup.
On Wed, Jul 14, 2010 at 03:23:03PM +0200, Ralf Mardorf wrote:
Now I'm really short in time, so very minimalist:
Mobo: ASUS M2A-VM HDMI, a while ago the BIOS was up-to-date, I guess
it's still up-to-date
Integrated graphics ATI Radeon X1250-based replaced by a NVIDI Geforce
7200GS.
# hwinfo --cpu
01: None 00.0: 10103 CPU
[Created at cpu.301]
Unique ID: rdCR.j8NaKXDZtZ6
Hardware Class: cpu
Arch: X86-64
Vendor: "AuthenticAMD"
Model: 15.107.2 "AMD Athlon(tm) X2 Dual Core Processor BE-2350"
Features:
fpu,vme,de,pse,tsc,msr,pae,mce,cx8,apic,sep,mtrr,pge,mca,cmov,pat,pse36,clflush,mmx,fxsr,sse,sse2,ht,syscall,nx,mmxext,fxsr_opt,rdtscp,lm,3dnowext,3dnow,rep_good,extd_apicid,pni,cx16,lahf_lm,cmp_legacy,svm,extapic,cr8_legacy,3dnowprefetch
Clock: 2100 MHz
BogoMips: 4199.32
Cache: 512 kb
Units/Processor: 2
RAM: 2GB
Sound cards: 2x Terratec EWX 24/96 just stereo IOs, Envy24, not as one
virtual card, I'm only using one card at the moment
Not connected anymore: Swissonic USB MIDI IO
No USB devices, e.g. keyboard and mouse are PS/2.
I'm connecting MIDI in the Qtractor (quasi QjackCtl) ALSA MIDI tab.
To be continued tomorrow or on Friday.
Thank you!
Cheers!
Ralf
1.
I disconnected all audio connections for JACK and connected hw MIDI in
to hw MIDI out. connected the DX7 MIDI out directly to the D4 MIDI in and
then I reconnected to the PCI card.
The difference is alarming :(.
Yamaha DX7 --> Alesis D4 results in a 100% musical groove.
Yamaha DX7 --> PC --> Alesis D4 results in extreme latency
So here you're directly routing the MIDI IN to the MIDI OUT, and experiencing
latency. Are you using JACK here, or directly ALSA? In other words, are you
connecting 'in' to 'out' in the qjackctl 'MIDI' tab or in the
'ALSA' tab?
Regards,
Arnout
9:37 p.m.
New subject: Tests directly routing pc's midi-in to midi-out (was: Re: ALSA MIDI latency test results are far away from reality)
On Wed, Jul 14, 2010 at 08:09:29PM +0200, Ralf Mardorf wrote:
On Wed, 2010-07-14 at 19:56 +0200, Arnout Engelen
wrote:
OK, if that's causing noticable latency, there's something odd going on - and
we should first see if we can fix this: layering more stuff (jack, a2j,
fluidsynth, qtractor etc) on top of this (apparently) weak foundation will
just confuse us.
Before finding out how to prevent 'noticable latency' for this use case, I'd
say it would be good to try and quantify this for a bit.
I took a MIDI Keyboard (m-audio keystation) and a Synth (Yamaha VL70-m),
connected them to each other directly, put a mic close to the keyboard, and
hit a key repeatedly with my nail.
The recording has a nice plastic 'tick' of me hitting the key with my nail,
and the softsynth sound starting a fraction of a second later. Looking with
audacity, the total nail-to-synthsound latency is about 20-26ms.
Then I plugged the synth into my USB audio/MIDI card (Edirol UA-25EX) and
connected the MIDI keyboard to my laptop (directly with USB).
Did the same test again, recorded it, and the nail-to-synthsound latency now
seems to be rougly in the 23-26ms range.
To *me*, this doesn't really seem to be a very noticable/problematic latency -
but I'm not a keyboard player, I might not be so sensitive. I remember playing
a MIDI wind controller at different latencies (I'm a saxophone player) - I'm
not sure if I could *hear* it, but I could sure *feel* the difference.
The wavs are at http://arnout.engelen.eu/files/dev/linuxmusicians/latencytests/
for your enjoyment. Such beautiful music!
It might be interesting if you could make similar recordings - see what kind
of latency gets unacceptable, if the latency is mostly constant or very
jittery, if it's much bigger than here or that you're just more sensitive than
me, etc.
Arnout
(the laptop used in these tests is a 2ghz single-core debian machine without
much tuning - the kernel doesn't even have preemption enabled, let alone the
-rt patch)
On Wed, Jul 14, 2010 at 03:23:03PM +0200, Ralf
Mardorf wrote:
I'm connecting MIDI in the Qtractor (quasi QjackCtl) ALSA MIDI tab. I disconnected all audio connections for JACK and
connected hw MIDI in
to hw MIDI out. connected the DX7 MIDI out directly to the D4 MIDI in and
then I reconnected to the PCI card.
The difference is alarming :(.
Yamaha DX7 --> Alesis D4 results in a 100% musical groove.
Yamaha DX7 --> PC --> Alesis D4 results in extreme latency
So here you're directly routing the MIDI IN to the MIDI OUT, and
experiencing latency. Are you using JACK here, or directly ALSA? In other
words, are you connecting 'in' to 'out' in the qjackctl 'MIDI'
tab or in
the 'ALSA' tab?
11:21 p.m.
New subject: Tests directly routing pc's midi-in to midi-out (was: Re: ALSA MIDI latency test results are far away from reality)
On Wed, 2010-07-14 at 21:37 +0200, Arnout Engelen wrote:
On Wed, Jul 14, 2010 at 08:09:29PM +0200, Ralf Mardorf
wrote:
Hahaha, because the keys of my old metal case DX7 are very loud, I was
able to halfway go on grooving ;). I'm neither a keyboarder nor a
drummer, but a guitarist, anyway, playing with the right hand a ride
cymbal and with the left hand kick and snare is ok for me.
I don't need to record it, the sound of the keys came before the sound
of the sound module and there definitive never was played a sound,
before I touched the keys ;) ... for the sequencer I'm not sure if
events wont be played before they should be played ... and only for the
hw MIDI, internal the studio in the box everything is ok.
On Wed, 2010-07-14 at 19:56 +0200, Arnout Engelen
wrote:
OK, if that's causing noticable latency, there's something odd going on - and
we should first see if we can fix this: layering more stuff (jack, a2j,
fluidsynth, qtractor etc) on top of this (apparently) weak foundation will
just confuse us.
Before finding out how to prevent 'noticable latency' for this use case, I'd
say it would be good to try and quantify this for a bit.
I took a MIDI Keyboard (m-audio keystation) and a Synth (Yamaha VL70-m),
connected them to each other directly, put a mic close to the keyboard, and
hit a key repeatedly with my nail. On Wed, Jul 14, 2010 at 03:23:03PM +0200, Ralf
Mardorf wrote:
I'm connecting MIDI in the Qtractor (quasi QjackCtl) ALSA MIDI tab. I disconnected all audio connections for JACK and
connected hw MIDI in
to hw MIDI out. connected the DX7 MIDI out directly to the D4 MIDI in and
then I reconnected to the PCI card.
The difference is alarming :(.
Yamaha DX7 --> Alesis D4 results in a 100% musical groove.
Yamaha DX7 --> PC --> Alesis D4 results in extreme latency
So here you're directly routing the MIDI IN to the MIDI OUT, and
experiencing latency. Are you using JACK here, or directly ALSA? In other
words, are you connecting 'in' to 'out' in the qjackctl 'MIDI'
tab or in
the 'ALSA' tab? The recording has a nice plastic 'tick' of me
hitting the key with my nail,
and the softsynth sound starting a fraction of a second later. Looking with
audacity, the total nail-to-synthsound latency is about 20-26ms.
I did something similar for my USB MIDI interface. I recorded short
sinus audio impulses and watched the waveforms by completely zooming in
using Audacity, but there's still the ambient noise level that makes it
impossible to see the absolut beginning of a signal. Jitter was around
+- 4 ms as far as I was able to interpret the waveforms. A short and
loud sinus impulse is the best signal I could produce to see a
difference to the ambient nose level. I didn't do this test for the PCI
MIDI.
Then I plugged the synth into my USB audio/MIDI card
(Edirol UA-25EX) and
connected the MIDI keyboard to my laptop (directly with USB).
Did the same test again, recorded it, and the nail-to-synthsound latency now
seems to be rougly in the 23-26ms range.
To *me*, this doesn't really seem to be a very noticable/problematic latency
That's right, it will become an issue when you will record HiHat, Snare,
Kick, Bass etc., the rhythm group one after the other or if you wish to
double a kick by two sounds etc..
-
but I'm not a keyboard player, I might not be so sensitive. I remember playing
a MIDI wind controller at different latencies (I'm a saxophone player) - I'm
not sure if I could *hear* it, but I could sure *feel* the difference.
exactly, as soo as you play an instrument while there is latency and/or
jitter the feeling gets lost.
The wavs are at http://arnout.engelen.eu/files/dev/linuxmusicians/latencytests/
for your enjoyment. Such beautiful music!
It might be interesting if you could make similar recordings - see what kind
of latency gets unacceptable, if the latency is mostly constant or very
jittery, if it's much bigger than here or that you're just more sensitive than
me, etc.
At least I could record FluidSynth + external MIDI devices in unsion or
do the finger-nail-microphone test ...
Arnout
(the laptop used in these tests is a 2ghz single-core debian machine without
much tuning - the kernel doesn't even have preemption enabled, let alone the
-rt patch)
I've got a long todo list :( now. If I should forget something I should
do, aske me again to do it ;).
- Ralf
11:29 p.m.
New subject: Tests directly routing pc's midi-in to midi-out (was: Re: ALSA MIDI latency test results are far away from reality)
Jitter was around
+- 4 ms as far as I was able to interpret the waveforms.
Or it was at 4 ms = +- 2ms or something like that. This is a delay that
isn't audible for day-today-day audio events, but it can brake a groove
easily. Not if all instruments do have the same jitter, but if just one
instruments has got this jitter or all instruments do have different
jitter of this value.
11:43 p.m.
New subject: Tests directly routing pc's midi-in to midi-out (was: Re: ALSA MIDI latency test results are far away from reality)
On Wed, Jul 14, 2010 at 11:28:54PM +0200, Ralf Mardorf wrote:
Or it was at 4 ms = +- 2ms or something like that.
This is a delay that
isn't audible for day-today-day audio events, but it can brake a groove
easily.
You keep repeating this, but so far I haven't seen a shred
of verifyable evidence to support this claim.
Ciao,
--
Je veux que la mort me trouve plantant mes choux, mais
nonchalant d’elle, et encore plus de mon jardin imparfait.
(Michel de Montaigne)
11:54 p.m.
New subject: Tests directly routing pc's midi-in to midi-out (was: Re: ALSA MIDI latency test results are far away from reality)
On Wed, 2010-07-14 at 23:43 +0200, fons(a)kokkinizita.net wrote:
On Wed, Jul 14, 2010 at 11:28:54PM +0200, Ralf Mardorf
wrote:
I could record audio for kick, snare, hi hat and bass one after the
other and mix it to one rhythm group and additionally I could record all
instruments at the same time and send the recordings to you and you
could do the same by yourself. It's also hard to say, if there isn't
more jitter, but 4 ms. At what point starts the attack of a signal
within the ambient noise level?
At least I could record FluidSynth DSSI in unison played to the Alesis
D4 by using different -p values. I'm sure everybody would be able to
here the problem.
'Ears made of gold' (a German idiom) aren't needed to hear it.
- Ralf
Or it was at 4 ms = +- 2ms or something like
that. This is a delay that
isn't audible for day-today-day audio events, but it can brake a groove
easily.
You keep repeating this, but so far I haven't seen a shred
of verifyable evidence to support this claim.
Ciao,
15 Jul
15 Jul
12:46 a.m.
New subject: Tests directly routing pc's midi-in to midi-out (was: Re: ALSA MIDI latency test results are far away from reality)
On Wed, Jul 14, 2010 at 11:54:35PM +0200, Ralf Mardorf wrote:
I could record audio for kick, snare, hi hat and bass
one after the
other and mix it to one rhythm group and additionally I could record all
instruments at the same time and send the recordings to you and you
could do the same by yourself.
That is not a valid test. If the soft instrument that generates
these sounds aligns MIDI events to Jack periods, and you are using
a period size of 1024 as you say you are, it proves nothing at all.
Apart from that, it remains to be seen if *real* timing errors of
+/- 2 ms do 'destroy the groove'. To test this, make the same
recording
- without jitter,
- with 1 ms jitter,
- with 2 ms jitter,
- with 3 ms jitter.
and check if listeners are able to identify which is which,
or at least to put them into order.
What you have been doing so far is compare an 'exact' version
with one that has some unkown and uncontrolled errors. You could
'prove' anything you want in that way.
You are just jumping to conclusions and making gratituous
generalisations.
Ciao,
--
Je veux que la mort me trouve plantant mes choux, mais
nonchalant d’elle, et encore plus de mon jardin imparfait.
(Michel de Montaigne)
1:15 a.m.
New subject: Tests directly routing pc's midi-in to midi-out (was: Re: ALSA MIDI latency test results are far away from reality)
On Thu, 2010-07-15 at 00:46 +0200, fons(a)kokkinizita.net wrote:
On Wed, Jul 14, 2010 at 11:54:35PM +0200, Ralf Mardorf
wrote:
I know very gifted musicians who do like me and they always 'preach'
that I should stop using modern computers and I don't know much averaged
people. So the listeners in my flat for sure would be able to hear even
failure that I'm unable to hear.
I could record audio for kick, snare, hi hat and
bass one after the
other and mix it to one rhythm group and additionally I could record all
instruments at the same time and send the recordings to you and you
could do the same by yourself.
That is not a valid test. If the soft instrument that generates
these sounds aligns MIDI events to Jack periods, and you are using
a period size of 1024 as you say you are, it proves nothing at all.
Apart from that, it remains to be seen if *real* timing errors of
+/- 2 ms do 'destroy the groove'. To test this, make the same
recording
- without jitter,
- with 1 ms jitter,
- with 2 ms jitter,
- with 3 ms jitter.
and check if listeners are able to identify which is which,
or at least to put them into order. What you have been doing so far is compare an
'exact' version
with one that has some unkown and uncontrolled errors. You could
'prove' anything you want in that way.
You are just jumping to conclusions and making gratituous
generalisations.
Ciao,
No doubt about it, I'm speculating.
Earlier I send somebody an email off-list (see below), anyway, even when
playing live by using ALSA MIDI just thru, there is latency, with or
without jitter, but off course without negative delay ;).
My speculations might be wrong. But there are audible issues and I'm
sure that even non-musicians are able to hear it, unfortunately I'm some
kind of freak, all the people I could ask to listen to this issues are
highly gifted musicians, unfortunately the averaged German soccer, radio
prime time, heavy rotation, music listening audience is beyond the
people that I know.
Anyway. this crowd shouldn't be the benchmark for good music. Am I
wrong?
I don't no what's bad, but something is absolutely bad for hw MIDI.
-------- Forwarded Message --------
From: Ralf Mardorf
To: [snip]
Subject: [off-list]
Date: Thu, 15 Jul 2010 00:22:17 +0200
ASAP, I guess later today (here it's 00:15 o'clock), I'll run jackd,
resp. the alsa driver with 4096frames/period at 44.1KHz and record the
external synth to the left and the virtual synth to the right channel.
This should give a clear result, regarding to the 'event happened,
before it was triggert' issue. I guess even for quantum physics such
phenomena are caused because of technical issues.
:D
Cheers!
Ralf
9:57 a.m.
New subject: Tests directly routing pc's midi-in to midi-out (was: Re: ALSA MIDI latency test results are far away from reality)
On Thu, Jul 15, 2010 at 01:14:45AM +0200, Ralf Mardorf wrote:
I'm sure they would be sensitive to bad timing. But that's not
the question. Would they be able to identify the recordings listed
above ? Until you try it you won't know, and your claim that 2 ms
of jitter 'destroys the groove' is pure conjecture.
Apart from
that, it remains to be seen if *real* timing errors of
+/- 2 ms do 'destroy the groove'. To test this, make the same
recording
- without jitter,
- with 1 ms jitter,
- with 2 ms jitter,
- with 3 ms jitter.
and check if listeners are able to identify which is which,
or at least to put them into order.
I know very gifted musicians who do like me and they always 'preach'
that I should stop using modern computers and I don't know much averaged
people. So the listeners in my flat for sure would be able to hear even
failure that I'm unable to hear. Anyway. this crowd shouldn't be the benchmark for
good music. Am I
wrong?
It's not about what 'good music' is. The question is if midi jitter
of 2 ms does degrade the quality of a rendering.
Ciao,
--
Je veux que la mort me trouve plantant mes choux, mais
nonchalant d’elle, et encore plus de mon jardin imparfait.
(Michel de Montaigne)
9:57 a.m.
New subject: Tests directly routing pc's midi-in to midi-out (was: Re: ALSA MIDI latency test results are far away from reality)
On Thursday 15 July 2010 01:14:45 Ralf Mardorf wrote:
On Thu, 2010-07-15 at 00:46 +0200,
fons(a)kokkinizita.net wrote:
You really should do that test first before speculating about the outcome and
your audience.
You would expect Audiophiles to spot the "super sounding" denon cables by
listening, right? Yet a blind test showed the opposite. The test was to
identify which audio take was played with denon-cables, el-cheapo cables from
walmart and a bended cloth-hanger. If they where as good as they claimed, the
denon-cable should get hits with probability significantly better then 1/3,
otherwise its just luck.
Guess what the outcome was: There was a significant hit: But they spotted the
cloth-hanger as the denon-cable. Thats what real experts do...
Do the listening test with as many people as possible and then show the
results. And only afterwards start the speculations what the reason and the
effects might be. (Thats called science btw.)
Have fun,
Arnold
Apart from that, it remains to be seen if *real*
timing errors of
+/- 2 ms do 'destroy the groove'. To test this, make the same
recording
- without jitter,
- with 1 ms jitter,
- with 2 ms jitter,
- with 3 ms jitter.
and check if listeners are able to identify which is which,
or at least to put them into order.
I know very gifted musicians who do like me
and they always 'preach'
that I should stop using modern computers and I don't know much averaged
people. So the listeners in my flat for sure would be able to hear even
failure that I'm unable to hear.
16 Jul
16 Jul
11:26 a.m.
New subject: Tests directly routing pc's midi-in to midi-out (was: Re: ALSA MIDI latency test results are far away from reality)
On Thu, 2010-07-15 at 09:56 +0200, Arnold Krille wrote:
On Thursday 15 July 2010 01:14:45 Ralf Mardorf wrote:
Btw. I tested my own music.
First I played inside songs from other people a Ralf-mastering of my own
music.
Most people didn't like my song.
Some weeks later I played the same song inside other songs from other
people by a loudness-war-mastering.
Most people liked the song.
Playing the same song two times can't be called heavy rotation, hence
they were not accustomed to my song, but they need a bad mastering to be
fine with this song.
A blind study is useless regarding to musical issues.
Or do you think we should start mixing music optimised to loudness,
because tests show that the audience prefers music without dynamic?
;)
Ralf
On Thu, 2010-07-15 at 00:46 +0200,
fons(a)kokkinizita.net wrote:
You really should do that test first before speculating about the outcome and
your audience.
You would expect Audiophiles to spot the "super sounding" denon cables by
listening, right? Yet a blind test showed the opposite. The test was to
identify which audio take was played with denon-cables, el-cheapo cables from
walmart and a bended cloth-hanger. If they where as good as they claimed, the
denon-cable should get hits with probability significantly better then 1/3,
otherwise its just luck.
Guess what the outcome was: There was a significant hit: But they spotted the
cloth-hanger as the denon-cable. Thats what real experts do...
Do the listening test with as many people as possible and then show the
results. And only afterwards start the speculations what the reason and the
effects might be. (Thats called science btw.)
Have fun,
Arnold Apart from that, it remains to be seen if *real*
timing errors of
+/- 2 ms do 'destroy the groove'. To test this, make the same
recording
- without jitter,
- with 1 ms jitter,
- with 2 ms jitter,
- with 3 ms jitter.
and check if listeners are able to identify which is which,
or at least to put them into order.
I know very gifted musicians who do like me
and they always 'preach'
that I should stop using modern computers and I don't know much averaged
people. So the listeners in my flat for sure would be able to hear even
failure that I'm unable to hear.
11:47 a.m.
New subject: Tests directly routing pc's midi-in to midi-out (was: Re: ALSA MIDI latency test results are far away from reality)
On Friday 16 July 2010 09:50:39 Ralf Mardorf wrote:
On Thu, 2010-07-15 at 09:56 +0200, Arnold Krille
wrote:
Apples and oranges.
You are working on midi-latency-jitter. Which is measurable. And the test is
when the jitter becomes unbearable.
Taste on the other thing is not measurable and while you could quantify it,
common sense says that taste-minorities are valuable too...
You really should do that test first before
speculating about the outcome
and your audience.
Btw. I tested my own music.
First I played inside songs from other people a Ralf-mastering of my own
music.
Most people didn't like my song.
Some weeks later I played the same song inside other songs from other
people by a loudness-war-mastering.
Most people liked the song.
Playing the same song two times can't be called heavy rotation, hence
they were not accustomed to my song, but they need a bad mastering to be
fine with this song.
A blind study is useless regarding to musical issues. Or do you think we should start mixing music optimised
to loudness,
because tests show that the audience prefers music without dynamic?
Taste-minorities. You play your dynamic-rich songs to fans of classical music
and see their reactions. If you can distinguish the "like it because of
dynamics" from the "don't like it because of rock-vs-classical". Which
just
shows that taste is not measurable.
And no, pop industry doesn't measure taste, it just measures profit.
Have fun,
Arnold
12:06 p.m.
New subject: Tests directly routing pc's midi-in to midi-out (was: Re: ALSA MIDI latency test results are far away from reality)
On Fri, 2010-07-16 at 11:46 +0200, Arnold Krille wrote:
My bad!
Because it's an unfair 'analogy'.
OTOH, industry does measure averaged taste, regarding to profit.
Arnold, I respect your opinion, because I guess you don't like
recordings without dynamic too. Btw. I'm not a hardliner and a fan of
Bob Katz.
BUT!
It's impossible to do neutral measurements and from a democratically
worldview listening to recordings without dynamic is the winner.
Today I listened to a very good free jazz recording, but even this
marginal group tends to do masterings that are borderline.
And I'm sure, my neighbours aren't able to understand this kind of
music, I bet they were near top call the psychiatric ambulance when I
listende to this free jazz, while they blow the vuvuzela the whole day.
IMO Peter Brötzmann (on Sax) and a friend of mine on the Piano is much
more pleasant, but any vuvuzela players, anyway the averaged opinion is
different to my opinion.
In other words, there's no neutral test regarding to musical issues.
0.00 €
Ralf
--
Is it possible to get an audible difference between white noise and
transposed white noise?
Somewhere in the vacuum I mislaid my endless sized metal plates.
On Friday 16 July 2010 09:50:39 Ralf Mardorf wrote:
Your bad!
On my computer the measurements are ok, but the audible results are bad.
On Thu, 2010-07-15 at 09:56 +0200, Arnold Krille
wrote:
Apples and oranges.
You are working on midi-latency-jitter. Which is measurable. And the test is
when the jitter becomes unbearable.
Taste on the other thing is not measurable and while you could quantify it,
common sense says that taste-minorities are valuable too... You really should do that test first before
speculating about the outcome
and your audience.
Btw. I tested my own music.
First I played inside songs from other people a Ralf-mastering of my own
music.
Most people didn't like my song.
Some weeks later I played the same song inside other songs from other
people by a loudness-war-mastering.
Most people liked the song.
Playing the same song two times can't be called heavy rotation, hence
they were not accustomed to my song, but they need a bad mastering to be
fine with this song.
A blind study is useless regarding to musical issues. Or do you think we should start mixing music
optimised to loudness,
because tests show that the audience prefers music without dynamic?
Taste-minorities. You play your dynamic-rich songs to fans of classical music
and see their reactions. If you can distinguish the "like it because of
dynamics" from the "don't like it because of rock-vs-classical". Which
just
shows that taste is not measurable.
And no, pop industry doesn't measure taste, it just measures profit.
12:19 p.m.
New subject: Tests directly routing pc's midi-in to midi-out (was: Re: ALSA MIDI latency test results are far away from reality)
On Friday 16 July 2010 12:06:02 Ralf Mardorf wrote:
On Fri, 2010-07-16 at 11:46 +0200, Arnold Krille
wrote:
Does it sound bad because of taste or because of something quantifiable?
If the later, your tests are insufficient and you have to extend it. Simple as
that. (Thats why scientists always want more money for devices:)
If the first, you have to a) define good taste and b) if you want to measure it,
you have to do blind-tests or even double blind-tests. And use a test-group as
large as possible.
Arnold
On Friday 16 July 2010 09:50:39 Ralf Mardorf
wrote:
Your bad!
On my computer the measurements are ok, but the audible results are bad. On Thu, 2010-07-15 at 09:56 +0200, Arnold Krille
wrote:
Apples and oranges.
You are working on midi-latency-jitter. Which is measurable. And the test
is when the jitter becomes unbearable.
Taste on the other thing is not measurable and while you could quantify
it, common sense says that taste-minorities are valuable too... You really should do that test first before
speculating about the
outcome and your audience.
Btw. I tested my own music.
First I played inside songs from other people a Ralf-mastering of my
own music.
Most people didn't like my song.
Some weeks later I played the same song inside other songs from other
people by a loudness-war-mastering.
Most people liked the song.
Playing the same song two times can't be called heavy rotation, hence
they were not accustomed to my song, but they need a bad mastering to
be fine with this song.
A blind study is useless regarding to musical issues.
12:46 p.m.
New subject: Tests directly routing pc's midi-in to midi-out (was: Re: ALSA MIDI latency test results are far away from reality)
On Fri, 2010-07-16 at 12:19 +0200, Arnold Krille wrote:
(Thats why scientists always want more money for
devices:)
That's the reason for my signature.
Ignore the ironical question, but the sentence about he metal palates in
the vacuum is a serious ironical statement.
No doubt about your argument regarding to esoteric audio cables, but
timing issues are something that aren't measurable.
A friend has got Huntington's disease, he does very good compositions,
but he isn't able to play those rock songs. His timing is bad, for me
and I'm sure for you too, but for him there are no timing issues.
There is no objective valid timing fluctuation. The musical savant next
door might be much more sensitive than I'm, regarding to the groove, I
don't know ... I guess there doesn't live a musical savant next door,
perhaps I'm this savant ;).
Anyway, forget about my assumptions about ms of jitter. I'm fine with
the C64, Atari ST and all those stand alone sequencers from the 80ies. I
tested did it, but I'm sure I'll be able to hear hear the difference to
my Linux computer ... not when listening to all MIDI instruments played
alone at the same time, but when listening to MIDI instruments + audio
tracks.
I don't care about my neighbours who might be unable to notice a bad
timing, resp. broken groove.
I try to get a home studio equipment, just for my pleasure.
It's not neutral science, it has to fit to my needs.
- Ralf
--
Is it possible to get an audible difference between white noise and
transposed white noise?
Somewhere in the vacuum I mislaid my endless sized metal plates.
12:50 p.m.
New subject: Tests directly routing pc's midi-in to midi-out (was: Re: ALSA MIDI latency test results are far away from reality)
On Fri, 2010-07-16 at 12:46 +0200, Ralf Mardorf wrote:
I tested did it, but I'm sure
Oops, there's a sentence accidentally killed ... sorry, but I'm in a
hurry.
1:02 p.m.
New subject: Tests directly routing pc's midi-in to midi-out (was: Re: ALSA MIDI latency test results are far away from reality)
On Friday 16 July 2010 06:06:02 Ralf Mardorf wrote:
It's impossible to do neutral measurements and
from a democratically
worldview listening to recordings without dynamic is the winner.
My personal take is that I would prefer different mixes for different uses.
When out walking on dangerous streets with my earphones in I have to keep the
volume low if I hope to hear road noise. A mix with wide dynamic range ends
with me not hearing the quiet passages as cars pass but hearing a mix of car
and recording in the loud passages.
So I might want a mix with little dynamic range for this situation. I need to
make some and see if it works out better.
all the best,
drew
1:23 p.m.
New subject: Tests directly routing pc's midi-in to midi-out (was: Re: ALSA MIDI latency test results are far away from reality)
On Fri, 2010-07-16 at 07:02 -0400, drew Roberts wrote:
On Friday 16 July 2010 06:06:02 Ralf Mardorf wrote:
Good argument ;), but regarding to Darwinism you better don't listen to
music while being in the jungle ... 'sometimes it makes me wonder how I
keep from going under' (Grandmaster Flash).
Of course, I like multi-band compressors, e.g. JAMin too. I'm not a Bob
Katz fan or an anti-compressor-hardliner.
I just want to point out that measured results are less important (not
unimportant).
- Ralf
It's impossible to do neutral measurements
and from a democratically
worldview listening to recordings without dynamic is the winner.
My personal take is that I would prefer different mixes for different uses.
When out walking on dangerous streets with my earphones in I have to keep the
volume low if I hope to hear road noise. A mix with wide dynamic range ends
with me not hearing the quiet passages as cars pass but hearing a mix of car
and recording in the loud passages.
So I might want a mix with little dynamic range for this situation. I need to
make some and see if it works out better.
all the best,
drew
1:26 p.m.
New subject: Tests directly routing pc's midi-in to midi-out
On 07/16/2010 11:46 AM, Arnold Krille wrote:
On Friday 16 July 2010 09:50:39 Ralf Mardorf wrote:
Since LAC2010 the bitten fruit is a banned word. You mean bananas &
oranges, don't you?
On Thu, 2010-07-15 at 09:56 +0200, Arnold Krille
wrote:
Apples and oranges. You really should do that test first before
speculating about the outcome
and your audience.
Btw. I tested my own music.
First I played inside songs from other people a Ralf-mastering of my own
music.
Most people didn't like my song.
Some weeks later I played the same song inside other songs from other
people by a loudness-war-mastering.
Most people liked the song.
Playing the same song two times can't be called heavy rotation, hence
they were not accustomed to my song, but they need a bad mastering to be
fine with this song.
A blind study is useless regarding to musical issues. You are working on midi-latency-jitter. Which is
measurable. And the test is
when the jitter becomes unbearable.
Taste on the other thing is not measurable and while you could quantify it,
common sense says that taste-minorities are valuable too...
LOL.
Or do you think we should start mixing music
optimised to loudness,
because tests show that the audience prefers music without dynamic?
Taste-minorities. You play your dynamic-rich songs to fans of classical music
and see their reactions. If you can distinguish the "like it because of
dynamics" from the "don't like it because of rock-vs-classical". Which
just
shows that taste is not measurable.
And no, pop industry doesn't measure taste, it just measures profit. Have fun,
Arnold
We're getting seriously off-topic here. After all, this is developer
list. What happened to the ALSA MIDI Jitter measurements and test-samples?
robin
1:30 p.m.
New subject: Tests directly routing pc's midi-in to midi-out
On Fri, 2010-07-16 at 13:26 +0200, Robin Gareus wrote:
On 07/16/2010 11:46 AM, Arnold Krille wrote:
The blame isn't on Arnold, but me. Test results will come ASAP. Btw. if
you would listen 5 hours to 4-on-the-flour, you probably would welcome
off topics too. Pardon for the OTs.
- Ralf
On Friday 16 July 2010 09:50:39 Ralf Mardorf
wrote:
Since LAC2010 the bitten fruit is a banned word. You mean bananas &
oranges, don't you?
On Thu, 2010-07-15 at 09:56 +0200, Arnold Krille
wrote:
Apples and oranges. You really should do that test first before
speculating about the outcome
and your audience.
Btw. I tested my own music.
First I played inside songs from other people a Ralf-mastering of my own
music.
Most people didn't like my song.
Some weeks later I played the same song inside other songs from other
people by a loudness-war-mastering.
Most people liked the song.
Playing the same song two times can't be called heavy rotation, hence
they were not accustomed to my song, but they need a bad mastering to be
fine with this song.
A blind study is useless regarding to musical issues. You are working on midi-latency-jitter. Which is
measurable. And the test is
when the jitter becomes unbearable.
Taste on the other thing is not measurable and while you could quantify it,
common sense says that taste-minorities are valuable too...
LOL.
Or do you think we should start mixing music
optimised to loudness,
because tests show that the audience prefers music without dynamic?
Taste-minorities. You play your dynamic-rich songs to fans of classical music
and see their reactions. If you can distinguish the "like it because of
dynamics" from the "don't like it because of rock-vs-classical". Which
just
shows that taste is not measurable.
And no, pop industry doesn't measure taste, it just measures profit. Have fun,
Arnold
We're getting seriously off-topic here. After all, this is developer
list. What happened to the ALSA MIDI Jitter measurements and test-samples?
robin
15 Jul
15 Jul
1:46 a.m.
New subject: Tests directly routing pc's midi-in to midi-out (was: Re: ALSA MIDI latency test results are far away from reality)
On Thu, 2010-07-15 at 00:46 +0200, fons(a)kokkinizita.net wrote:
[snip]
What 'we' are able to 'hear' differs to what 'we' are able to
'feel'
while playing an MIDI instrument. After listening 10 minutes to a bad
timing, I'm unable to differ between a bad and a good timing, this is
human. Try to distinguish odours, not two or there but twenty or thirty.
The feeling a musician has got, while playing is also important.
I don't know any pipe organ for a church in Parma, but I'm sure if the
keyboarder pushes a key the sound will be audible at the same time. I
guess, Aeolus will play every note on real time when played by a Linux
sequencer, e.g. Qtractor, but I guess not when played by my master
keyboard, played by an organist. I don't know, I never tested it, but
regarding to what I experienced, I'm sure on my machine there is some
kind of real, serious, very bad timing issue, when using hw MIDI.
10:07 a.m.
New subject: Tests directly routing pc's midi-in to midi-out (was: Re: ALSA MIDI latency test results are far away from reality)
On Thu, Jul 15, 2010 at 01:46:41AM +0200, Ralf Mardorf wrote:
I don't know any pipe organ for a church in Parma,
but I'm sure if the
keyboarder pushes a key the sound will be audible at the same time.
Absoulutely not. Organ pipes take some time before they will sound,
this can easily be 20 ms and considerably more for some. Apart from
that pipes are not all at the same distance from the player, this
again can easily introduce variations of 20 ms or more, even between
pipes of the same rank.
I guess, Aeolus will play every note on real time when
played by a Linux
sequencer, e.g. Qtractor, but I guess not when played by my master
keyboard, played by an organist.
Aeolus doesn't care or even know where the MIDI is coming from.
And it does quantise note on/off to Jack periods. Nobody ever
complained about that.
Ciao,
--
Je veux que la mort me trouve plantant mes choux, mais
nonchalant d’elle, et encore plus de mon jardin imparfait.
(Michel de Montaigne)
8:23 a.m.
New subject: Tests directly routing pc's midi-in to midi-out (was: Re: ALSA MIDI latency test results are far away from reality)
On Wed, Jul 14, 2010 at 11:54:35PM +0200, Ralf Mardorf wrote:
Perhaps you could make a stereo recording, the left channel recording the
mic'ed 'tick' of hitting the trigger, the right channel recording the audio
coming from the speakers? You'd say e.g. a loud hi-hat should be recognisable
enough.
On Wed, 2010-07-14 at 23:43 +0200,
fons(a)kokkinizita.net wrote:
> On Wed, Jul 14, 2010 at 11:28:54PM +0200, Ralf Mardorf wrote:
> > Or it was at 4 ms = +- 2ms or something like that. This is a delay that
> > isn't audible for day-today-day audio events, but it can brake a groove
> > easily.
That would mean my hardware synth (the yamaha vl70-m), connected *directly*
(no PC involved), causes a huge latency (20-26ms) making it utterly unusable
for making a groove - and not just slightly, but by a large margin.
That *could* be (as it's not a drum synth), but it'd be kind of surprising.
You keep
repeating this, but so far I haven't seen a shred
of verifyable evidence to support this claim.
I could record audio for kick, snare, hi hat and bass one after the
other and mix it to one rhythm group and additionally I could record all
instruments at the same time and send the recordings to you and you
could do the same by yourself. It's also hard to say, if there isn't
more jitter, but 4 ms. At what point starts the attack of a signal
within the ambient noise level? At least I could record FluidSynth DSSI in unison
played to the Alesis
D4 by using different -p values. I'm sure everybody would be able to
here the problem.
Let's keep this thread restricted to the situation with only ALSA MIDI in
routed directly to ALSA MIDI OUT - it's getting hard to keep track of what's
going on :).
Arnout
8:26 a.m.
New subject: Tests directly routing pc's midi-in to midi-out
Ralf Mardorf wrote:
On Wed, 2010-07-14 at 19:56 +0200, Arnout Engelen
wrote:
Please make a test without any program using JACK, just connect the
DX7 port to the D4 port with aconnect(gui), and try that.
Regards,
Clemens
On Wed, Jul 14, 2010 at 03:23:03PM +0200, Ralf
Mardorf wrote:
I'm connecting MIDI in the Qtractor (quasi QjackCtl) ALSA MIDI tab. Yamaha DX7 --> Alesis D4 results in a 100%
musical groove.
Yamaha DX7 --> PC --> Alesis D4 results in extreme latency
So here you're directly routing the MIDI IN to the MIDI OUT, and experiencing
latency. Are you using JACK here, or directly ALSA? In other words, are you
connecting 'in' to 'out' in the qjackctl 'MIDI' tab or in the
'ALSA' tab?
10:41 a.m.
New subject: Tests directly routing pc's midi-in to midi-out
On Thu, 2010-07-15 at 08:26 +0200, Clemens Ladisch wrote:
Ralf Mardorf wrote:
I'll test this :).
On Thu, 2010-07-15 at 09:57 +0200, fons(a)kokkinizita.net wrote:
On Wed, 2010-07-14 at 19:56 +0200, Arnout Engelen
wrote:
Please make a test without any program using JACK, just connect the
DX7 port to the D4 port with aconnect(gui), and try that.
Regards,
Clemens On Wed, Jul 14, 2010 at 03:23:03PM +0200, Ralf
Mardorf wrote:
I'm connecting MIDI in the Qtractor (quasi QjackCtl) ALSA MIDI tab. Yamaha DX7 --> Alesis D4 results in a 100%
musical groove.
Yamaha DX7 --> PC --> Alesis D4 results in extreme latency
So here you're directly routing the MIDI IN to the MIDI OUT, and experiencing
latency. Are you using JACK here, or directly ALSA? In other words, are you
connecting 'in' to 'out' in the qjackctl 'MIDI' tab or in the
'ALSA' tab? I'm sure they would be sensitive to bad timing.
But that's not
the question. Would they be able to identify the recordings listed
above ? Until you try it you won't know, and your claim that 2 ms
of jitter 'destroys the groove' is pure conjecture.
Who knows? Perhaps 2ms shown by Audacity are 20ms, because Audacity has
a bug? Perhaps 2ms shown by Audacity are 2ms, but when playing JACK, the
sound card or what ever will add additional jitter?
I can't test the list, because on my machine there is something audible.
On Thu, 2010-07-15 at 09:56 +0200, Arnold Krille wrote:
On Thursday 15 July 2010 01:14:45 Ralf Mardorf wrote:
Perhaps it's not that 2ms, but here are audible issues. As I mentioned before.
Audacity shows 2ms, but JACK, the driver the hardware might add jitter.
FWIW blind tests aren't scientific,just double-blind studies are meaningful. And if
you wish to test cables you need to test the quality after one year, after two years etc..
Anyway, a bad cable might cause a bad sound quality, but not bad timing.
Timing is the meat and potatoes to music.
Regarding to my Linux computer such studies aren't needed. A bad timing is a bad
timing.
At least for the USB MIDI that I'm not using anymore, I made tests with a Windows
install (I don't have this install on my machine anymore, so I can't test the PCI
card with Windows).
The USB MIDI was much better on Windows, even better than the PCI cards at the moment are
on Linux. So I guess, yes I don't know, that the hardware is ok.
- Ralf
On Thu, 2010-07-15 at 00:46 +0200,
fons(a)kokkinizita.net wrote:
You really should do that test first before speculating about the outcome and
your audience.
You would expect Audiophiles to spot the "super sounding" denon cables by
listening, right? Yet a blind test showed the opposite. The test was to
identify which audio take was played with denon-cables, el-cheapo cables from
walmart and a bended cloth-hanger. If they where as good as they claimed, the
denon-cable should get hits with probability significantly better then 1/3,
otherwise its just luck.
Guess what the outcome was: There was a significant hit: But they spotted the
cloth-hanger as the denon-cable. Thats what real experts do...
Do the listening test with as many people as possible and then show the
results. And only afterwards start the speculations what the reason and the
effects might be. (Thats called science btw.)
Have fun,
Arnold Apart from that, it remains to be seen if *real*
timing errors of
+/- 2 ms do 'destroy the groove'. To test this, make the same
recording
- without jitter,
- with 1 ms jitter,
- with 2 ms jitter,
- with 3 ms jitter.
and check if listeners are able to identify which is which,
or at least to put them into order.
I know very gifted musicians who do like me
and they always 'preach'
that I should stop using modern computers and I don't know much averaged
people. So the listeners in my flat for sure would be able to hear even
failure that I'm unable to hear.
11:48 a.m.
New subject: Tests directly routing pc's midi-in to midi-out
On Thu, Jul 15, 2010 at 10:40:53AM +0200, Ralf Mardorf wrote:
On Thu, 2010-07-15 at 09:57 +0200,
fons(a)kokkinizita.net wrote:
Sounds unlikely - but if you post the recording we can check.
Until you try it you won't know, and your
claim that 2 ms of jitter
'destroys the groove' is pure conjecture.
Who knows? Perhaps 2ms shown by Audacity are 20ms, because Audacity has
a bug? Perhaps 2ms shown by Audacity are 2ms, but when
playing JACK, the
sound card or what ever will add additional jitter?
You claimed the latency/timing was obviously noticably broken without needing
'golden ears' even without JACK, right? Let's first try to get this reliable
without JACK, just ALSA, then we can add other things to the mix later. If
this is not possible, anything 'on top of' this is doomed, too. I doubt it
though.
Arnout
I can't test the list, because on my machine there
is something audible.
On Thu, 2010-07-15 at 09:56 +0200, Arnold Krille wrote:
On Thursday 15 July 2010 01:14:45 Ralf Mardorf
wrote:
Perhaps it's not that 2ms, but here are audible issues. As I mentioned before.
Audacity shows 2ms, but JACK, the driver the hardware might add jitter.
FWIW blind tests aren't scientific,just double-blind studies are meaningful. And if
you wish to test cables you need to test the quality after one year, after two years etc..
Anyway, a bad cable might cause a bad sound quality, but not bad timing.
Timing is the meat and potatoes to music.
Regarding to my Linux computer such studies aren't needed. A bad timing is a bad
timing.
At least for the USB MIDI that I'm not using anymore, I made tests with a Windows
install (I don't have this install on my machine anymore, so I can't test the PCI
card with Windows).
The USB MIDI was much better on Windows, even better than the PCI cards at the moment are
on Linux. So I guess, yes I don't know, that the hardware is ok.
- Ralf
On Thu, 2010-07-15 at 00:46 +0200,
fons(a)kokkinizita.net wrote:
You really should do that test first before speculating about the outcome and
your audience.
You would expect Audiophiles to spot the "super sounding" denon cables by
listening, right? Yet a blind test showed the opposite. The test was to
identify which audio take was played with denon-cables, el-cheapo cables from
walmart and a bended cloth-hanger. If they where as good as they claimed, the
denon-cable should get hits with probability significantly better then 1/3,
otherwise its just luck.
Guess what the outcome was: There was a significant hit: But they spotted the
cloth-hanger as the denon-cable. Thats what real experts do...
Do the listening test with as many people as possible and then show the
results. And only afterwards start the speculations what the reason and the
effects might be. (Thats called science btw.)
Have fun,
Arnold Apart from that, it remains to be seen if *real*
timing errors of
+/- 2 ms do 'destroy the groove'. To test this, make the same
recording
- without jitter,
- with 1 ms jitter,
- with 2 ms jitter,
- with 3 ms jitter.
and check if listeners are able to identify which is which,
or at least to put them into order.
I know very gifted musicians who do like me
and they always 'preach'
that I should stop using modern computers and I don't know much averaged
people. So the listeners in my flat for sure would be able to hear even
failure that I'm unable to hear.
12:18 p.m.
New subject: Tests directly routing pc's midi-in to midi-out
On Thu, 2010-07-15 at 11:48 +0200, Arnout Engelen wrote:
Indeed.
Correct.
Who knows?
Perhaps 2ms shown by Audacity are 20ms, because Audacity has
a bug?
Sounds unlikely Perhaps 2ms
shown by Audacity are 2ms, but when playing JACK, the
sound card or what ever will add additional jitter?
You claimed the latency/timing was obviously noticably broken without needing
'golden ears' even without JACK, right? Let's first try to get this reliable without JACK,
just ALSA
So I'll do
- instead of dev.hpet.max-user-freq=64 I'll try 1024 or 2048 as Robin
mentioned
- connect the DX7 port to the D4 port with aconnect(gui) as Clemens
recommended
If nobody should demand to it, I won't use
- aplaymidi, because there might be a problem. All instruments at the
same time by the machine is missing the reference of recorded
instruments that might have had another fluctuation for the timing or
the alternative, it's missing the feeling of a musician playing live
How should I do
- I should be able to get my Atari ST working. It's MIDI is good enough
for my needs. So, how should I use the Atari ST to make a
'timestamp'-test as somebody recommended?
The Atari e.g. could play 4 on the floor at 120 BPM. I could watch the
received events by a Linux MIDI monitor or record it by a Linux MIDI
sequencer. But, should I sync by MTC or anything else etc.?
Cheers!
Ralf
12:49 p.m.
New subject: Tests directly routing pc's midi-in to midi-out
PS:
How should I do
- I should be able to get my Atari ST working. It's MIDI is good enough
for my needs. So, how should I use the Atari ST to make a
'timestamp'-test as somebody recommended?
The Atari e.g. could play 4 on the floor at 120 BPM. I could watch the
received events by a Linux MIDI monitor or record it by a Linux MIDI
sequencer. But, should I sync by MTC or anything else etc.?
I guess openoctave supports an ALSA MIDI sequencer only, based on
Rosegarden, but without audio, hence jackd isn't needed?
Perhaps seq24 and other only need ALSA MIDI, but JACK audio ... but make
use of those isn't easy and perhaps they don't know MIDI sync
possibilities?
OTOH MIDI sync by e.g. MTC might not be useful for this test?
12:55 p.m.
New subject: Tests directly routing pc's midi-in to midi-out
Ralf Mardorf wrote:
- instead of dev.hpet.max-user-freq=64 I'll try
1024 or 2048 as Robin
mentioned
This parameter will not have any effect on anything because there is no
program that uses the HPET timers from userspace. When high-resolution
timers are used by ALSA, this is done inside the kernel where there is
no limit on the maximum frequency.
Regards,
Clemens
1:08 p.m.
New subject: Tests directly routing pc's midi-in to midi-out
On Thu, 2010-07-15 at 12:55 +0200, Clemens Ladisch wrote:
Ralf Mardorf wrote:
IIRC someone on jack-devel mailing list had issues when using mplayer
with the value 64 and it was solved when using the value 1024. But as I
mentioned before, for my USB MIDI there was a difference between system
timer and hr timer, but there was no difference for the value 64 and
1024, when using hr timer.
Btw. I don't understand what a maximum frequency in the context does
mean. If 64 or 1024 should have impact, what would be the result?
System timer for a kernel-rt is set up to 1000Hz and hr timer is at
1000000000Hz.
What is 'max-user-freq' for?
Cheers!
Ralf
- instead of dev.hpet.max-user-freq=64 I'll
try 1024 or 2048 as Robin
mentioned
This parameter will not have any effect on anything because there is no
program that uses the HPET timers from userspace. When high-resolution
timers are used by ALSA, this is done inside the kernel where there is
no limit on the maximum frequency.
Regards,
Clemens
1:45 p.m.
New subject: Tests directly routing pc's midi-in to midi-out
On 07/15/2010 01:07 PM, Ralf Mardorf wrote:
It limits the maximum frequency at which user-space applications can
[request to] receive "wakeup calls" from the hr-timer.
see also the "Timers" thread on LAD last November:
http://linuxaudio.org/mailarchive/lad/2009/11/7/161647
On Thu, 2010-07-15 at 12:55 +0200, Clemens Ladisch
wrote:
> Ralf Mardorf wrote:
>> - instead of dev.hpet.max-user-freq=64 I'll try 1024 or 2048 as Robin
>> mentioned
>
> This parameter will not have any effect on anything because there is no
> program that uses the HPET timers from userspace.
That'd be correct if Ralf would stick to 'amidiplay' and friends for his
tests.
There are a couple of audio-tools who can use either RTC or HPET for
timing, although most of them need an option to explicitly enable it.
> When high-resolution
> timers are used by ALSA, this is done inside the kernel where there is
> no limit on the maximum frequency.
Thanks for that explanation. It makes perfect sense.
I take it the same must be true for dev.rtc.max-user-freq as well.
BTW. Do you know the unit of these values?
cat /sys/class/rtc/rtc0/max_user_freq
cat /proc/sys/dev/hpet/max-user-freq
are they Hz?
linux-2.6/Documentation/hpet.txt does not mention it at all and
linux-2.6/Documentation/rtc.txt hints it's Hz but does not explicitly
say so.
Regards,
Clemens
IIRC someone on jack-devel mailing list had issues when using mplayer
with the value 64 and it was solved when using the value 1024. But as I
mentioned before, for my USB MIDI there was a difference between system
timer and hr timer, but there was no difference for the value 64 and
1024, when using hr timer.
Btw. I don't understand what a maximum frequency in the context does
mean. If 64 or 1024 should have impact, what would be the result?
System timer for a kernel-rt is set up to 1000Hz and hr timer is at
1000000000Hz.
What is 'max-user-freq' for? Cheers!
Ralf
best,
robin
--
Robin Gareus mail: robin(a)gareus.org
site: http://gareus.org/ chat: xmpp:rgareus@ik.nu
blog: http://rg42.org/ lab : http://citu.fr/
Public Key at http://pgp.mit.edu/
Fingerprint : 7107 840B 4DC9 C948 076D 6359 7955 24F1 4F95 2B42
2:45 p.m.
New subject: Tests directly routing pc's midi-in to midi-out
On Thu, 2010-07-15 at 13:45 +0200, Robin Gareus wrote:
:)
Ralf
On 07/15/2010 01:07 PM, Ralf Mardorf wrote:
While at least one friend throw his Apple MacOs through the window. I'm
not kidding. Modern computers + music + my friends = not good. I've got
two kinds of friends, the once who say I shouldn't use a modern computer
and the others who say, I should buy Nuendo and expensive hardware. And
btw. I don't have got 1000 friends, but just a handful.
If I would ask my neighbours to listen, they would be fine with bad
timing, regarding to their habits, listening to the radio at prime time.
Anyway, I could ask people to listen, but I'm sure this would be
useless.
On Thu, 2010-07-15 at 12:55 +0200, Clemens
Ladisch wrote:
> Ralf Mardorf wrote:
>> - instead of dev.hpet.max-user-freq=64 I'll try 1024 or 2048 as Robin
>> mentioned
>
> This parameter will not have any effect on anything because there is no
> program that uses the HPET timers from userspace.
That'd be correct if Ralf would stick to 'amidiplay' and friends for his
tests. There are a couple of audio-tools who can use either
RTC or HPET for
timing, although most of them need an option to explicitly enable it.
It limits the maximum frequency at which user-space applications can
[request to] receive "wakeup calls" from the hr-timer.
see also the "Timers" thread on LAD last November:
http://linuxaudio.org/mailarchive/lad/2009/11/7/161647
Okay, what ever user-space might be, I assume regarding to the
explanations it's unimportant for rt. And as mentioned by the text of
the link, I can confirm that at least my USB MIDI is better when using
hr timer.
I'll test amidiplay, but again, playing all MIDI instruments at the same
isn't the major problem, perhaps just for me, resp. for people with
'golden ears'.
The major issue is sync to audio recordings of MIDI instruments, while
doing audio recordings of other, resp. the same instruments again.
I e.g. do only have one DX7 and one Matrix-1000 and my TG33 (with vector
control) is broken, hence I can't use all outputs, but one stereo output
of the TG33.
I wish to be able to record a synth several times. This means that even
inaudible jitter will become audible, for a production.
Of course I won't record one drum after the other from any of my drum
modules, because this just would result in more noise, but recording the
snare or kick separated to other drum samples is needed, when doing the
mastering by Linux and using a compressor like JAMin.
Accumulation of jitter, caused by recording one instrument after the
other is breaking the groove.
> When high-resolution
> timers are used by ALSA, this is done inside the kernel where there is
> no limit on the maximum frequency.
Thanks for that explanation. It makes perfect sense.
I take it the same must be true for dev.rtc.max-user-freq as well.
BTW. Do you know the unit of these values?
cat /sys/class/rtc/rtc0/max_user_freq
cat /proc/sys/dev/hpet/max-user-freq
are they Hz?
linux-2.6/Documentation/hpet.txt does not mention it at all and
linux-2.6/Documentation/rtc.txt hints it's Hz but does not explicitly
say so.
Regards,
Clemens
IIRC someone on jack-devel mailing list had issues when using mplayer
with the value 64 and it was solved when using the value 1024. But as I
mentioned before, for my USB MIDI there was a difference between system
timer and hr timer, but there was no difference for the value 64 and
1024, when using hr timer.
Btw. I don't understand what a maximum frequency in the context does
mean. If 64 or 1024 should have impact, what would be the result?
System timer for a kernel-rt is set up to 1000Hz and hr timer is at
1000000000Hz.
What is 'max-user-freq' for? Cheers!
Ralf
best,
robin
3:36 p.m.
New subject: Tests directly routing pc's midi-in to midi-out
On 07/15/2010 02:45 PM, Ralf Mardorf wrote:
On Thu, 2010-07-15 at 13:45 +0200, Robin Gareus
wrote:
Took me a while to catch that drift. I meant friends of 'amidiplay'
(eg 'amidirecord', 'aseqdump', etc) with the aim to keep things simple
for testing.
"..and friends" is an English idiom; sorry to put you off track.
On 07/15/2010 01:07 PM, Ralf Mardorf wrote:
While at least one friend throw his Apple MacOs through the window. I'm
not kidding. Modern computers + music + my friends = not good. I've got
two kinds of friends, the once who say I shouldn't use a modern computer
and the others who say, I should buy Nuendo and expensive hardware. And
btw. I don't have got 1000 friends, but just a handful.
If I would ask my neighbours to listen, they would be fine with bad
timing, regarding to their habits, listening to the radio at prime time. On Thu, 2010-07-15 at 12:55 +0200, Clemens
Ladisch wrote:
> Ralf Mardorf wrote:
>> - instead of dev.hpet.max-user-freq=64 I'll try 1024 or 2048 as Robin
>> mentioned
>
> This parameter will not have any effect on anything because there is no
> program that uses the HPET timers from userspace.
That'd be correct if Ralf would stick to 'amidiplay' and friends for his
tests. Anyway, I could ask people to listen, but I'm sure
this would be
useless.
It's the opposite of "kernel-space" :)
http://en.wikipedia.org/wiki/User_space
There are a couple of audio-tools who can use
either RTC or HPET for
timing, although most of them need an option to explicitly enable it.
It limits the maximum frequency at which user-space applications can
[request to] receive "wakeup calls" from the hr-timer.
see also the "Timers" thread on LAD last November:
http://linuxaudio.org/mailarchive/lad/2009/11/7/161647
Okay, what ever user-space might be, > When high-resolution
> timers are used by ALSA, this is done inside the kernel where there is
> no limit on the maximum frequency.
Thanks for that explanation. It makes perfect sense.
I take it the same must be true for dev.rtc.max-user-freq as well.
BTW. Do you know the unit of these values?
cat /sys/class/rtc/rtc0/max_user_freq
cat /proc/sys/dev/hpet/max-user-freq
are they Hz?
linux-2.6/Documentation/hpet.txt does not mention it at all and
linux-2.6/Documentation/rtc.txt hints it's Hz but does not explicitly
say so.
Regards,
Clemens
IIRC someone on jack-devel mailing list had issues when using mplayer
with the value 64 and it was solved when using the value 1024. But as I
mentioned before, for my USB MIDI there was a difference between system
timer and hr timer, but there was no difference for the value 64 and
1024, when using hr timer.
Btw. I don't understand what a maximum frequency in the context does
mean. If 64 or 1024 should have impact, what would be the result?
System timer for a kernel-rt is set up to 1000Hz and hr timer is at
1000000000Hz.
What is 'max-user-freq' for? I assume regarding to the
explanations it's unimportant for rt. And as mentioned by the text of
the link, I can confirm that at least my USB MIDI is better when using
hr timer.
I'll test amidiplay, but again, playing all MIDI instruments at the same
isn't the major problem, perhaps just for me, resp. for people with
'golden ears'.
Lets try something very simple:
ONE)
- Take a very simple midi-file.
- Use 'aplaymidi' to send it from your PC to your external midi-drum
machine. - Use your drum-synth's "klick" or "woodblock" sound or
sth
very dry with a good attack.
- do a quick ear-test if you can hear midi-jitter?
- capture the audio-output of the external-midi-synth with arecord.
Rewind and do it again.
Post the two files and the used .mid on a web-server or some drop-box.
If you want to check yourself: Align the first-beat of the captured
audio files in a multi-track audio-editor. While it will involve a bit
of manual labor to quantify the jitter. It'll at least be solid evidence.
TWO)
- launch an external MIDI-metronome (eg your Atari ST)
- connect it to your PC
- use 'arecordmidi' to generate a .mid file from it.
Repeat at least once and post the two midi files somewhere for us to
download.
THREE)
midi-metronom -> PC -> external-synth ==> audio
This combines ONE+TWO. just use 'aconnect[gui]' to use
your PC as MIDI-THRU. and 'arecord' to record audio that comes
from your drum-synth.
Note, at the moment we're not interested in latency, but in jitter.
The ticks in the recorded audio file _should be_ at identical intervals
+- jitter.
The output of
cat /proc/asound/timers
and
cat /proc/asound/version
might be interesting
Is that about right? Comments anyone?
The major issue is sync to audio recordings of MIDI
instruments, while
doing audio recordings of other, resp. the same instruments again.
I e.g. do only have one DX7 and one Matrix-1000 and my TG33 (with vector
control) is broken, hence I can't use all outputs, but one stereo output
of the TG33.
I wish to be able to record a synth several times. This means that even
inaudible jitter will become audible, for a production.
Of course I won't record one drum after the other from any of my drum
modules, because this just would result in more noise, but recording the
snare or kick separated to other drum samples is needed, when doing the
mastering by Linux and using a compressor like JAMin.
Accumulation of jitter, caused by recording one instrument after the
other is breaking the groove.
:)
Ralf
Cheers!
Ralf
best,
robin
4:31 p.m.
New subject: Tests directly routing pc's midi-in to midi-out
Robin Gareus wrote:
On 07/15/2010 01:07 PM, Ralf Mardorf wrote:
Jack can read the current time from /dev/hpet, but it does not use it to
generate interrupts. As far as I know, there is no program that does.
On Thu, 2010-07-15 at 12:55 +0200, Clemens
Ladisch wrote:
> Ralf Mardorf wrote:
>> dev.hpet.max-user-freq
>
> This parameter will not have any effect on anything because there is no
> program that uses the HPET timers from userspace.
That'd be correct if Ralf would stick to 'amidiplay' and friends for his
tests.
There are a couple of audio-tools who can use either RTC or HPET for
timing, although most of them need an option to explicitly enable it. BTW. Do you know the unit of these values?
cat /sys/class/rtc/rtc0/max_user_freq
cat /proc/sys/dev/hpet/max-user-freq
are they Hz?
Yes.
> IIRC someone on jack-devel mailing list had issues
when using mplayer
> with the value 64 and it was solved when using the value 1024.
This has nothing to do with MIDI timing; mplayer can use the RTC (not
HPET) for audio/video synchronization to work around the 100 Hz limit of
the system timer on old Linux kernels.
Regards,
Clemens
14 Jul
14 Jul
9:46 p.m.
On 07/14/2010 03:23 PM, Ralf Mardorf wrote:
[..]
$ su -c "chgrp audio /dev/hpet"
Its
also writable for the group, right?
$ su -c "sysctl -w
dev.hpet.max-user-freq=64"
Documentation on this value is hard to come by, but I think it's unit is
Hz. So you'll want
su -c "sysctl -w dev.hpet.max-user-freq=1024"
or even more :)
try:
echo 2048 | sudo tee /sys/class/rtc/rtc0/max_user_freq
echo 2048 | sudo tee /proc/sys/dev/hpet/max-user-freq
[..]
ciao,
robin
--
Robin Gareus mail: robin(a)gareus.org
site: http://gareus.org/ chat: xmpp:rgareus@ik.nu
blog: http://rg42.org/ lab : http://citu.fr/
Public Key at http://pgp.mit.edu/
Fingerprint : 7107 840B 4DC9 C948 076D 6359 7955 24F1 4F95 2B42
10:16 p.m.
On Wed, 2010-07-14 at 21:45 +0200, Robin Gareus wrote:
On 07/14/2010 03:23 PM, Ralf Mardorf wrote:
[..]
Yep :). I've got no idea what would be better a high or a low value, but
at least 64 when using HR timer was better than using the regular timer.
Unfortunately not many apps are able to run, when HR timer is used.
Usage of HR timer can freeze the system, e.g. Rosegarden does this on my
machine. I also need to start 'qtractor filename'. If I first start
Qtractor and than try to load a session, here are issues because HR
timer already is captured.
I guess one would be more flexible, if not using HR timer. I didn't
tested if there will be a difference when using the PCI MIDI. I'll do
this also ASAP. As I mentioned before, for USB MIDI there is a big
difference.
No thunder, no storm anymore, but there was a rainbow some minutes
ago :)
- Ralf
$ su -c "chgrp audio /dev/hpet"
Its also writable for the group, right?
$ su -c "sysctl -w
dev.hpet.max-user-freq=64"
Documentation on this value is hard to come by, but I think it's unit is
Hz. So you'll want su -c "sysctl -w
dev.hpet.max-user-freq=1024"
or even more :)
try:
echo 2048 | sudo tee /sys/class/rtc/rtc0/max_user_freq
echo 2048 | sudo tee /proc/sys/dev/hpet/max-user-freq
[..]
ciao,
robin
10:24 p.m.
On Wed, 2010-07-14 at 22:16 +0200, Ralf Mardorf wrote:
On Wed, 2010-07-14 at 21:45 +0200, Robin Gareus
wrote:
Could it be that a low value is better because it's some kind of 'be
ready for an IRQ every 64 times (of what unit ever)'?
IIRC a long time ago I tested 64 and 1024 and couldn't hear or see (for
the waveforms) a difference.
On 07/14/2010 03:23 PM, Ralf Mardorf wrote:
[..]
Yep :). I've got no idea what would be better a high or a low value, but
at least 64 when using HR timer was better than using the regular timer.
Unfortunately not many apps are able to run, when HR timer is used.
Usage of HR timer can freeze the system, e.g. Rosegarden does this on my
machine. I also need to start 'qtractor filename'. If I first start
Qtractor and than try to load a session, here are issues because HR
timer already is captured.
I guess one would be more flexible, if not using HR timer. I didn't
tested if there will be a difference when using the PCI MIDI. I'll do
this also ASAP. As I mentioned before, for USB MIDI there is a big
difference.
No thunder, no storm anymore, but there was a rainbow some minutes
ago :)
- Ralf
$ su -c "chgrp audio /dev/hpet"
Its also writable for the group, right?
$ su -c "sysctl -w
dev.hpet.max-user-freq=64"
Documentation on this value is hard to come by, but I think it's unit is
Hz. So you'll want su -c "sysctl -w
dev.hpet.max-user-freq=1024"
or even more :)
try:
echo 2048 | sudo tee /sys/class/rtc/rtc0/max_user_freq
echo 2048 | sudo tee /proc/sys/dev/hpet/max-user-freq
[..]
ciao,
robin
10:32 p.m.
On Wed, 2010-07-14 at 21:45 +0200, Robin Gareus wrote:
On 07/14/2010 03:23 PM, Ralf Mardorf wrote:
[..]
Sorry another PS, I missed to reply to this question.
At least for Suse it is:
spinymouse11.2@suse11-2:~> su -c "chgrp audio /dev/hpet"
Password:
spinymouse11.2@suse11-2:~> ls -l /dev/hpet
crw-rw---- 1 root audio 10, 228 2010-07-14 21:39 /dev/hpet
I'm sure it was for 64 Studio 3.0-beta3 too, but I never checked it for
64 Studio 3.3 alpha.
$ su -c "chgrp audio /dev/hpet"
Its also writable for the group, right? 
15 Jul
15 Jul
7:07 p.m.
On Wed, Jul 14, 2010 at 6:23 AM, Ralf Mardorf
<ralf.mardorf(a)alice-dsl.net> wrote:
For the MIDI audio test's LXDE session I'm
running GNOME terminal tab 1
JACK2, tab 2 Qtractor. Evolution offline + this Email opened for writing
to the lists. Envy24 Control and nothing else.
For Qtractor I switched from queue timer (resolution) 'system timer
(1000 Hz)' to 'HR timer (1000000000 Hz)' and restarted Qtractor.
For your prior failures, are you sure you had the correct soundcard
setup as the MIDI queue timer?
This caused me some issues in the past:
http://old.nabble.com/the-defacto-host-for-lv2-tt28789821.html#a28793953
Now my Qtractor View->Options->MIDI->Playback-Queue Timer is
permanently set to HR timer which avoids such issues when switching
soundcards.
You may want to check this setting prior to running tests... I also
found this thread helpful w/r/t explaining timer issues in MIDI:
http://old.nabble.com/Is-ALSA-using-hrtimer--ts28699922.html
-- Niels
5305
days inactive
5307
days old
linux-audio-dev@lists.linuxaudio.org
53 comments
9 participants
participants (9)
-
Arnold Krille -
Arnout Engelen -
Clemens Ladisch -
drew Roberts -
fons＠kokkinizita.net -
Niels Mayer -
Paul Davis -
Ralf Mardorf -
Robin Gareus