6 ms·

Good point. I think you do accept the convenience of browsers (many cool projects such as this one https://learningsynths.ableton.com/ https://learningsynths.a

Good point. I think you do accept the convenience of browsers (many cool projects such as this one https://learningsynths.ableton.com/ https://learningsynths.ableton.com/). So now the problem is the audio performance. As I post in the comments below, we now have WASM, so C++ and Rust can all run in browsers. This can provide a near-native audio performance. Just take Glicol, the live coding language I design as an example: it runs in browsers (https://glicol.org https://glicol.org) and it also runs as a VST plugin (https://youtu.be/tmmBhBmIEW0 https://youtu.be/tmmBhBmIEW0), or you can use the audio engine to write VST plugin (https://github.com/chaosprint/dattorro-vst-rs https://github.com/chaosprint/dattorro-vst-rs).

spacechild1 4y ago
Yep. Pure Data and SuperCollider can also run in the browser. But there's a difference between C/C++/Rust audio apps compiled to WASM on the one hand and writing audio code in JS on the other hand. Then again, I think it's perfectly ok for people to experiment with audio in browser. "Native" audio desktop applications will always be superior, so there's nothing to be afraid of.
PaulDavisThe1st 4y ago
> As I post in the comments below, we now have WASM, so C++ and Rust can all run in browsers. This can provide a near-native audio performance. Native audio apps require realtime scheduling and memory locking, things you cannot do/control in the browser. The problem is that you can likely get 70-85% of "it" done in the browser, but when the user/performer need the remaining 15-30% for whatever reason, what do they do then?
- Jasper_ 4y ago
  Very rarely do you get that level of control even on modern systems. People aren't making music on ASIO-capable sound cards, they're using ASIO4All which implements ASIO on top of your boring MME/WASAPI audio stack. On any modern OS, you don't write directly to the sound card, you write to a buffer which the system mixer does the FX graph on, then that goes to the underlying sound system. CoreAudio, WASAPI and PipeWire are all built like this. Realtime threads are attempted to be solved by AudioWorklet which allow a high-priority thread. We probably won't get to the level of 100% assembly programming, but we can get close, and I think that's fine. Where I get upset at Web Audio is the amount of time spent in all the oscillators and FX nodes; I think you're better off ignoring those just because of how limiting and awkward they are.
  - PaulDavisThe1st 4y ago
    > Very rarely do you get that level of control even on modern systems. Windows, macOS, Linux all offer this control. AudioWorklet does not offer much control of thread priority (read the source code of any DAW to see how much is actually done), and also isn't clearly appropriate for parallelization of DAW processing, which is a standard architecture in any current DAW. It's not really about asm programming. It's about the ability with the host OS in all the appropriate and required ways. Browsers are extremely unlikely to permit this, for a variety of very sensible reasons.
    - chaosprint 4y ago
      I think it's all about trade-offs. For example, I can also point out that the latency on Windows, macOS are too high as these are general-purpose oriented systems. See this paper: http://eecs.qmul.ac.uk/~andrewm/mcpherson_nime2016.pdf http://eecs.qmul.ac.uk/~andrewm/mcpherson_nime2016.pdf Similar dilemma we have for the general-purposed browsers. To push to a limit, we can only resort to bare metal or Xenomai Linux like Daisy or Bela. But for the same reason we use Windows and macOS, we trade off some audio performance for a better overall experience.
      - PaulDavisThe1st 4y ago
        Most of the problems with the lower limit on audio latency these days come down to hardware (motherboard/PCI bus level) rather than the OS. Both macOS and Linux can routinely handle values significantly lower than the 10msec mentioned in the paper you cited, given the right hardware (more or less guaranteed for macOS, much harder to ensure for Linux).
  - jcelerier 4y ago
    > People aren't making music on ASIO-capable sound cards, sorry what :) I don't know anyone who does a bit of remotely serious music making who doesn't have at least some USB focusrite or something like that > On any modern OS, you don't write directly to the sound card, you write to a buffer which the system mixer does the FX graph on, then that goes to the underlying sound system. CoreAudio, WASAPI and PipeWire are all built like this. Paul Davis is the author of JACK and Ardour fyi, I think they have a good idea of how things work :p buffers are unavoidable but I don't see webaudio allowing me to use a 64 frames buffer size and still be able to put in some effects and play with some softsynths like I have right now, or even being able to run isolcpu and tweak DMAs to entirely devote specific CPU cores to audio processing.

spacechild1 4y ago

Yep. Pure Data and SuperCollider can also run in the browser. But there's a difference between C/C++/Rust audio apps compiled to WASM on the one hand and writing audio code in JS on the other hand. Then again, I think it's perfectly ok for people to experiment with audio in browser. "Native" audio desktop applications will always be superior, so there's nothing to be afraid of.

PaulDavisThe1st 4y ago

> As I post in the comments below, we now have WASM, so C++ and Rust can all run in browsers. This can provide a near-native audio performance. Native audio apps require realtime scheduling and memory locking, things you cannot do/control in the browser. The problem is that you can likely get 70-85% of "it" done in the browser, but when the user/performer need the remaining 15-30% for whatever reason, what do they do then?

Jasper_ 4y ago
Very rarely do you get that level of control even on modern systems. People aren't making music on ASIO-capable sound cards, they're using ASIO4All which implements ASIO on top of your boring MME/WASAPI audio stack. On any modern OS, you don't write directly to the sound card, you write to a buffer which the system mixer does the FX graph on, then that goes to the underlying sound system. CoreAudio, WASAPI and PipeWire are all built like this. Realtime threads are attempted to be solved by AudioWorklet which allow a high-priority thread. We probably won't get to the level of 100% assembly programming, but we can get close, and I think that's fine. Where I get upset at Web Audio is the amount of time spent in all the oscillators and FX nodes; I think you're better off ignoring those just because of how limiting and awkward they are.
- PaulDavisThe1st 4y ago
  > Very rarely do you get that level of control even on modern systems. Windows, macOS, Linux all offer this control. AudioWorklet does not offer much control of thread priority (read the source code of any DAW to see how much is actually done), and also isn't clearly appropriate for parallelization of DAW processing, which is a standard architecture in any current DAW. It's not really about asm programming. It's about the ability with the host OS in all the appropriate and required ways. Browsers are extremely unlikely to permit this, for a variety of very sensible reasons.
  - chaosprint 4y ago
    I think it's all about trade-offs. For example, I can also point out that the latency on Windows, macOS are too high as these are general-purpose oriented systems. See this paper: http://eecs.qmul.ac.uk/~andrewm/mcpherson_nime2016.pdf http://eecs.qmul.ac.uk/~andrewm/mcpherson_nime2016.pdf Similar dilemma we have for the general-purposed browsers. To push to a limit, we can only resort to bare metal or Xenomai Linux like Daisy or Bela. But for the same reason we use Windows and macOS, we trade off some audio performance for a better overall experience.
    - PaulDavisThe1st 4y ago
      Most of the problems with the lower limit on audio latency these days come down to hardware (motherboard/PCI bus level) rather than the OS. Both macOS and Linux can routinely handle values significantly lower than the 10msec mentioned in the paper you cited, given the right hardware (more or less guaranteed for macOS, much harder to ensure for Linux).
- jcelerier 4y ago
  > People aren't making music on ASIO-capable sound cards, sorry what :) I don't know anyone who does a bit of remotely serious music making who doesn't have at least some USB focusrite or something like that > On any modern OS, you don't write directly to the sound card, you write to a buffer which the system mixer does the FX graph on, then that goes to the underlying sound system. CoreAudio, WASAPI and PipeWire are all built like this. Paul Davis is the author of JACK and Ardour fyi, I think they have a good idea of how things work :p buffers are unavoidable but I don't see webaudio allowing me to use a 64 frames buffer size and still be able to put in some effects and play with some softsynths like I have right now, or even being able to run isolcpu and tweak DMAs to entirely devote specific CPU cores to audio processing.