5 ms·

> Any app that does audio has at least two threads of execution: the main thread, and the audio thread As a side note, I sure wish browsers would hurry up and

by fenomas 10y ago

> Any app that does audio has at least two threads of execution: the main thread, and the audio thread As a side note, I sure wish browsers would hurry up and implement web audio workers so that this could be true for me!

eterm 10y ago
Why don't we have have sandbox execution environments in the OS itself? Why do we have a web browser at all and not just a way of running arbitrary code from a network in a sandbox? We'll end up re-imagining the browser as an OS with workers for anything an OS could do anyway in the end if we continue to need to have the browser act as an application runner.
- vertex-four 10y ago
  > Why don't we have have sandbox execution environments in the OS itself? Well, if you try, you wind up with something that looks an awful lot like a web browser - especially once WebAssembly is a thing. The API that many desktop operating systems provide is not designed for the security model that you're looking for, so you wind up building a new one on top of it - see WinRT when Microsoft needed a sandbox. We used to have things like Java Web Start (still do in some enterprise systems), and, well, it's not exactly any better than a web browser except that it has a better view layer for applications than HTML/CSS. It's also not supported on mobile platforms.
- pjmlp 10y ago
  > Why don't we have have sandbox execution environments in the OS itself? We do, that is how mainframes work. It is also available in Mac OS X, Windows and mobile OSes, one just needs to make use of the respective APIs. As for the GNU/Linux and *BSD I am out of touch how good the current sandbox support for cnames, Lx and others actually is.
- moron4hire 10y ago
  It was called Java and it never lived up to the promise. The browser may not be the app deployment system we want, but it is certainly the one we deserve
- moron4hire 10y ago
  It was called Java and it never lived up to the promise. The browser may not be the app deployment system we want, but it is certainly the one we deserve
padenot 10y ago
An `AudioContext` (which is the object that lets you do non-trivial audio in the browser) does most of its work on a special, high priority thread, off an audio callback. Having `AudioContext` in a worker does not get you a lot. It's planned, but not prioritized very high. What happens when you're calling methods in JavaScript on an `AudioContext` is that we simply validate the input and queue messages to the audio thread, so this is effectively exactly what the article is talking about. We use some locking, but we've carefully wrote the code so that it's not really an issue. We lock just to swap two pointers in a message queue. This could certainly use atomics, but we have more important things to do first. That said, the interesting thing developers need and want is `AudioWorklets` [0], and that's what we at the W3C Audio WG is working on more or less full-time, these days. It used to be called `AudioWorker`, but got renamed for a lot of reasons [1]. [0]: https://github.com/WebAudio/web-audio-api/wiki/AudioWorklet-IDL-Proposal https://github.com/WebAudio/web-audio-api/wiki/AudioWorklet-... [1]: https://github.com/WebAudio/web-audio-api/issues/532 https://github.com/WebAudio/web-audio-api/issues/532
- fenomas 10y ago
  Thanks, this is very useful! Follow up questions, if you see them: 1. Does what you said include ScriptProcessorNodes? 2. Is this true of all browsers per specification, or true of a particular browser's implementation? My experience with web audio has been that in Chrome things work as you say, but in FF I could never find a webaudio library that played back without heavy clicking, so I supposed audio workers might help. 3. Given what you said, what will be different about Worklets? I scanned the links but I guess I don't follow the bigger picture.
  - padenot 10y ago
    1. No, it's the one thing that has to be on the main thread per spec. 2. It's true for all browsers. ScriptProcessor runs on the main thread and can be glitchier in Firefox (but depending on the use case it can be the opposite). See https://padenot.github.io/web-audio-perf/#scriptprocessornode https://padenot.github.io/web-audio-perf/#scriptprocessornod... for more details. 3. Worklets are bits or javascript that run on the audio thread directly, where you're supposed to only implement the DSP bits, and only communicate with the main thread using message passing.

by fenomas 10y ago

eterm 10y ago

Why don't we have have sandbox execution environments in the OS itself? Why do we have a web browser at all and not just a way of running arbitrary code from a network in a sandbox? We'll end up re-imagining the browser as an OS with workers for anything an OS could do anyway in the end if we continue to need to have the browser act as an application runner.

vertex-four 10y ago
> Why don't we have have sandbox execution environments in the OS itself? Well, if you try, you wind up with something that looks an awful lot like a web browser - especially once WebAssembly is a thing. The API that many desktop operating systems provide is not designed for the security model that you're looking for, so you wind up building a new one on top of it - see WinRT when Microsoft needed a sandbox. We used to have things like Java Web Start (still do in some enterprise systems), and, well, it's not exactly any better than a web browser except that it has a better view layer for applications than HTML/CSS. It's also not supported on mobile platforms.
pjmlp 10y ago
> Why don't we have have sandbox execution environments in the OS itself? We do, that is how mainframes work. It is also available in Mac OS X, Windows and mobile OSes, one just needs to make use of the respective APIs. As for the GNU/Linux and *BSD I am out of touch how good the current sandbox support for cnames, Lx and others actually is.
moron4hire 10y ago
It was called Java and it never lived up to the promise. The browser may not be the app deployment system we want, but it is certainly the one we deserve
moron4hire 10y ago
It was called Java and it never lived up to the promise. The browser may not be the app deployment system we want, but it is certainly the one we deserve

padenot 10y ago

An `AudioContext` (which is the object that lets you do non-trivial audio in the browser) does most of its work on a special, high priority thread, off an audio callback. Having `AudioContext` in a worker does not get you a lot. It's planned, but not prioritized very high. What happens when you're calling methods in JavaScript on an `AudioContext` is that we simply validate the input and queue messages to the audio thread, so this is effectively exactly what the article is talking about. We use some locking, but we've carefully wrote the code so that it's not really an issue. We lock just to swap two pointers in a message queue. This could certainly use atomics, but we have more important things to do first. That said, the interesting thing developers need and want is `AudioWorklets` [0], and that's what we at the W3C Audio WG is working on more or less full-time, these days. It used to be called `AudioWorker`, but got renamed for a lot of reasons [1]. [0]: https://github.com/WebAudio/web-audio-api/wiki/AudioWorklet-IDL-Proposal https://github.com/WebAudio/web-audio-api/wiki/AudioWorklet-... [1]: https://github.com/WebAudio/web-audio-api/issues/532 https://github.com/WebAudio/web-audio-api/issues/532

fenomas 10y ago
Thanks, this is very useful! Follow up questions, if you see them: 1. Does what you said include ScriptProcessorNodes? 2. Is this true of all browsers per specification, or true of a particular browser's implementation? My experience with web audio has been that in Chrome things work as you say, but in FF I could never find a webaudio library that played back without heavy clicking, so I supposed audio workers might help. 3. Given what you said, what will be different about Worklets? I scanned the links but I guess I don't follow the bigger picture.
- padenot 10y ago
  1. No, it's the one thing that has to be on the main thread per spec. 2. It's true for all browsers. ScriptProcessor runs on the main thread and can be glitchier in Firefox (but depending on the use case it can be the opposite). See https://padenot.github.io/web-audio-perf/#scriptprocessornode https://padenot.github.io/web-audio-perf/#scriptprocessornod... for more details. 3. Worklets are bits or javascript that run on the audio thread directly, where you're supposed to only implement the DSP bits, and only communicate with the main thread using message passing.