There's a huge divide between people who might play with this at home as a toy and those who would be able to work with professional musicians with it.
The latter group will have some very strict requirements around performance, latency and workflow.
Edit: and reliability
DSP based systems struggled a lot with IO in the late 90s until faster SATA drives became ubiquitous. Lots of them used SCSI or exotic hardware cards to deal with large track counts.
It did have a SCSI drive, but in 1999 I did not consider that "exotic", having been using them on various Unix workstations for more than a decade before that.
They do plan to have a "native wrapper like tauri" in the future. I've played around with node-web-audio-api for low latency multichannel for Electron, but it wasn't a great success. Mostly because Rust audio backends (and almost all audio backends in general) aren't very good in such usage.
The crux is you want everything to play in sync when doing recording and overdubbing, e.g. "hit record and what I hear live is in sync with what I have recorded already". Almost all DAWs solve this by just starting things a bit later (latency compensation). Some audio cards solve this by allowing direct hardware monitoring. But even then you will have some samples of latency.
most plug-ins don't add latency ?
> There is no way eliminate CPU cycles being spent on whatever the plugin does.
that's not how DAW works, they don't output audio immediately anyways, everything is buffered at the driver level or just above so that there's always 1 or 2 buffers of delay between the input and the output. There's no difference in terms of latency between putting one or 50 bitcrushers in series for instance because in the end the audio main loop looks like (in a very simplified way):
void process_soundcard_buffers(float** in, float** out, int samples) {
for(int i = 0; i < samples; i++) // samples would usually be the buffer size you set in your audio config
out[0][0] = f(in[0][0]);
}
Lastly, some fancy interfaces have built in DSP, so that you can load your effects right in the interface, for when you want effects in your recording monitor feed...
So I dont think latency is that critical anymore, and with a decent interface its mostly sorted out.
EDIT: The concerns here are primarily with input latency. Between plucking a string and heading it in your monitor it has to go through: your input hardware, the USB interface, the OS, the browser (which doesn't have explicit low latency capabilities), and JS. Most platforms support ASIO which is a low-level driver for reading audio data from devices. About as close to reading the ADCs yourself. Without a low-latency driver working with the OS there's so much latency overhead it's audible.
Jitter is a much bigger problem.
AFAIK ASIO is windows only.
macOS has proper audio APIs out of the box, and arguably since the introduction of WASAPI exclusive mode and WaveRT in Windows Vista, Windows has all the needed tools as well. But most of the more "professional" DAW products (in particular those by Steinberg, the author of ASIO) seem to ignore the existence of those. REAPER is one of the exceptions. Even WASAPI shared mode latency is really usable (below 30ms), but not low enough for tightly synchronized real-time recording.
Linux audio can be set up to provide low-latency audio as well, but I cannot comment on the details there as I'm not using it for that purpose.
Checkmate ;) j/k
You're right, it's not natively on Linux, and you wouldn't use it on Linux today since the kernel supports lower latency IO and has better scheduling. Jack has gotten so much better. We didn't have that at the time and I was desperate to use the only interface card I had.
That said, there are plenty of open source implementations of ASIO drivers now that aren't hardware tied.
Actually you absolutely would use it, in the same way you did back then.
WineASIO is a layer that allows a Wine application to use the ASIO API. Since ASIO is not a part of Windows itself, anything that wants to use ASIO can't do so on "bare Wine", and Wine doesn't allow for the installation of a windows kernel driver layer like ASIO. Hence: WineASIO - an implementation of ASIO for use by Windows applications running inside Wine.
Also, Ubuntu 14 dates to 2014; JACK dates back to 2002. Very little, if anything has changed about JACK since 2014. AFAIR, WineASIO could or did use JACK itself at some point in its development history, since it was a pretty natural fit.
I don't know of any open source ASIO implementations. The only 3rd party one of, ASIO4ALL, is not open source. Then again, I don't track the Windows environment much at all.
You're right, Jack existed. I remember struggling to get it working though. Oh well, I'm quite a long ways form that career though. Rusty skills.
You cannot be performing to audio that you are hearing with any delay, especially if the monitoring of the live audio is also being routed through software.
At a certain point of latency it introduced delays and badly affects how you perform. In some circumstances it makes performance actually impossible.
There are ways around this, namely if the software knows exactly what the input and output latency is then the playback and recording can be compensated. For live monitoring though you really need that done in the audio hardware itself in hard real time.
The reasons are things like, if you want to play in time with a previously recorded track, or if you are using digital effects and need to be able to hear their effect on your instrument as you play it.
Both of these are less of an issue today than they were 15 years ago where a USB 2.0 audio interface added significant delay into audio and made it harder to get what you wanted out of the system.
Otherwise latency is not really a problem.
This is absolutely not true. Latency in audio systems is important in almost every aspect of using a DAW
but that doesn't allow me to have my (software) effects chain when I record ? for a guitar solo where i'm going to play with say, delays and whammys that's a no-go