[LAD] ALSA MIDI latency test results are far away from reality
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 PortClient name Port name 14:0Midi Through Midi Through Port-0 16:0TerraTec EWX24/96TerraTec EWX24/96 MIDI 20:0TerraTec EWX24/96TerraTec 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.1 s sample; latency_ms; latency_ms_worst 0; 1.07; 1.07 ; 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.1 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.
Re: [LAD] FIxed alsa-tools' envy24control missing peak level meters and Reset Peaks
On Tue, Jul 13, 2010 at 09:54:58PM -0700, Niels Mayer wrote: What's even more absurd, is to have the benefits of the ice1712's hardware metering squandered by drawing thousands of rectangles per second (each individual LED on each meter is a separate x draw-rectangle call). It should at least use the XDrawRectangles(), which draws a list of them in a single call. And since the hardware metering already quantizes to 256 levels -- there's no point in re-quantizing those to individual virtual LEDs as is done w/ the current envy24control. Depends. A linear mapping is not really the best you can do. 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) ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] ALSA MIDI latency test results are far away from reality
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: ro...@gareus.org site: http://gareus.org/ chat: xmpp:rgar...@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 ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] ALSA MIDI latency test results are far away from reality
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 ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] ALSA MIDI latency test results are far away from reality
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. 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. 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 'looong 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 ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] ALSA MIDI latency test results are far away from reality
On Wed, Jul 14, 2010 at 9:52 AM, Clemens Ladisch clem...@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 ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] ALSA MIDI latency test results are far away from reality
On Wed, 2010-07-14 at 15:52 +0200, Clemens Ladisch wrote: 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. Qtractor at the moment is ALSA MIDI only and I even didn't use the -Xseq bridge. 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). 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 PortClient name Port name 14:0Midi Through Midi Through Port-0 16:0TerraTec EWX24/96TerraTec EWX24/96 MIDI 20:0USB Device 0x170b:0x11 USB Device 0x170b:0x11 MIDI 1 24:0TerraTec EWX24/96TerraTec EWX24/96 MIDI ### ONE OF THE PCI CARDS $ 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.1 s sampling 1 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 ; 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.1 s sampling 1 midi latency values - please wait ... press Ctrl+C to abort test sample; latency_ms; latency_ms_worst 0; 2.21; 2.21 ; 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.1 s sampling 1 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 ; 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.1 s sampling 1 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;
Re: [LAD] ALSA MIDI latency test results are far away from reality
On Wed, 2010-07-14 at 10:53 -0400, Paul Davis wrote: On Wed, Jul 14, 2010 at 9:52 AM, Clemens Ladisch clem...@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 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 ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] ALSA MIDI latency test results are far away from reality
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 clem...@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 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 PS: Not me playing, Qtractor is playing those instruments for me. Offline now ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] ALSA MIDI latency test results are far away from reality
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 clem...@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@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] ALSA MIDI latency test results are far away from reality
On 07/14/2010 04:22 PM, Ralf Mardorf wrote: 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. 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. 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. 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. 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 'looong 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: ro...@gareus.org site: http://gareus.org/ chat: xmpp:rgar...@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 ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] ALSA MIDI latency test results are far away from reality
On 07/14/2010 05:27 PM, Ralf Mardorf wrote: 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 clem...@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? 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. - Ralf *Offline now* ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
[LAD] Correlation of alsa -p value and hw MIDI jitter
Hi :) delayed by a thunder-storm I could do another test. 64 Studio 3.3 alpha (= Ubuntu Karmic) amd64 LXDE, poff dsl-provider, cpufreq-selector -g performance, chgrp audio /dev/hpet, sysctl -w dev.hpet.max-user-freq=64, modprobe snd-hrtimer Qtractor + HR timer playing FluidSynth DSSI drums and a standalone MIDI drum module in unison. $ jackd -Rch -dalsa -dhw:0 -r96000 -p16 -n2 FluidSynth DSSI and the hardware MIDI drum module are playing in unison. $ jackd -Rch -dalsa -dhw:0 -r96000 -p512 -n2 Borderline, not out of timing, but not fine and already critical. $ jackd -Rch -dalsa -dhw:0 -r96000 -p256 -n2 Borderline, not out of timing, but not fine. $ jackd -Rch -dalsa -dhw:0 -r96000 -p128 -n2 Borderline, not out of timing, but not fine. $ jackd -Rch -dalsa -dhw:0 -r96000 -p64 -n2 Borderline, not out of timing, but not fine. $ jackd -Rch -dalsa -dhw:0 -r96000 -p32 -n2 It here might become usable. $ jackd -Rch -dalsa -dhw:0 -r96000 -p16 -n2 Yes, for this test the problem at -p32 and -p16 is, that because of phasing the kick become randomly very loud. It seems not to depend on the sounds, but jitter, anyway I can't say this for sure, some sounds can't be played in unison, even if there won't be jitter. Values = -p64 result in ... I need to hear it again ... $ jackd -Rch -dalsa -dhw:0 -r96000 -p64 -n2 ... 'in unison' becomes a little bit of an early reflection like effect, but a very, very short delayed early reflection, still more a fluctuating phasing. $ jackd -Rch -dalsa -dhw:0 -r96000 -p1024 -n2 Completely out of sync, bad timing. Unusable. I guess even with -p16 one should record all drums and the bass at the same time, but recording every instrument one after another. This could be possible even for -p512, but MIDI is completely out of timing at -p1024, note, at 96KHz. Short attacked percussive sounds shouldn't be played in unison. For some usage PCI MIDI seems to be okay on my machine, but it's not comparable to an Atari ST and SMPTE sync to a 4-track cassette recorder or even to a C64 and click sync to a 4-track cassette recorder. PCI MIDI still has to much jitter for a straight timing, that enables to record one instrument after the other in perfect sync. I guess as long as I could keep -p256 and I won't be able to do a lot without increasing this value, hw MIDI could be usable for very simple music, when the whole MIDI backing is recorded at the same time, but one after the other instrument. - Ralf ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] ALSA MIDI latency test results are far away from reality
On 07/14/2010 06:31 PM, Nedko Arnaudov wrote: Robin Gareus robin-+vldmftonamdnm+yrof...@public.gmane.org writes: 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. What version? release-4 - the latest on svn://svn.gna.org/svn/a2jmidid I can clearly see code that handles this in the current version. It is in jack.c, a2j_alsa_output_thread(), lines 385-411 I've just seen that there's git://repo.or.cz/a2jmidid.git and jumped from release-4 to release-6. ciao, robin -- Robin Gareus mail: ro...@gareus.org site: http://gareus.org/ chat: xmpp:rgar...@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 ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
[LAD] 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 ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] ALSA MIDI latency test results are far away from reality
On Wed, 2010-07-14 at 17:30 +0200, Robin Gareus wrote: On 07/14/2010 04:22 PM, Ralf Mardorf wrote: 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)? Yes there are lapse, even if there should be no messages about xruns. 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? 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. 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. 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. 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 'looong 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. Thank you for your effort :). 'Read you later' today or at the latest on Friday. enjoy a good long week-end. Have a nice weekend too. I'll spend the weekend for Linux audio. Cheers! Ralf ciao, robin Cheers! Ralf ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] 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: 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 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 ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
[LAD] controlling access to the sound card
I have three applications that want to use the sound card, two audio stream players, and a voip phone. I want to set up linux so that if a call comes in on the phone the OS will disconnect the audio players, give exclusive access to the voip phone, and then when the phone is done reconnect the audio players to the sound card. How can this be done? ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] ALSA MIDI latency test results are far away from reality
On Wed, Jul 14, 2010 at 1:42 PM, Robin Gareus ro...@gareus.org wrote: On 07/14/2010 06:31 PM, Nedko Arnaudov wrote: Robin Gareus robin-+vldmftonamdnm+yrof...@public.gmane.org writes: 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. What version? release-4 - the latest on svn://svn.gna.org/svn/a2jmidid I can clearly see code that handles this in the current version. It is in jack.c, a2j_alsa_output_thread(), lines 385-411 I've just seen that there's git://repo.or.cz/a2jmidid.git and jumped from release-4 to release-6. the code you cited does not do that. it is in a loop that sleeps until each queued MIDI event should be delivered. it explicitly does *not* deliver them all at once. its one inaccuracy is that it will not attempt to sleep for less than 1msec, so if you have 2 messages separated by less than 1 msec, they will be delivered one directly after the other. ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] controlling access to the sound card
On Wed, 2010-07-14 at 15:02 -0500, Jason Butler wrote: I have three applications that want to use the sound card, two audio stream players, and a voip phone. I want to set up linux so that if a call comes in on the phone the OS will disconnect the audio players, give exclusive access to the voip phone, and then when the phone is done reconnect the audio players to the sound card. How can this be done? Regarding to the German Wiki PulseAudio should be able to handle stuff like this. While PulseAudio is a PITA to many Linux audio production users, IIUC PulseAudio should help for needs as yours. Of course you have to code apps, resp. to use apps that were programmed for usage with PulseAudio. I've got no knowledge about this!!, but if PulseAudio shouldn't be able to handle this kind of things, than I wonder what the advantages of it should be. Unfortunately the Wiki on English isn't that informative as the German Wiki ... I anyway didn't read the complete German Wiki. - Ralf ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] 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: On Wed, Jul 14, 2010 at 03:23:03PM +0200, Ralf Mardorf wrote: 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? I'm connecting MIDI in the Qtractor (quasi QjackCtl) ALSA MIDI tab. 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) ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] ALSA MIDI latency test results are far away from reality
On 07/14/2010 07:58 PM, Ralf Mardorf wrote: On Wed, 2010-07-14 at 17:30 +0200, Robin Gareus wrote: On 07/14/2010 04:22 PM, Ralf Mardorf wrote: 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)? Yes there are lapse, even if there should be no messages about xruns. 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. It turned out I was using an ancient version of 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? 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. 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. 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. 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 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. 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. 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 'looong
Re: [LAD] ALSA MIDI latency test results are far away from reality
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: ro...@gareus.org site: http://gareus.org/ chat: xmpp:rgar...@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 ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] ALSA MIDI latency test results are far away from reality
On Wed, 2010-07-14 at 21:42 +0200, Robin Gareus wrote: On 07/14/2010 07:58 PM, Ralf Mardorf wrote: On Wed, 2010-07-14 at 17:30 +0200, Robin Gareus wrote: On 07/14/2010 04:22 PM, Ralf Mardorf wrote: 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)? Yes there are lapse, even if there should be no messages about xruns. 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. It turned out I was using an ancient version of 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? 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. 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. 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. 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. 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
Re: [LAD] ALSA MIDI latency test results are far away from reality
On Wed, 2010-07-14 at 21:45 +0200, Robin Gareus wrote: 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 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 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 ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] ALSA MIDI latency test results are far away from reality
On Wed, 2010-07-14 at 22:16 +0200, Ralf Mardorf wrote: On Wed, 2010-07-14 at 21:45 +0200, Robin Gareus wrote: 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 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 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 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. ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] ALSA MIDI latency test results are far away from reality
On Wed, 2010-07-14 at 21:45 +0200, Robin Gareus wrote: On 07/14/2010 03:23 PM, Ralf Mardorf wrote: [..] $ su -c chgrp audio /dev/hpet Its also writable for the group, right? Sorry another PS, I missed to reply to this question. At least for Suse it is: spinymouse1...@suse11-2:~ su -c chgrp audio /dev/hpet Password: spinymouse1...@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. ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] 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: On Wed, 2010-07-14 at 19:56 +0200, Arnout Engelen wrote: On Wed, Jul 14, 2010 at 03:23:03PM +0200, Ralf Mardorf wrote: 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? I'm connecting MIDI in the Qtractor (quasi QjackCtl) ALSA MIDI tab. 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. 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. 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 ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] 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. ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] [64studio-devel] [64studio-users] Correlation of alsa -p value and hw MIDI jitter
On Wed, 2010-07-14 at 14:12 -0700, Devin Anderson wrote: On Wed, Jul 14, 2010 at 12:43 PM, Ralf Mardorf ralf.mard...@alice-dsl.net wrote: On Wed, 2010-07-14 at 12:30 -0700, Devin Anderson wrote: On Wed, Jul 14, 2010 at 10:29 AM, Ralf Mardorf ralf.mard...@alice-dsl.net wrote: Hi :) delayed by a thunder-storm I could do another test. --snip-- So, what you're saying is that your MIDI device and software synth sync up less and less as you raise the period size. Yes :). I had presupposed before that your MIDI device was triggering *after* your software synth, but it occurs to me that it might be the other way around. Do you hear the audio from your software synth first, or from your MIDI device? I can't say it today, now I do some office work. I had the impression that it might vary. Sometimes the virtual drum sampler and sometimes the standalone drum sampler was played earlier, I need to check this ASAP. For older tests with my USB MIDI device it was exactly that way, that jitter had positive and negative delay. At least the recorded waveforms of external MIDI equipment (when I used USB MIDI, now I'm using PCI MIDI), were recorded by Qtractor, before theoretically the MIDI event was send ;). Note! Qtractor had no latency compensation, all recorded audio of external MIDI instruments should have (positive) delay, but negative delay. If it ends up being the case that your MIDI device is being triggered before your software synth, then I'm guessing that the issue here is not MIDI jitter. I'm guessing the issue is that the latency that's imposed by JACK on incoming and outgoing audio is not imposed on incoming and outgoing ALSA MIDI. So, while the audio coming out of the software synth is delayed by a certain amount of frames imposed by JACK, the audio coming out of your MIDI device is only delayed by the latency of the ALSA drivers, the latency of the MIDI ports, the latency of your MIDI device. This would certainly explain why the problem gets worse as you raise the period size, and could explain why you had positive and negative delay in your older USB MIDI tests, as the reported MIDI jitter in your tests was *far* worse in your older tests than it is now. At the moment, I happen to be doing some work in JACK 2 that could potentially solve this issue by enabling MIDI to sync more closely with audio, so I'm very curious to know if my suspicions are correct. Please keep me updated. :) Should I build JACK dummy packages for 64 Studio and daily get JACK2 from svn co http://subversion.jackaudio.org/jack/jack2/trunk/jackmp ? I wonder if this should be cross-posted to LAD? On LAD and the 64 Studio list are people with much knowledge and your reply might hit the nail on the head. - Ralf ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] 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) ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] [64studio-users] [64studio-devel] Correlation of alsa -p value and hw MIDI jitter
No firewire here. I once had a MOTU, but I guess that there isn't a driver for Linux and the guy who lend me the MOTU + Mac was Dirk Brauner who isn't a friend anymore. I guess the MOTO was audio only. The people who are still my friends don't have much different equipment, but I've got. Always Envy24 based PCI, one friend has just more IOs for his Envy24 based PCI card. Make sure that the MIDI device is being triggered before the soft synth before you post to LAD. If it ends up being the case, then go ahead and post it on LAD. You're right I was stupid to spread to much speculations. And yes, regarding to your knowledge you should join LAD. - Ralf ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] 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) ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
[LAD] Sever issue?
I guess nearly ever mail sent to LAD returned with an issue regarding to unable to deliver the message in the time limit specified to thaytan at noraisin dot net, while no mail was send to somebody who obviously has something seriously to do with GStreamer. Perhaps this is unimportant, but because I don't know, I guess it's better to inform about this 'issue' or 'non-issue' - Ralf ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] 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, f...@kokkinizita.net wrote: 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. 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. 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 ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] 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, f...@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. ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
