4 Jul
2010
4 Jul
'10
10:56 p.m.
On Sun, 2010-07-04 at 21:52 +0100, Dan Mills wrote:
Trying again, I accidentally sent this off list the
first time....
So I can add, I anyway will test to use two PCI cards, at least for
MIDI, for audio would be nice too.
-------- Forwarded Message --------
From: Ralf Mardorf
To: Dan Mills
Subject: Re: [LAD] No nagging, a serious question
Date: Sun, 04 Jul 2010 22:47:47 +0200
It was off-list?!
On Sun, 2010-07-04 at 21:35 +0100, Dan Mills wrote:
If you are working in a world where you know the
available hardware in
detail LOTS of things become easy, for example I can time stamp an
incoming MIDI byte with the sample number of reported as current
position by the sound card (There is only one), instant way to get
effectively zero latency jitter.
This doesn't work nearly so well when there is more then one sound card
Good to read about this issue. I always disable the on-board audio
devices, but I would add a second PCI card to my PC and sync it with the
already installed sound card, so I better don't do it. It at least would
be nice to have several MIDI IO by simply using some cheap Envy24 cards.
Unfortunately those cheap cards seems to use just one of the two MPUs
supported by the Envy24.
Cheers!
Ralf
4 Jul
4 Jul
11:16 p.m.
On Sun, 2010-07-04 at 22:56 +0200, Ralf Mardorf wrote:
Good to read about this issue. I always disable the
on-board audio
devices, but I would add a second PCI card to my PC and sync it with
the
already installed sound card, so I better don't do
it. It at least
would
be nice to have several MIDI IO by simply using some
cheap Envy24
cards.
Unfortunately those cheap cards seems to use just one
of the two MPUs
supported by the Envy24.
Note that I didn't say Linux does this (it would break separation
between the midi and audio subsystems), just that you can do it if you
know when developing the midi ISR exactly what hardware you have
available on the audio side (Specifically what address the cards
playback position register is).
The thing is you really want that timestamp to be based on the soundcard
clock that will ultimately be outputting the samples generated as a
result of that midi, difficult with things like Pulse (and to an extent
Jack) in the way and obviously unworkable with netjack.
This sort of issue is what the ALSA midi sequencer is really intended to
fix, by making midi timing a kernel problem rather then a user space
one. It sort of solves HALF the problem, in that it makes getting midi
messages out on time more or less possible (at least on paper), but it
does nothing for reliably timestamping incoming midi using a clock that
can be related simply to the audio sample clock and which would thus be
useful when building software synths.
You could probably hack a multi serial port card to do multiple midi
ports (Change the rock to give a suitable divider for 31250 baud
(4MHz?), add current loop interfaces)...
Regards, Dan.
11:44 p.m.
On Sun, 2010-07-04 at 22:16 +0100, Dan Mills wrote:
You could probably hack a multi serial port card to do
multiple midi
ports (Change the rock to give a suitable divider for 31250 baud
(4MHz?), add current loop interfaces)...
Been there, done that - when I was a penniless dole-scrounging scruffy
university drop-out living on a farm in the middle of nowhere, I decided
I needed a MIDI sequencer. So, I modified an old serial card with a
4MHz crystal which divides to 31250 baud, and wrote a simple
tracker-style sequencer in a mixture of C and assembler on DOS. It
worked, kind of. If you wanted to do anything really wild like change
the tempo you needed to recompile.
Gordon MM0YEQ
5 Jul
5 Jul
1:08 a.m.
On Sunday 04 July 2010, Gordon JC Pearce wrote:
On Sun, 2010-07-04 at 22:16 +0100, Dan Mills wrote:
As for the serial card with a different crystal, BTDT, on a TRS-80 Color
Computer 3. Not only that, but the software, Ultimuse-III, written by Mike
Knudsen could handle the serial card and the bitbanger at the same time, so
I actually had 2 ports and drove two different midi keyboards each with
their own midi voice assignments. This on a machine with 60 ticks/second
IRQ's for a clock. And neither port had any extra added buffers, it Just
Worked(TM).
--
Cheers, Gene
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Any sufficiently advanced technology is indistinguishable from a rigged
demo.
You could probably hack a multi serial port card
to do multiple midi
ports (Change the rock to give a suitable divider for 31250 baud
(4MHz?), add current loop interfaces)...
Been there, done that - when I was a penniless dole-scrounging scruffy
university drop-out living on a farm in the middle of nowhere, I decided
I needed a MIDI sequencer. So, I modified an old serial card with a
4MHz crystal which divides to 31250 baud, and wrote a simple
tracker-style sequencer in a mixture of C and assembler on DOS. It
worked, kind of. If you wanted to do anything really wild like change
the tempo you needed to recompile.
Gordon MM0YEQ
8:33 a.m.
On Sun, 2010-07-04 at 19:08 -0400, Gene Heskett wrote:
On Sunday 04 July 2010, Gordon JC Pearce wrote:
60 ticks/second IRQ's for clock is for the C64 too, the UART was
connected to the bus, but a serial port.
On Sun, 2010-07-04 at 22:16 +0100, Dan Mills
wrote:
As for the serial card with a different crystal, BTDT, on a TRS-80 Color
Computer 3. Not only that, but the software, Ultimuse-III, written by Mike
Knudsen could handle the serial card and the bitbanger at the same time, so
I actually had 2 ports and drove two different midi keyboards each with
their own midi voice assignments. This on a machine with 60 ticks/second
IRQ's for a clock. And neither port had any extra added buffers, it Just
Worked(TM). You could probably hack a multi serial port card
to do multiple midi
ports (Change the rock to give a suitable divider for 31250 baud
(4MHz?), add current loop interfaces)...
Been there, done that - when I was a penniless dole-scrounging scruffy
university drop-out living on a farm in the middle of nowhere, I decided
I needed a MIDI sequencer. So, I modified an old serial card with a
4MHz crystal which divides to 31250 baud, and wrote a simple
tracker-style sequencer in a mixture of C and assembler on DOS. It
worked, kind of. If you wanted to do anything really wild like change
the tempo you needed to recompile.
Gordon MM0YEQ
5:16 a.m.
New subject: [Fwd: Re: No nagging, a serious question]
On Sun, Jul 4, 2010 at 5:16 PM, Dan Mills <dmills(a)exponent.myzen.co.uk> wrote:
This sort of issue is what the ALSA midi sequencer is
really intended to
fix, by making midi timing a kernel problem rather then a user space
one.
the mistake there is that it makes the once-reasonable assumption that
the required timing could only be accomplished in the kernel. this was
once true, but its not anymore.
It sort of solves HALF the problem, in that it makes
getting midi
messages out on time more or less possible (at least on paper), but it
does nothing for reliably timestamping incoming midi using a clock that
can be related simply to the audio sample clock and which would thus be
useful when building software synths.
IIRC, you can set the clock source on an ALSA sequence queue to be the
clock based on a PCM device.
8:51 a.m.
New subject: [Fwd: Re: No nagging, a serious question]
On Sun, 2010-07-04 at 23:16 -0400, Paul Davis wrote:
On Sun, Jul 4, 2010 at 5:16 PM, Dan Mills
<dmills(a)exponent.myzen.co.uk> wrote:
Is it possible to make the ALSA MIDI latency test use the PCM playback
and PCM capture as clock source?
spinymouse11.2@suse11-2:~> alsa-midi-latency-test --help
Usage: alsa-midi-latency-test -o client:port -i client:port ...
-o, --output=client:port port to send events to
-i, --input=client:port port to receive events from
-l, --list list available midi input/output ports
-R, --realtime use realtime scheduling (default: no)
-P, --priority=int scheduling priority, use with -R
(default: maximum)
-S, --samples=# of samples to take for the measurement (default:
10000)
-s, --skip=# of samples to skip at the beginning (default: 0)
-w, --wait=ms time interval between measurements
-r, --random-wait use random interval between wait and 2*wait
-h, --help this help
-V, --version print current version
This sort of issue is what the ALSA midi
sequencer is really intended to
fix, by making midi timing a kernel problem rather then a user space
one.
the mistake there is that it makes the once-reasonable assumption that
the required timing could only be accomplished in the kernel. this was
once true, but its not anymore.
It sort of solves HALF the problem, in that it
makes getting midi
messages out on time more or less possible (at least on paper), but it
does nothing for reliably timestamping incoming midi using a clock that
can be related simply to the audio sample clock and which would thus be
useful when building software synths.
IIRC, you can set the clock source on an ALSA sequence queue to be the
clock based on a PCM device. 
10:37 a.m.
New subject: [Fwd: Re: No nagging, a serious question]
On Mon, Jul 5, 2010 at 4:16 AM, Paul Davis <paul(a)linuxaudiosystems.com> wrote:
IIRC, you can set the clock source on an ALSA sequence
queue to be the
clock based on a PCM device.
You can, but I'm pretty sure last time I tested it (admittedly five or
six years ago) I found that the resulting clock was quantized to the
PCM device buffer length.
Chris
21 Jul
21 Jul
10:49 a.m.
On 07/04/2010 11:16 PM, Dan Mills wrote:
On Sun, 2010-07-04 at 22:56 +0200, Ralf Mardorf
wrote:
I cannot help but noting that the 'most bone-headed way of doing
low-latency audio' called firewire provides timestamps related to the
sample clock for midi messages (even each MIDI byte). The timestamps are
valid accross multiple devices.
The FFADO backend uses these to position the midi messages in the jack
buffers with sample accuracy. Therefore all jitter you see when using
the a firewire device with FFADO and jack is either due to MIDI itself
or due to the hardware you use. But not due to the software stack
(modulo bugs), the protocol nor the 1394 bus.
Regards,
Pieter
Good to read about this issue. I always disable
the on-board audio
devices, but I would add a second PCI card to my PC and sync it with
the
already installed sound card, so I better
don't do it. It at least
would
be nice to have several MIDI IO by simply using
some cheap Envy24
cards.
Unfortunately those cheap cards seems to use just
one of the two MPUs
supported by the Envy24.
Note that I didn't say Linux does this (it would break separation
between the midi and audio subsystems), just that you can do it if you
know when developing the midi ISR exactly what hardware you have
available on the audio side (Specifically what address the cards
playback position register is).
The thing is you really want that timestamp to be based on the soundcard
clock that will ultimately be outputting the samples generated as a
result of that midi, difficult with things like Pulse (and to an extent
Jack) in the way and obviously unworkable with netjack.
This sort of issue is what the ALSA midi sequencer is really intended to
fix, by making midi timing a kernel problem rather then a user space
one. It sort of solves HALF the problem, in that it makes getting midi
messages out on time more or less possible (at least on paper), but it
does nothing for reliably timestamping incoming midi using a clock that
can be related simply to the audio sample clock and which would thus be
useful when building software synths. 
2:57 p.m.
New subject: [Fwd: Re: No nagging, a serious question]
On Wed, Jul 21, 2010 at 1:49 AM, Pieter Palmers <pieterp(a)joow.be> wrote:
I cannot help but noting that the 'most
bone-headed way of doing low-latency
audio' called firewire provides timestamps related to the sample clock for
midi messages (even each MIDI byte). The timestamps are valid accross
multiple devices.
As the person that last uttered the words "bone headed" and
"firewire"
in the same sentence, I figure I should respond. :-)
Yes, it's attempted in software, e.g. isosynchronous packets ... and
it's full of fail:
http://www.docstoc.com/docs/23936431/FFADO-firewire-audio-for-Linux-httpwww…
(Hmmm... I guess they do have interesting papers at the Linux Plumbers Conf.)
"No direct access to devices hardware audio sampling clock (compare to
PCI devices)"
"Devices don't lock audio clock to iso clock"
"Must infer audio clock relative to iso clock (and/or wall time) based
on incoming time stamps"
"must compensate for buffer and transport delays through firewire and
device electronics"
"some devices can be very picky about the accuracy of the inferred audio clock"
"most manufacturers use vendor-specific extensions for key aspects of
device control"
"some manufacturers think they can do better than the standard and use
their own"
............
http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.119.1433&rep=r…
--> complexity fail... jitter fail ::
"The results of the test bench shows that RT-
net over RT-FireWire gives performance compara-
ble with RTnet over Ethernet. The former shows
larger latency and larger latency variation (jitter),
i.e. the difference between 97% threshold latency
and worst case latency. This is due to the rela-
tively more complex software stack: the packet path
through the whole RT-FireWire includes more task
handover, context switches, which inevitably cause
more lantency to the whole data path. On the other
hand, the former has a less leaning slope. This is
due to the higher data transfer rate on FireWire: the
FireWire devices in experiment can transfer data at
400Mb/s, while the Ethernet devcie in experiment
can only transfer at 100Mb/s."
........................
-- Niels
http://nielsmayer.com
5 Jul
5 Jul
2:38 a.m.
New subject: [Fwd: Re: No nagging, a serious question]
On Sun, Jul 4, 2010 at 1:56 PM, Ralf Mardorf <ralf.mardorf(a)alice-dsl.net> wrote:
Good to read about this issue. I always disable the
on-board audio
devices, but I would add a second PCI card to my PC and sync it with the
already installed sound card, so I better don't do it. It at least would
be nice to have several MIDI IO by simply using some cheap Envy24 cards.
Unfortunately those cheap cards seems to use just one of the two MPUs
supported by the Envy24.
Some of the higher-end Terratec's such as the "Phase 88" have two sets
of MIDI ports provided by the ICE1712. The TerraTec EWX 24/96 you have
is also an ICE1712 design with at least one external midi port. There
might be a second MIDI port on it via on-board extra connectors. They
have some synth-products that might hook up with this extension header
board just like the DMX6Fire... as to whether ALSA has provisions for
this second port, or the extension cards will determine whether you
can access the port easily.
The phase88 looks quite nice and probably cost a fortune back in 2005...
http://www.synthtopia.com/content/2004/11/03/terratec-producer-introduces-p…
http://www.ebayanuncios.es/interface-audio-profesional-terratec-phase-88-ra…
·
Here are other cards supported by this chip:
Module snd-ice1712
------------------
Module for Envy24 (ICE1712) based PCI sound cards.
* MidiMan M Audio Delta 1010
* MidiMan M Audio Delta 1010LT
* MidiMan M Audio Delta DiO 2496
* MidiMan M Audio Delta 66
* MidiMan M Audio Delta 44
* MidiMan M Audio Delta 410
* MidiMan M Audio Audiophile 2496
* TerraTec EWS 88MT
* TerraTec EWS 88D
* TerraTec EWX 24/96
* TerraTec DMX 6Fire
* TerraTec Phase 88
* Hoontech SoundTrack DSP 24
* Hoontech SoundTrack DSP 24 Value
* Hoontech SoundTrack DSP 24 Media 7.1
* Event Electronics, EZ8
* Digigram VX442
* Lionstracs, Mediastaton
* Terrasoniq TS 88
-- Niels
http://nielsmayer.com
8:42 a.m.
New subject: [Fwd: Re: No nagging, a serious question]
I'll search Ebay for several low-cost cards that are usable for
'pro-audio'. Thanx for the ice1712 list, btw. I just will search for the
PCI ones, because IIRC all ALSA MIDI latency tests the people from Linux
audio lists did were ok for PCI cards. USB failed most of the times or
very often and regarding to firewire I read too much about driver
issues.
On Sun, 2010-07-04 at 17:38 -0700, Niels Mayer wrote:
On Sun, Jul 4, 2010 at 1:56 PM, Ralf Mardorf
<ralf.mardorf(a)alice-dsl.net> wrote:
Good to read about this issue. I always disable
the on-board audio
devices, but I would add a second PCI card to my PC and sync it with the
already installed sound card, so I better don't do it. It at least would
be nice to have several MIDI IO by simply using some cheap Envy24 cards.
Unfortunately those cheap cards seems to use just one of the two MPUs
supported by the Envy24.
Some of the higher-end Terratec's such as the "Phase 88" have two sets
of MIDI ports provided by the ICE1712. The TerraTec EWX 24/96 you have
is also an ICE1712 design with at least one external midi port. There
might be a second MIDI port on it via on-board extra connectors. They
have some synth-products that might hook up with this extension header
board just like the DMX6Fire... as to whether ALSA has provisions for
this second port, or the extension cards will determine whether you
can access the port easily.
The phase88 looks quite nice and probably cost a fortune back in 2005...
http://www.synthtopia.com/content/2004/11/03/terratec-producer-introduces-p…
http://www.ebayanuncios.es/interface-audio-profesional-terratec-phase-88-ra…
·
Here are other cards supported by this chip:
Module snd-ice1712
------------------
Module for Envy24 (ICE1712) based PCI sound cards.
* MidiMan M Audio Delta 1010
* MidiMan M Audio Delta 1010LT
* MidiMan M Audio Delta DiO 2496
* MidiMan M Audio Delta 66
* MidiMan M Audio Delta 44
* MidiMan M Audio Delta 410
* MidiMan M Audio Audiophile 2496
* TerraTec EWS 88MT
* TerraTec EWS 88D
* TerraTec EWX 24/96
* TerraTec DMX 6Fire
* TerraTec Phase 88
* Hoontech SoundTrack DSP 24
* Hoontech SoundTrack DSP 24 Value
* Hoontech SoundTrack DSP 24 Media 7.1
* Event Electronics, EZ8
* Digigram VX442
* Lionstracs, Mediastaton
* Terrasoniq TS 88
-- Niels
http://nielsmayer.com
5267
days inactive
5284
days old
linux-audio-dev@lists.linuxaudio.org
11 comments
8 participants
participants (8)
-
Chris Cannam -
Dan Mills -
Gene Heskett -
Gordon JC Pearce -
Niels Mayer -
Paul Davis -
Pieter Palmers -
Ralf Mardorf