Re: Status v2

Feel free to open up any new issues and proposals you  have in the v2 issue
tracker.  We're  looking for concrete use cases and it sounds like you have
some.

Don't worry about duplicated issues and what not.  We'll take care of it.

We look forward to your comments and ideas!

On Thu, Apr 16, 2020 at 12:07 PM André Michelle <
andre.michelle@audiotool.com> wrote:

> Hi Hongchan,
>
>
> is there some kind of summary for the most important key features? There
> are a lot of issues on github that deal with details of existing
> audio-nodes. I think for many developers that are building complete DAWs
> with their own infrastructure, improving audio-nodes is not that
> interesting. We are looking for the most stable solution to run our own
> dsp-code in a different prioritised thread without any performance crucial
> dependencies like the main gc,  event loop or graphic updates (while I
> understand that the communication between those threads will introduce
> message-latency when the browser is busy, but that is neglectable). More
> important is getting rid of glitches (pops, clicks), that the main thread
> introduces. We are already pooling objects whenever they have a short
> lifetime, but the overall performance seems to be worse than in Flash
> (where everything ran in the main thread). But that is of course
> a subjective observation, since we cannot compare both properly. However
> many users ask for the Flashversion of audiotool, because it ran better for
> them. Especially on Chromebooks. Many schools in the US are using audiotool
> on Chromebooks.
>
> How can I contribute?
> My guess is that fixing those issues is rather about the internal
> infrastructure of the browser than specifications. In theory the
> audio-worklet is the way to go.
>
> The only case I can make is to have an adjustable audio-ring-buffer
> (relaxing the 128 frame block-size) to better handle short performance
> peaks and make it completely independent from the main-thread. I
> understand, it is easier said than done. Does the v2 specifications include
> that? Are you trying to merge v2 into v1? That would explain the issues for
> existing audio-nodes. I guess for most advanced audio programmers a
> parallel v2 with a very simple api (config and push callback like it was in
> pepper) would solved many problems we are facing right now.
>
> This may sound blunt, but let the web-developers build their own
> audio-frameworks. In no time we will have all the currently existing v1
> audio-nodes covered and way more in the future. The actual issue is not
> making better nodes. Developers will always ask for more. But giving them a
> universal access point to a prioritised, configurable thread will certainly
> create more impact, very similar to WebGL (where many frameworks were built
> with amazing features for different tasks).
>
> Thanks for your time :)
>
> ~
> André Michelle
> https://www.audiotool.com
>
> On 16. Apr 2020, at 20:02, Hongchan Choi <hongchan@google.com> wrote:
>
> Hi André,
>
> Your contribution will be tremendously helpful. V2 issue tracker is here:
> https://github.com/WebAudio/web-audio-api-v2/issues
>
> -Hongchan
>
>
> On Thu, Apr 16, 2020 at 10:58 AM André Michelle <
> andre.michelle@audiotool.com> wrote:
>
>> Hi all,
>>
>>
>> where can I see the current status of the web audio api v2? Unfortunately
>> the mails I get in this channel are often very cryptic without the entire
>> context of your meetings. I do not know where to contribute. Any pointers?
>>
>> ~
>> André Michelle
>> https://www.audiotool.com
>>
>>
>