[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Date Index][Thread Index][Author Index]

Re: Midi Sample Dump

Floyd said:
>I tried dumping a loop into my sequencer.  It was a long loop,
>about 50 seconds.  So I was prepared to be patient, but after 20
>minutes it was still sending data. The numbers in the "multiple"
>window (that's supposed to be percent complete, no?) kept counting
>and overflowing and counting some more with the 10's digit incrementing
>about once per second or so.

Midi Sample Dump is painfully slow. I just dumped a 1 second loop and timed
it. It took 86 seconds to finish. So your 50 second loop would take about
72 minutes. If your sequencer supports handshaking, the process should
speed up quite a bit. Without it, the echoplex adds delays in the data
transmission to limit the danger of over running data buffers on the
receiving device. With handshaking, the receiver can acknowledge each chunk
of data so that the echoplex knows when it is ok to send the next chunk and
doesn't wait.

The slowness isn't the echoplex's fault. The problem is that midi is a
slow, inefficient, piece of garbage. It clocks data at 31.25khz, meaning
the best case is 31,250 bits per second. For each 8 bit data byte that midi
transmits, it requires one "start bit" and one "stop bit." That's 1/5 of
the bandwidth right there. So we are down to 25,000 bits per second. Sample
Dump transmits chunks of data, or "packets," at a time, each containing 127
bytes. 7 of those bytes are protocol overhead. So we throw out another
7/127 of data bandwidth and are down to 23,622 bits of data per second.
Midi doesn't stop the abuse there, because each 8 bit byte can only have 7
bits of data, with the most significant bit being 0. There goes another 1/8
of bandwidth, and we are down to 20,669 data bits per second. The sample
dump standard further insists that each audio sample be justified within
the 7-bit bytes, meaning we need 3 of them (21 bits) to contain a typical
16 bit audio sample. Unused bits are filled with zeros, and we are throwing
away 5 bits for each sample. So we lose another 5/21 of our data bandwidth,
and we finally arrive at 15,748 bits per second of actual data. Each sample
is 16 bits, so we are sending 984 samples per second. The Echoplex's sample
rate is 41.5khz, meaning 41,500 samples in one second of audio. 41500/984 =
42.2 seconds, just to transfer 1 second of audio in the ideal case. Adding
delays to prevent buffer overflows apparently doubles this, so it ends up
taking 86 seconds for 1 second of audio. The handshaking will presumably
cut this by as much as 1/2, depending on how fast the receiver can deal
with the data flow.

Beautiful, isn't it? Just takes a LOT of patience.

We added Sample Dump, actually, because everyone seemed to be complaining
about the Jamman for not having such a thing. We didn't actually think
anyone would find it very useful, but it was relatively easy since it
didn't require any extra hardware than we already had. Be careful what you
wish for.....

Oh, and ignore the counter. The "percent done" part never got implemented,
since we ran into so many problems trying to work around everyone else's
strange sample dump implementations.

>Any advice or similar experiences out there?

My advice: start the dump and go to lunch. And if you are sending 50 second
loops, make sure your sequencer can hold about 4.2 megabytes.


Kim Flint                   | Looper's Delight
kflint@annihilist.com       | http://www.annihilist.com/loop/loop.html
http://www.annihilist.com/  | Loopers-Delight-request@annihilist.com