4 ms·

Because "the audio thread waits for nothing." Garbage collection is unacceptable, more than a single pointer dereference to get to state is borderline unaccepta

Because "the audio thread waits for nothing." Garbage collection is unacceptable, more than a single pointer dereference to get to state is borderline unacceptable, and synthesizers (that an MIDI system would trigger) are up there with some of the most computationally demanding software you can develop even for toy projects. Especially so, even. A naively coded soft synth in C++ talking directly with drivers can easily crap out with 4-5 voices of polyphony. Now onto why a browser is a bad place to do this. Your audio subsystem supplies a buffer to you (or you supply a buffer to it, depending on OS) and you need to fill it in a fixed amount of time to avoid a buffer underrun, or increase the buffer size. At a 48kHz sample rate and a buffer size of say, 512 (default on MacOS) you have ten milliseconds to fill it. But you don't get all that time. As buffer sizes get smaller, the dominant factor becomes how much time it takes to get data from kernel to userspace, and from userspace down to kernal. In a browser now you have to go from kernel to user space to sandbox down to user space down to kernel. So getting low latency MIDI input to a browser, rendering it to sound, and getting it back, is basically a terrible use case scenario in terms of latency. Yea you can do a lot when you don't care about latency, but then the question is, why would you care about live MIDI input if you don't care about latency? Firefox's audio engine (or at least WebRender) is actually fairly impressive - I've heard things that they can get sub ms latency. But I don't really trust that you can do that and do serious audio processing, which any non-sine synth is going to entail.

nine_k 7y ago
A midi event stream is massively less demanding than a waveform stream. A browser could at least be a source of such events that you would route to your favorite hardware synth. Interestingly, browsers are capable of native audio and video playback for years; somehow it wasn't such a problem, given their relaxed requirements for latency.
- unlinked_dll 7y ago
  It's because streaming video and audio is simplex, MIDI + rendering is duplex. Round trip latency for a decent app needs to be sub 5ms, it doesn't matter if you have 200ms+ for receiving packets from a video/audio source on a web page, since you're not providing live input to get live output.
  - pg_is_a_butt 7y ago
    Try updating your 15 year old computer. It works fine.
deleted 7y ago
[deleted]
comboy 7y ago
You could make similar argument against webgl. Sure, it's hard, but take a step back and midi is just a more sophisticated keyboard/mouse (re input, the output is just a few pixels). Most musicians are ok with as much as 10ms latency while playing. That's plenty of CPU time. 1ms is about how long it takes sound to travel 1 feet. So how far away you are from your speakers may give you more latency that whatever current CPUs are capable off. I'm not arguing to make web DAWs and audio plugins. But for learning piano it's perfectly fine.
robbrown451 7y ago
Have you actually tried it? I mean, I build music web apps that run great on Chromium browsers. They use Web Audio API to generate sounds (non sine synths.... Web Audio API allows you to do all kinds of crazy stuff with oscillators and convolvers and such), and they take input from a MIDI keyboard. On a decent computer it sounds great and latency isn't noticeable (to me anyway). I've compared to using various native software synths and don't hear a difference in latency. Then again, I'm not expecting anyone to use my app to do a performance in Carnegie Hall. I want kids and other mere mortals to be able to have fun while learning and making music. You don't have to use it, of course, but I'm genuinely curious why you'd want to deny this sort of thing to others.

nine_k 7y ago

A midi event stream is massively less demanding than a waveform stream. A browser could at least be a source of such events that you would route to your favorite hardware synth. Interestingly, browsers are capable of native audio and video playback for years; somehow it wasn't such a problem, given their relaxed requirements for latency.

unlinked_dll 7y ago
It's because streaming video and audio is simplex, MIDI + rendering is duplex. Round trip latency for a decent app needs to be sub 5ms, it doesn't matter if you have 200ms+ for receiving packets from a video/audio source on a web page, since you're not providing live input to get live output.
- pg_is_a_butt 7y ago
  Try updating your 15 year old computer. It works fine.

deleted 7y ago

[deleted]

comboy 7y ago

You could make similar argument against webgl. Sure, it's hard, but take a step back and midi is just a more sophisticated keyboard/mouse (re input, the output is just a few pixels). Most musicians are ok with as much as 10ms latency while playing. That's plenty of CPU time. 1ms is about how long it takes sound to travel 1 feet. So how far away you are from your speakers may give you more latency that whatever current CPUs are capable off. I'm not arguing to make web DAWs and audio plugins. But for learning piano it's perfectly fine.

robbrown451 7y ago

Have you actually tried it? I mean, I build music web apps that run great on Chromium browsers. They use Web Audio API to generate sounds (non sine synths.... Web Audio API allows you to do all kinds of crazy stuff with oscillators and convolvers and such), and they take input from a MIDI keyboard. On a decent computer it sounds great and latency isn't noticeable (to me anyway). I've compared to using various native software synths and don't hear a difference in latency. Then again, I'm not expecting anyone to use my app to do a performance in Carnegie Hall. I want kids and other mere mortals to be able to have fun while learning and making music. You don't have to use it, of course, but I'm genuinely curious why you'd want to deny this sort of thing to others.