Menu
▾
▴
|
From: <chr...@ep...> - 2002-11-08 11:29:56
|
>Further to this, serial MIDI only runs at 31.250 kbaud, which means that= >the maximum resolution of a MIDI note on is 42 samples at 44.1kHz (30 bi= ts >at 31250bits/s). > >Obviously things like OSC have greater time resolution, but it shows tha= t >sample accurate note triggering isn't essential. It may something worth >droppping for efficiency. I definitely agree with that, as notes will be triggered by pure MIDI devices in most cases anyway. And even if not, sample accurate triggering= is just overkill. I think doubling MIDIs frequency (in case of note on that would be 2*1067Hz =3D 2133Hz) would be enough for the internal rate. That way you preserve at least MIDIs resolution, no? (BTW note on has 3 Bytes, what are the remaining 6 Bits for? CRC?) ________________________________________ Online Fotoalben - jetzt kostenlos bei http://www.ePost.de |
|
From: Phil K. <phi...@el...> - 2002-11-08 12:20:41
|
The MIDI spec defines the bit pattern as one start bit, eight data bits and one stop bit with a transfer rate of 31.25 (+/- 1%) Kbaud, hence 10 bits per message byte. Although this speed is the official spec I've found that ALSA, and a number of MIDI cards, do not seem to throttle data back to the spec and will pass data though the interface at reception speed. Although this is a wider problem for me regarding DMIDI and hardware it's potentially a good thing when we are dealing with software based D/MIDI applications (10 Gbit MIDI :). So regarding MIDI timing I get the impression that PC host based interfaces cannot guarantee the 31.25k rate, but testing is not conclusive. -P On Fri, 2002-11-08 at 11:29, chr...@ep... wrote: > >Further to this, serial MIDI only runs at 31.250 kbaud, which means that > >the maximum resolution of a MIDI note on is 42 samples at 44.1kHz (30 bits > >at 31250bits/s). > > > >Obviously things like OSC have greater time resolution, but it shows that > >sample accurate note triggering isn't essential. It may something worth > >droppping for efficiency. > > I definitely agree with that, as notes will be triggered by pure MIDI > devices in most cases anyway. And even if not, sample accurate triggering > is just overkill. > > I think doubling MIDIs frequency (in case of note on that would be > 2*1067Hz = 2133Hz) would be enough for the internal rate. That way you > preserve at least MIDIs resolution, no? > > (BTW note on has 3 Bytes, what are the remaining 6 Bits for? CRC?) > > > > > > > > > ________________________________________ > Online Fotoalben - jetzt kostenlos bei http://www.ePost.de > > > > > ------------------------------------------------------- > This sf.net email is sponsored by: See the NEW Palm > Tungsten T handheld. Power & Color in a compact size! > http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en > _______________________________________________ > Linuxsampler-devel mailing list > Lin...@li... > https://lists.sourceforge.net/lists/listinfo/linuxsampler-devel |
|
From: Benno S. <be...@ga...> - 2002-11-08 17:45:25
|
On Fri, 2002-11-08 at 13:12, Phil Kerr wrote: > Although this speed is the official spec I've found that ALSA, and a > number of MIDI cards, do not seem to throttle data back to the spec and > will pass data though the interface at reception speed. Although this > is a wider problem for me regarding DMIDI and hardware it's potentially > a good thing when we are dealing with software based D/MIDI applications > (10 Gbit MIDI :). yes, of course that's why I prefer the PC sequencer -> internal MIDI -> PC software synth/sampler solution over using external gear. Timing will be very tigh and chords do not suffer from smearing. In fact in some extreme test cases with my proof-of-concept code where flooded it with aligned note-on events there were CPU overloads due to the voice initialization code eating away a few cycles. Probably we will need to limit the note-on's per fragment in order to level out these CPU load peaks, especially when using very small fragment sizes (32-64 samples) with bigger fragment sizes there is plenty of time for handling the note events. > > So regarding MIDI timing I get the impression that PC host based > interfaces cannot guarantee the 31.25k rate, but testing is not > conclusive. No that is not true. Some sound cards do not have MIDI RX or TX interrupts and force the driver to go into polling mode which means either high CPU usage or low throughput. (see the soundblaster awe 64 midi out -> no tx irq -> midi sucks :-) ) With other cards like the Hoontech you get note-on midi-out-to-in latency that matches the wire speed. Looong time ago I wrote a tittle tool that does this http://www.gardena.net/benno/linux/mididelay-0.1.tgz Paul Davis and others (using decent midi cards) reported 1.1 msec note-on midi-out-to-in latency which matches the wire speed. On the SB AWE64 I got about 10 msec (due the lack of a TX irq) plus when midi out traffic is very heavy the machine slows down to a crawls (using OSS/Free). So before buying a MIDI card pay attention that both RX and TX irqs are present. But my prefered MIDI "cable" between two boxes will be DMIDI over 100Mbit LAN anyway. :-) PS: does sound my RAM sample module reasonable ? (taking into account the suggestions you guys gave here like Steve's modulation rate reduction etc). If there are not objections I'm going to write some code and make the sampling module "audible". :-) cheers, Benno -- http://linuxsampler.sourceforge.net Building a professional grade software sampler for Linux. Please help us designing and developing it. |
