[HN Gopher] Change the destination output device in Web Audio
___________________________________________________________________
Change the destination output device in Web Audio
Author : feross
Score : 26 points
Date : 2023-01-11 07:17 UTC (2 days ago)
(HTM) web link (developer.chrome.com)
(TXT) w3m dump (developer.chrome.com)
| aliqot wrote:
| This is pretty cool, I'm curious if we'll see DAWs start
| targeting the browser as a platform. I could see Bitwig or
| Ableton accomplishing this. Curious if Cockos has this in their
| sites, given that they seem to be most active and forward
| thinking.
| PaulDavisThe1st wrote:
| Not sure what the metric for "most active and forward thinking"
| is, given that Ardour already has support for websocket-based
| browser control surfaces, and in general releases as often or
| more often than Reaper.
|
| But anyway ...
|
| Given that we already have things like Cardinal (a FLOSSier
| version of VCV Rack) running directly in the browser, I expect
| that a wasm port of an open source DAW will likely occur within
| a few years. Whether that would be a good thing is a different
| question. Browser audio is absolutely not the ideal platform
| for pro-audio (if indeed it is even possible to get the
| required performance at all), but for "bedroom producers" and
| podcasters, it might be sufficient.
|
| The problem is that many (not all, but most) DAWs are built on
| native toolkits (in-house or 3rd party) that assume access to a
| very large operating system API. Although wasm/browser-land
| keeps expanding, it is still quite a long way from covering all
| the things that the (e.g. 86) libraries relied by on a typical
| native DAW require from the host environment.
| fleventynine wrote:
| For collaboration between "bedroom producers", a wasm-based
| plugin ecosystem would be a huge upgrade from a native DAW. I
| hate trying to share a project and having to worry about "do
| they have the right plugins/softsynths installed" and other
| tedious technical distractions. I'd be happy to give up 50%
| performance (of a native DAW) for the collaboration benefits
| alone.
| PaulDavisThe1st wrote:
| Collaboration doesn't require a wasm based ecosystem, and
| in addition a was-based plugin ecosystem is ... well, i
| don't even know what you're talking about there to be
| honest. There are plugins you already cannot get on a given
| platform ... do you think that adding a new platform that
| is likely less performant and has the same "almost fully
| portable but not quite" characteristics is going to help or
| convince plugin developers to support it too?
|
| Collaboration requires common file formats above all else.
| Sharing plugins is the icing on the cake, and frequently
| not necessary. With sufficient bandwidth, realtime
| collaboration with everyone using their own preferred DAW
| is also fairly possible.
| fleventynine wrote:
| There are lots of better word processors than Google
| Docs, but most of the docs I contribute to are hosted on
| it because it requires zero friction for a newcomer to
| collaborate.
|
| What I want is the equivalent of Google Docs for audio
| and MIDI, with a thriving ecosystem of plugins and
| softsynths that everyone can use in any project with zero
| friction (and none of this "let me bounce that track to
| audio since you don't have that plugin" nonsense).
| PaulDavisThe1st wrote:
| > What I want is ...
|
| Google Docs has no plugins. Google Docs is not a tool for
| accomplishing a task that used to be (and to some extent
| still is) considered a lifelong learning experience
| requiring significant skill (audio engineering). Google
| Docs does not rely on an ecosystem of several hundred 3rd
| party developers providing "critical" functionality for a
| given project.
|
| I'm fairly sure that you will get a relatively functional
| DAW in the browser very soon (some might argue that it's
| already here). However, it is likely to be disjoint from
| the pro-audio "native" world because the features
| required by the latter are not likely to show up in the
| browser for a long time (this is a prediction, and I am
| ready to see it prove false).
|
| I therefore see the DAW world bifurcating into an even
| more broken up version of itself than we already have
| (where Logic doesn't run on Windows, where AU plugins are
| macOS only, where there's no remotely acceptable portable
| session file format, where there's at least 3 and maybe 5
| plugin APIs that any given developer needs to consider,
| etc. etc.)
|
| Bedroom producers, podcasters and others with limited
| needs will find a lovely new world waiting for them in
| the browser. Live performance, soundtrack and other large
| scale productions will probably remain native. Some
| plugins will exist for the browser (just like some do for
| Linux today), many will not.
| cageface wrote:
| I think you're right at least in the near term but I
| wouldn't be surprised to see a low-friction browser based
| music production tool start to rapidly build a following
| the way that Rebirth or Fruity Loops did in their day.
| Especially for electronic music the performance
| requirements are not that strict and easy entry and
| collaboration could be enough to attract a large
| userbase.
| fleventynine wrote:
| > Google Docs is not a tool for accomplishing a task that
| used to be (and to some extent still is) considered a
| lifelong learning experience requiring significant skill
| (audio engineering)
|
| I would argue that the lifelong learning experience has
| more to do with developing a good ear (and taste) than
| learning specific technical tools or workflows. Anything
| that helps experienced audio engineers collaborate with
| talented musicians and composers working from home is a
| good thing.
|
| With regards to plugin APIs, hopefully the web-DAW
| community can agree on a de-facto standard based around
| WebAssembly, and ideally that standard would be fully
| open. If it is successful, the native DAWs have the
| option of supporting it too.
| PaulDavisThe1st wrote:
| > Anything that helps experienced audio engineers
| collaborate with talented musicians and composers working
| from home is a good thing.
|
| Right, but if you get paid to do this sort of thing and
| thus time-is-money, then networked-based collaboration is
| likely to prove more productive than reducing the toolset
| to what can be done in-browser. Those tools already
| exist, but once again are deeply fragmented.
| fleventynine wrote:
| Don't underestimate the value of asynchronous
| collaboration (where person A is working on the project
| while person B is doing something else).
|
| Sometimes "using the absolute best tools regardless of
| platform" is not the thing to optimize for.
|
| Maybe the client wants to tweak their vocal performance
| and get a mastered mixdown right away (using the
| engineer's last-used settings for the session) without
| waiting (or paying) for them to re-do the master.
| spacebeer wrote:
| Or you could make a OS/DE for normal people, with an option to
| change audio output per program with 2 clicks, like KDE Plasma
| does.
| goodSteveramos wrote:
| Agreed. Web apps have no business knowing what my audio config
| is. Instead of the OS or browser implementing a working sound
| picker, every single website will have to do it and all but the
| big ones will do it slightly wrong. Google is positioning the
| web for them to take over the desktop.
| zamadatix wrote:
| It's more easily explained as always wanting your web
| conference call to use your headset even if normally you want
| the browser to use something else than as a replacement for
| changing your OS settings.
|
| The web is constantly positioned to takeover the desktop
| though, has been for many years at this point.
| echelon wrote:
| Absolutely they do! This makes it possible to develop and
| distribute your app on the web, which is much easier than
| supporting native downloads.
___________________________________________________________________
(page generated 2023-01-13 23:01 UTC)