Introduction
I'll hand a report about the actually MIDI jitter in later. Here I
argued why it's quixotic to ignore some issues for some suggestions, how
to work with Linux for a mix of natural instruments, internal MIDI
instruments and external MIDI instruments. Alternatively I recommend to
take care about and feature some functions for Linux MIDI sequencers.
Hi, folks :)
so far we solved that JACK doesn't disconnect clients any more, the most
probable reason for this seems to be the change from JACK1 to JACK2.
The next important thing for me, is to decrease jitter for external MIDI
equipment, doing this might spare the need to urgently solve some or
maybe all other issues I'm not fine with.
Here's the report of what I did at last and also I argue some aspects of
MIDI and historical MIDI equipment. I guess some people like the sound
of a Stradivari more than the sound of a modern violin made of wood
that's still wet, for synth it's comparable to that. I hope you
understand this analogy. Sometimes I read that e.g. Hexter sounds equal
to a DX7, then I often was near to ask for the serial number of the used
DX7, some people even wrote that the Bristol DX7 sounds like a DX7,
reading this I tend to ask from which planet and company the DX7 they
are talking about is. Some synth like the DX7, Prophet 5 etc. came with
really different revisions. Just imagine a virtual synth that sounds
like a Minimoog, hopefully it sounds like a Minimoog with a stable
tuning, the tuning of some Minimoogs strongly colour their outputs ;).
1.
I soldered a MIDI cable that fit to my TERRATEC EWX 24/96 PCI sound
card. I guess it's possible that sync is better when using this
interface instead of the USB one.
In the first place I would like to have both interfaces, to enable the
usage of the whole MIDI equipment I've got. There are 3 reasons to have
more than one interface.
The first reason even can be satisfied with additional interfaces having
bad sync or simply one interface by adding a switch for the sources. I
need to have several MIDI inputs, for different sources, but mostly I
use one master keyboard, while most other sources just need the
possibility to dump SysEx, without the need to do that in rt.
The second reason is that some equipment only receives in omni mode or
isn't able to be fine with 'running status', so that I have to use an
independent output or to rummage about my Commodore 64 and an Assembler
routine I wrote around 17 years ago, to filter and pass one channel. By
the way, this program I wrote and a MIDI-thru-box I build don't cause
serious jitter or delay, but each MIDI-thru causes delay and for the
rhythm group this can become a serious problem, when it won't be
compensated, that's one of the reasons why every sequencer should
feature an offset option for tracks or at least for the elements on the
tracks (clips, parts, segments or what ever 'your' sequencer's manual
call them). I only know a sequencer post Commodore 64 and pre Linux, Mac
OS, Windows supporting to turn 'running status' on or off, an Atari
sequencers pre the latest Atari Cubase version. This is good because of
the slow interface, but sometimes requires more than one MIDI output.
For cases with less MIDI data traffic, it would be nice to have every
sequencer supporting to turn 'running status' on or off. For Linux I
guess ALSA MIDI and JACK MIDI internally are working with all bytes,
while for the output to external equipment 'running status' is active
and cancelling status bytes. I hope there's a flag that can be set by
sequencers, so that ALSA MIDI and JACK MIDI enable or disable 'running
status' for the output to external equipment when needed.
The third reason is that 16 MIDI channels aren't enough, resp. one
interface can be to slow to handle all the data. Imagine that you might
use 16 instruments, but with 16 FX that need separate channels or
imagine you're using just 8 instruments, but you control filters by
SysEx in rt for some instruments and of course you some day might need
17 instruments and no channel can be used in a way to control 2
instruments (often it might be possible to split the range of notes and
e.g. to use modulation wheel for one and after touch for the other
synth, or two synth are played in unison only).
2.
-------- Original Message --------
Subject: Re: PS: Qtractor wishlist
Date: Mon, 1 Jun 2009 11:50:25 +0100 (WEST)
From: Rui Nuno Capela <[email protected]>
if your primary audio interface is the "usb" one, try to put it ahead of
the "snd" in the priority sequence--see your rtirq.conf, like this
# IRQ thread service names
# (space separated list, from higher to lower priority).
RTIRQ_NAME_LIST="rtc snd usb i8042"
change that to:
RTIRQ_NAME_LIST="rtc usb snd i8042"
and restart.
-------- Original Message --------
Subject: Re: Qtractor and/ or trouble because of Linux audio is
prpblematic
Date: Mon, 15 Jun 2009 10:43:35 +0100 (WEST)
From: Rui Nuno Capela <[email protected]>
Ralf Mardorf wrote:
No, my primary sound device is an Envy24 based PCI card. The USB device
is for MIDI only. I guess once upon a time I got better sync and/ or
less jitter when not using RTC or what clock ever, but sync to PCM
output or what it is called for Rosegarden's sequencer clock.
ok, try using "usb3" instead of just "usb" in that rtirq.conf line. that
will make your particular usb midi device ahead of the usb crowd. just
remember that will probably change depending on which usb host port the
device is plugged.
getting back to midi timing. rtc was indeed problematic before, moreover
on a rt-preemptive kernel (which still is highly experimental atm). to
make things worse the vanilla system timer is bad as easy, mostly due to
lousy default resolution (250hz). for quite some time, having the midi
timer dependable on the pcm device timing was the reasonable choice but
then it made jitter a function of the audio period/buffer size. not good
and open for too many ymmv issues.
that's why one could only go with 1000hz kernel timers. newer kernels (alsa)
have this default high-resolution timers option which might be a blessing.
you see, linux audio/midi is and has been a moving target, with too many
ups and downs, and still a swamp of good and bad software solutions and
hardware combinations.
in many ways, it is far, too far yet, from a complete or finished
business. i wonder if it will ever be ;)
Instead of searching USB 01 I verified if the MIDI device still is
connected to slot 03.
r...@64studio:~# hwinfo --usb
01: [snip]
Driver Modules: "usbcore"
[snip]
02: [snip]
Driver Modules: "usbcore"
[snip]
03: [snip]
Driver: "snd-usb-audio"
Driver Modules: "snd_usb_audio"
[snip]
Then I run '# gedit /etc/default/rtirq', edited the file, see the
attached 'rtirq'.conf and restarted the computer, resp. shut down the
computer, did something else and will turn it on later, so that the
configuration could be used by /etc/init.d/rtirq I guess. I think that
for other distros I need to search were the configuration file is, e.g.
in /etc/sysconfig.
Cheers,
Ralf
--
http://www.dailywav.com/1002/beginning.wav
#!/bin/bash
#
# Copyright (c) 2004-2007 rncbc aka Rui Nuno Capela.
#
# /etc/default/rtirq
#
# Configuration for IRQ thread tunning,
# for realtime-preempt enabled kernels.
#
# This program is free software; you can redistribute it and/or modify it
# under the terms of the GNU General Public License version 2 or later.
#
# IRQ thread service names
# (space separated list, from higher to lower priority).
# DEFAULT:
# RTIRQ_NAME_LIST="rtc snd usb i8042"
# EDITED TO:
RTIRQ_NAME_LIST="rtc snd usb3 i8042"
# Highest priority.
RTIRQ_PRIO_HIGH=90
# Priority decrease step.
RTIRQ_PRIO_DECR=5
# Whether to reset all IRQ threads to SCHED_OTHER.
RTIRQ_RESET_ALL=0
# On kernel configurations that support it,
# which services should be NOT threaded
# (space separated list).
RTIRQ_NON_THREADED="rtc snd"
# Process names which will be forced to the
# highest realtime priority range (99-91)
# (space separated list, from highest to lower priority).
# RTIRQ_HIGH_LIST="softirq-timer"
_______________________________________________
64studio-users mailing list
[email protected]
http://lists.64studio.com/mailman/listinfo/64studio-users
