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.
I expect many people fooling around with GarageBand or VCV Rack don't have any special sound card. Also, it doesn't seem that uncommon to for musicians to make recordings using a cell phone?
But recording when it matters is dependent on the microphone, the pre-amp and the A/D converter, none of which are of suitable quality in a cell phone to be the basis for a "serious" recording.
Sure, maybe most professionals don't do that but you said nobody does that, as if amateurs don't exist.
I was thinking more of setups where you connect a mic/pre directly into the phone.
Most of the time I've seen people doing this, however, they are using "native" recording apps on their phones, not a browser.
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.
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
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.
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.