Fast access to channel data

[dy]

Working with audio oftentimes there is audio.read(time).getChannelData(channel) to get raw array - pretty long. Is there a sense to provide id-access to channel to make audio.read(time)[channel]? @jamen

We could do that by initializing object properties on AudioBuffer instance.

Object.defineProperties(audioBuffer, {
0: {
get: function () {return this.getChannelData(0)}
},
...
})

Or is it better to patch audioBuffer by audio itself? It is going to do that every read call, pretty slow.

[jamen]

I like the idea of a shorter way to access that data

But two questions I think of:

• Would we keep the two ways to do the same thing? (Does that show some redundancy?)
• Is using audioBuf[int] clear if the reference doesn't have channel in it? I feel like it could be mistook for pulse, but maybe not.

Agree with the doing it every read call would be slow. Allowing syntax from audio and keeping audio-buffer with less forgiving API to the data structure makes sense to me.

[dy]

Ok, audio-buffer is low-level enough structure to keep it sugar-free.

[dy]

Although what if we rename audioBuffer.data to audioBuffer.channels?

• ✅ we would fix that agreement in API, exposing channel data and number of channels naturally, anyways we use array with channels data and unlikely will get back to single-row array.
• ✅ that is natural pattern from audio - to pass channels array
• ✅ that would start making sense for channels argument as [lData, rData]
• ❎ that is not compliant with WAA AudioBuffers, we'd wave to wrap them, although we already non-compatible due to constructor.
• ❎ performance-wise it potentially may be slower than pure audio-buffer, although in long-term that can be winning due to exposed getChannelData(N)
• ❎ in case if we return native AudioBuffer, it will not have that property, although we can define it on the created native buffer − how bad is that? For @audiojs infrastructure that is win, for compatibility that is loss

[dy]

Fixed in audio-buffer@4.0.0