[LAD] [Fwd: Re: No nagging, a serious question]
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 ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] [Fwd: Re: No nagging, a serious question]
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. ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] [Fwd: Re: No nagging, a serious question]
On Sun, 2010-07-04 at 22:14 +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)... If one is fine with programming on Linux ;). ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] [Fwd: Re: No nagging, a serious question]
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 ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] [Fwd: Re: No nagging, a serious question]
On Sunday 04 July 2010, Gordon JC Pearce wrote: >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 > 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. ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] [Fwd: Re: No nagging, a serious question]
On Sun, Jul 4, 2010 at 1:56 PM, 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. 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-phase-88/ http://www.ebayanuncios.es/interface-audio-profesional-terratec-phase-88-rack/300230 · 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 ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] [Fwd: Re: No nagging, a serious question]
On Sun, Jul 4, 2010 at 5:16 PM, Dan Mills 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. ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] [Fwd: Re: No nagging, a serious question]
On Sun, 2010-07-04 at 19:08 -0400, Gene Heskett wrote: > On Sunday 04 July 2010, Gordon JC Pearce wrote: > >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 > > > 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). 60 ticks/second IRQ's for clock is for the C64 too, the UART was connected to the bus, but a serial port. ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] [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 > 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-phase-88/ > http://www.ebayanuncios.es/interface-audio-profesional-terratec-phase-88-rack/300230 > · > 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 ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] [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 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. Is it possible to make the ALSA MIDI latency test use the PCM playback and PCM capture as clock source? spinymouse1...@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:portport 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: 1) -s, --skip=# of samplesto 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 ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] [Fwd: Re: No nagging, a serious question]
On Mon, Jul 5, 2010 at 4:16 AM, Paul Davis 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 ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] [Fwd: Re: No nagging, a serious question]
On 07/04/2010 11:16 PM, Dan Mills wrote: 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. 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 ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] [Fwd: Re: No nagging, a serious question]
On Wed, Jul 21, 2010 at 1:49 AM, Pieter Palmers 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-httpwwwffadoorg (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=rep1&type=pdf --> 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 ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
