Why nuke AudioBuffer?

[labsound]

Why nuke AudioBuffer?

[raub]

To make it clear, I only need JS bindings to think that there are all the WAA-described methods and classes. Even if the backend implementation doesn't really define them. However, if backend has them it is much easier to achieve.

After some inspection of Cromium's implementation, I understood that AudioBus can be used. They've implemented the missing decodeAudioData through MakeBusFromMemory and new AudioBuffer(bus) constructor, that fills AudioBuffer with data from the bus.

However I still consider 2 cases:

• I could (silently) make AB great again, doing so outside the LabSound codebase. But may be you still decide that it should be back in the core and then for me it's better to wait/help for it to happen.
• You are far more experienced in this topic. While my approach is simply copy-paste the missing apis from Chromium's codebase, and tweak it until compilation succeeds, you could offer some better ways of implementing it.

Now, if you decide to fix the WAA compliance of LabSound, maybe we could do it like this: I'll try to come up with a contribution of these apis and then we tweak it together? Or maybe you decide that it would be better and easier if you "unnuked" it yourself?

[meshula]

Gotcha. At the moment I'm thinking about how to implement ABSN in a clean way...

[meshula]

I think a philosophical split we took with LabSound was with the play once nature of the AudioBufferSourceNode. Despite what the WA spec says, creating an ABSN incurs overhead in wiring it into the signal processing graph, and it also introduces variability in onset timing that might be objectionable when used in an instrument. The fact that the ABSN can only be used once also incurs complication (spaghetti!) to the engine in managing the destruction of the node.

The equivalent code to what you link above is as follows

        ContextRenderLock r(context.get(), "TestAudioFile");
        std::shared_ptr<AudioBus> audioFile = MakeBusFromFile("samples/voice.ogg", false);

Using the AudioBus is nearly identical to using AudioBuffer.

        std::shared_ptr  audioFileNode = std::make_shared<SampledAudioNode>();
        voiceNode->setBus(r, voiceClip);

Now that I've explained the issue, it seems to me that creating an AudioBuffer and AudioBufferSourceNode using the new LabSound mechanism would be pretty easy and wouldn't reintroduce spaghetti code, if there's really a need for those two classes.

Since the pattern you mention can be reproduced with MakeBusFromFile, and since SampledAudioNode is a non-self-destructing replacement for the ABSN, I'm wondering if you could comment on whether that's good enough for your needs, or if you see a need for actually having a node with the self-destructing behavior? Also, is there more than the self-destructing behavior of ABSN that is missing?

[raub]

@meshula any success yet?

[meshula]

Here's the design I have in mind:

The AudioBuffer has a one to one mapping with the AudioBus. The AudioBufferSourceNode is one to one with SampledAudioNode. The thing missing is the automatic destruction of the ABSN when complete.

We could define AudioBuffer as a typedef against AudioBus, and AudioBufferSourceNode as a typedef as well. i.e. -

typedef AudioBus AudioBuffer;
typedef SampledAudioNode AudioBufferSourceNode;

The connected AudioBus has a length, the SAN has got a member called m_VirtualReadIndex. That's enough information to know how much time remains. Should probably add a remainingTime() method to the SAN for it.

A ABSNManager would run periodically to test that remainingTime() is zero, and when it is zero, it could call disconnect on all the ABSN inputs and outputs, and then lose the reference to the ABSN. As long as you aren't keeping a copy of the pointer, the ABSN would then vanish. I think the ABSNManager would be a separate utility class that you would instantiate in your code, and run periodically (for example, once every 100ms or so) so that you can control exactly when ABSNs are destroyed.

So all the pieces exist to make it work. I haven't had time to write it yet, but it looks straight forward. Do you want to have a go? Otherwise, it'll be a couple of days before I can get to it.

[raub]

I'm now deep in all those JS bindings stuff. It'll also take a few days. So I can wait for you to try implementing this vision of ABSN.

[raub]

Any updates on that?

I've managed to find a workaround of sorts... I use a lab::AudioBus inside of (js-)AudioBuffer and pass it to the (js-)ABSN. While ABSN is actually lab::SampledAudioNode. And it seem to work, but ASSN is lacking the detune param. Probably it will be easier and closer to the spirit of LabSound if we simply added that param? I'm ok with fixing waa-compliance on my side whenever I'm able to, after all it's me who exports to JS 😺

[meshula]

detune incoming:
meshula@292fca2

[meshula]

API is stable, closing now.