Re: Web Audio API feedback for UC3

Hi Gabriel, thanks for your feedback.

On Fri, Feb 24, 2012 at 6:19 AM, Gabriel Cardoso
<gabriel.cardoso@inria.fr>wrote:

> Hi all,
>
> Some feedback on using the Web Audio API to build a online audio
> worksation => UC3
>
> http://vimeo.com/37250605


Nice!  Thanks for sharing that.


>
>
> I implemented an object I called ProjectListening dealing with sound
> rendering. When instanciated, this object initializes an AudioContext
> and loads audio sources from file urls (inspired by
>
> http://code.google.com/p/chromium/source/browse/trunk/samples/audio/doc/resources/buffer-loader.js
> ).
>
> For each track, an AudioGainNode is created and connected to the context
> var gainNode = this.context.createGainNode ();
> this.gainNodes [track.id] = gainNode;
> gainNode.connect (this.context.destination)
>
> Each clip is added to a list in the ProjectListening object. To play the
> song, an AudioBufferSource is created (context.createBufferSource ())
> for each clips and connected to the AudioGainNode corresponding to its
> track. The clip contain information about his position in the track so
> notOn can be set.
>
> The AudioBufferSource list is emptied when the song is stopped.
>
> That is almost all I've done so far and I found it very instinctive
> (never built an audio app before).
>
> I am able to control tracks volume (gain actually),
> move/remove/duplicate clips.
>
> To mute tracks, I just disconnect the corresponding AudioGainNode from
> the context, but when I reconnect it (unmute), all the clips that
> haven't been played are all played at the same time ! Is it the expected
> behavior ? Should I remove all "past" clips before reconnecting an
> audioGainNode ?
>

To mute tracks, another possibly simpler approach would be to set the
audioGainNode's gain value to 0 temporarily while the track is muted, but
before doing so, make note of the old gain value so when you un-mute you
can restore the gain value.

But, I'm interested in the behavior you were seeing when disconnecting and
then reconnecting.  I'll try to have a look to see if this is a bug, or
just an
expected consequence of the API calls.  It's hard to tell until I see the
exact code.



>
> I also noticed a slight delay on Chrome Fedora that is not existing on
> the Mac OS X version.
>

The Chrome audio latency performance is currently somewhat better on Mac OS
X (and Windows 7) than it is on Linux.  This is because it's hard to tune
the Chrome audio back-end for Linux when it's deployed on a heterogeneous
mixture of Linux configurations and hardware, .asoundrc files, etc.  But,
we still have room to tune there and make improvements.



>
> That's it for now,
>
> Gabriel
>
>
>
>
>