With Audacity 4 entering its final stages before release, I wanted to see if I could get the robot to get a browser-based version of it going. And, well, yes: Check out Soundscaper, Audacity 4 on the web
The thing is based on DilsonsPickles’ design system, which has been our design prototype when designing Audacity 4, some web tech for audio and storage, as well as a healthy amount of Audacity code compiled into WebAssembly. I’ve also asked the robot to implement some pet features of mine, such as video tracks, multi-track recording and a project bin.
While it does run in the browser, it does not upload anything; all storage and processing happens on your device.
My hope is that Soundscaper can serve both the Audacity team as an advanced prototype, as well as users who cannot use Audacity 4 due to OS version limitations and other reasons. If you find any bugs, report them here or on Github – it’s very much not stable yet.
Yes. It evolved from “oh look, there’s an FFmpeg WASM which allows me to do file conversions” as I was getting annoyed that my video editor didn’t handle WebM and WebP particularly well (which also went somewhere: Converters | Koytek Wattenberg Media) via an “but couldn’t I do basic edits too?” to finally “but what if I ported Audacity?”. Compared to the little converter tools, I feel like this “Audacity on the web” concept has a lot more merit as an actual project.
There have been a few WebAssemby versions of Audacity over the years. I don’t recall the earliest version I’ve seen, but one of the more well known versions from around 2022: https://wavacity.com/
I wrote a rather lengthy reply to your post on this thread @LeoWattenberg along the lines of what you have posted in your blog, but it got held for review and then I guess deleted. If it all comes back to me I’ll write it again send it to you directly.
@LeoWattenberg , have you found any intrinsic limitations to the web version of Audacity 4?
I’m aware that browser based technology has evolved a lot over the years, but I’d guess there could still be issues related to, or arising from the browser’s security sandbox.
audioIO is limited to whatever the browser provides. Usually you can select inputs freely, but not outputs, input channels are limited to 2 in chromium, and desktop audio needs explicit confirmation every time you engage it
CORS can get in the way of fetching online resources, so any kind of downloader requires a server to do it
compiled plugins don’t work (but nyquist should)
localStorage is managed by the browser and thus can’t be moved to a different drive for space reasons, and all files must be copied into either RAM or localStorage to be worked on (I compress them with wavpack to alleviate this pressure a bit)
That’s really interesting, as a “died in the wool” webby who’s dabbled in web audio and web containers (thanks to Stackblitz)) I’m intrigued by this.
You can manage quite a lot locally on the play and mix side using the the web audio graph and local file access. But the specs and implementations are patchy (eg no master clock in spec, filesystem chromium only). It’s fun though and the web is an amazing platform. Eg see this basic mixer I’ve been playing with. BIggest problem was syncing streams - you can’t (weak spec) and have to load all into browser memory (Safari is the biggest problem here, no surprise)
Web assembly make sense but so much of the code will we making platform assumptions so I shows a good architecture that you can get so much to run. Awesome.
What is “the robot?” you mean Agentic something or other?
It’s Codex, though I bet Claude could do it just as well. I recently told it to fully switch over to test-driven development and it’s spent the past 3 days clamping down on the basic “contracts” as it calls them. Whenever it’s done, it’ll probably either work surprisingly well, or not at all — but probably nothing in-between
@LeoWattenberg, this is where I try to remember what I posted to you earlier that got lost.
If Audacity ends up with a front end on an internet browser, then correcting a problem for one person will correct it for everyone. There will be no need for users to run an update to see the latest.
But I can see running under that model it would be tempting to start walling off some features — even existing ones — under a paywall to afford the back end expenses.
Indeed, all incentives are pointed towards enshittification of a web thing. I shall try mitigating them as best I can, perhaps making an association similar to KDE to take care of it instead of kw.media. But we’ll get there when we get there, ie once the thing actually works and proves itself to be worthwhile pursuing in the first place.
