I didn’t ask the original question but I have a couple follow-ups, if you don’t mind…
Which components do you think could be leveraged in the browser? Assuming something like emscripten is used?
The big issues will be plugins. Apart from a few FAUST…
Ardour bundles a nice set of plugins - are you suggesting there’s something in the way of porting those too? Or that the vast majority of professional third party plugin are proprietary, and won’t be supporting an emscripten build anytime soon.
There’s a lot of confusion here. The websocket support is not in anyway connected with the idea of “implementing ardour (or any DAW) in the browser”. It is solely and entirely based on the idea of building control interfaces for Ardour that run in a browser.
This dream of “build a DAW in the browser” needs to die a rapid death, at least for the 5-20 years it will take for “the browser platform” to match what a native desktop environment can do.
Ardour is (very roughly) about 150k lines of code for the GUI, another 130k lines of code for libardour and another 270k lines of code for the remaining libraries written as part of the project. It uses almost every programming technique you can do in a language like C++. It runs dozens of threads, many of them running with realtime scheduling. It has to stream potentially hundreds of MB/sec from an actual filesystem. It needs a GUI model that goes so far beyond current web “toolkits” or “frameworks” that it’s just amusing reading all the chat about the latter on e.g. Hacker News. We need atomic operations. We run hand-written assembler for metering code (30% speedup with large buffer sizes).
I understand that more and more stuff is being implemented within browsers. I understand the emscripten/webasm are really pushing the boundaries of what can be done. I fully expect there to be some seriously impressive audio tools that are implemented within the browser (there already are … almost).
But look at this way: in most senses, Ardour is at least as complex as Firefox. Would you seriously suggest implementing a browser inside a browser ? And I don’t mean as an exercise to prove it can be done, I mean do it because it makes sense. Yes, I’ve run Windows95 inside my browser - I know about what’s possible. But it is slow and makes essentially zero sense other than as a gimmick.
So please, by all means go ahead and implement small scale interesting browser-based audio software. There’s a ton of stuff that can be done. But don’t ask us to think about let alone get involved in “porting” an industrial-level DAW (600 tracks? no problem) to the “browser platform”.
Re: audio I/O … low latency I/O is critical to DAWs. But low latency I/O is of no importance to browser audio implementations, and the idea that you’re going to get direct passthrough that replicates the behavior and best performance of ASIO/CoreAudio/ALSA is a pipedream, I believe. I admit that I could be wrong on this, but I know of no plans to make this happen.
And finally, yes, the majority of 3rd party plugins are not going to be ported to the browser any time soon (if ever).
Thanks, really appreciate the perspective. And I respect your request not to spin cycles on this subject - however at least one response is in order…
I don’t mean to suggest Wasm puts the “browser platform” on level playing field with native environments, and I agree w/ you (+ @x42) that it’s performance / architectural capabilities will necessarily lag some number of years, or simply fail to achieve parity in many ways…but there are valuable aspects of web apps where the opposite is true. And while those are precisely the aspects a native, bleeding-edge, “industrial-level DAW” is more than happy to trade for 600+ tracks, as a home studio enthusiast and software engineer, I’m intrigued to imagine an approximate of Ardour 4 delivered at the click of a hyperlink. I know, I know - even if the engine was somehow ported + rearchitected via wasm modules, we’ve still got the low latency audio problem…
Should a different talented group of engineers pull it off, I’m hard pressed to think those 3rd party plugins would ignore a new revenue stream
they’ve largely ignored Linux for the last 20 years, despite one of the most well known plugin makers using Linux internally and publically saying that the audio industry needs to move towards Linux. So I don’t hold out a huge amount of hope. On the other hand, the web-based market would be much, much larger.
I’m sure you meant to say Ardour 0.99.3, and even the equivalent of that likely won’t run in a browser in 2020
If you manage to even get Ardour 2 running the step to Ardour 6 isn’t that great in terms of environmental complexity.
If you use hardware monitoring that may not be the prime concern. What’s more important is reliable latency. In case you record overdubs, things need to be aligned.
I think asking the question the other way round, makes much more sense: Why should the DAW care from where (whose computer) it is controlled? When the DAW core is decoupled from its front-end, as Ardour’s core fortunately is (libardour and gtk2_ardour), this core shouldn’t care in which process or system the front-end runs.
A lot of valuable use cases come to mind:
A musician rehearsing/recording in the recording room, controlling the DAW running on a computer in the control or machine room, or musicians on stage creating their own monitor mixes.
A live sound engineer using a tablet, walking the venue and fine-tuning the FOH mix
A headless network mixer or networked DAW is a powerful tool, combined with AoIP I/O and connection management. Numerous use cases come to mind, e.g. multi-room audio with different I/O per room (breakout boxes, mixing console, AoIP monitors), or thin-client as the GUI to a complex networked audio distribution and processing setup with a DSP server (cluster)
A DAW with a networked control surface (e.g. OSC, AES70, MIDI…)
While true, the thing to remember is that the front end is the vast majority of Ardour’s code. At least 75% of the code is just for GUI and UI, though it is likely more (For some reason 90% is sticking in my head), so most of the complexity is actually in the UI.
