On Mon, Aug 15, 2016 at 6:34 AM, robert bristow-johnson <r...@audioimagination.com> wrote: > well, i'm not much of a musician (i wish i were). but i am honestly > surprized reading the magnitude of NoteOn delay and possible jitter. i > *just* cannot imagine why *anything* like 10 ms would be needed to get the > note going. how are you measuring this Nigel?
I don't really get it either, but I guess it's the result of slow MCUs controlling DSPs or custom chips... Or, in the case of the Roland JV-1080 and (I suspect, others in that family); a RISC CPU "emulating" an MCU by means of timer interrupts with apparently no synchronization at all, to anything. (Those synths don't have DSPs nor MCUs, AFAIK, so they're basically softsynths running on custom hardware - among the first of their kind, I believe.) This impacts MIDI handling, EGs, LFOs etc. Apparently, the designers just assumed that "a few ms more or less won't matter," and designed literally everything around that - even on machines that would seem to have no real excuse to have these problems, such as the Roland JV series. [...] > samples should not be buffered any more than 32 or, at the outset, 64 > samples. i am *not* one of them process-samples-one-at-a-time partisans and > i have had plenty of arguments with them (not buffering samples and not > processing them in blocks is very inefficient, unnecessarily inefficient). There's no need to go full sample-by-sample just to get sample accurate timing. Besides, that's still "only" sample accurate, which is still insufficient for true audio rate control. (Consider the example of generating musical notes by triggering granules via messages/events. You need subsample accurate timing to handle any frequency that doesn't happen to result in integer periods at the current sample rate.) I'm doing buffers in Audiality 2 (64 samples; wired at compile time), but control is done through buffer splitting (controlled by scripting VM timing, and timestamped events), so timing is still subsample accurate. (Technically sample accurate, but oscillators have access to, and honor, the fractional part of timestamps as well.) Of course, that means any units that unroll loops or use SIMD or similar will need alternate inner loops to handle split buffers, but at least, one isn't constantly taking the full impact of sample-by-sample processing, with all the function calls, state reloads, missed optimization opportunities etc, that comes with that. (This engine is mostly for games, and I'm even considering using it on phones and the like, so that kind of overhead would be completely unacceptable. But, for various reason, I really wanted to be able to control things with subsample accurate timing.) That said, total buffering will typically be way more than 32 or 64 sample frames anyway, unless you're running on custom hardware, or a RTOS. However, that's constant latency - not jitter. If a few ms of constant latency becomes a real problem, one can use headphones instead of monitor speakers. ;-) [...] > well, if note stealing is > necessary, that would add some uncertainty, but let's say that your synth > can play more 10 times more notes than you have fingers to play them. then > note stealing should not be necessary. I can sort of see why note stealing would be a problem on a machine with a very strict cycle budget (you can't just cut a voice mid-buffer, because that adds state update overhead that may not fit in the budget), but then again, how many notes would realistically need to be stolen during one single buffer period anyway? Why not just reserve time for stealing a few notes per buffer, so constant latency can be guaranteed under all normal working conditions? [...] > i just can't see, unless the computer is jerking off, why any MIDI synth > needs more than, say, 3 ms. with a jitter of 2 ms (i.e. the key-down to > note-onset must be at least 1 ms with a possible 0 to 2 ms further delay due > to MIDI merge issues or when the complete MIDI message is received before > the following 32-sample block. and there's no good fucking reason why the > sample block should be longer.) Well, IMHO, there's no real excuse for much more than one sample frame of jitter, but latency is all about the OS. With RT-Linux and RTAI, I've seen worst case latencies of a few microseconds on various standard and industry PC hardware, so from the hardware point of view, there is absolutely no excuse at all. It's all about the cost of moving everything into kernel space or "user space realtime context," as opposed to running it in "normal" processes under a (standard or patched) general purpose OS. In a former life, I ported the Linux OSS AudioPCI driver to RT-Linux and managed to set it up with overlapping input and output buffers, so there was only one sample frame of time between the input and output DMA transfers. Rock solid on a 233 MHz PII. Others have processed one sample at a time that way (not possible with a normal sound card using PCI DMA), and in short, it's not a problem. If you can't do it, it's either the OS, or a hardware/driver issue. (Such as a graphics driver allowing the bus to block when the GPU command buffer is full; common problem in the past, which would also affect ProTools/Windows users and the like.) [...] > but i can't, for the life of me, understand why any hardware product would > need a latency of 17 or 20 ms. that's a factor of 10 longer than the > minimum delay i can account for. Totally agree. The only "valid" excuse I can think of is FFT based filters and synthesis methods, but that's a different problem, and the vast majority of hardware synths and the like don't do anything like that, AFAIK. //David _______________________________________________ dupswapdrop: music-dsp mailing list music-dsp@music.columbia.edu https://lists.columbia.edu/mailman/listinfo/music-dsp
