search

brangerbriz / liBB.js

A JavaScript library/framework for creating interactive && generative apps + installations in/out of the browser
http://libb.brangerbriz.com/
GNU General Public License v3.0
1 stars 2 forks source link

BB.Audio: Safari: poorly implemented WebAudio #46

Closed nbriz closed 7 years ago

nbriz commented 7 years ago

...so not only did safari never implement the detune property for AudioBufferSourceNodes but it appears they poorly implemented AudioScheduledSourceNode methods. Though the spec clearly specifics otherwise, on safari you can't call stop more than once

...probably need to create some kind of polyfill to handle this differently on Safari

nbriz commented 7 years ago

turns out that the _removePolyNote()method in the BB.AudioBase class ( which AudioSampler, AudioNoise and AudioTone all derive from ) does a decent enough job of killing the sound at the same time that the .stop() method is scheduled for ( ie. resulting in the same effect ) but does so without actually scheduling the .stop() method && thus gets around this Safari issue.

unfortunately, if u call sound.play(); sound.stop(); u will hear the sound play for a fraction of a second, when in theory a call to stop immediately after play should not make any sound ( this is what calling .stop() inside the Sampler's .stop() method is for ).

for this reason, i've edited the .stop() and the .noteOff() methods where they call: this.input[freq].node.stop( now + hold + release + 0.00005);

to something like:

if( BB.Check.browserInfo().name == "Safari"){
    // see >> https://github.com/brangerbriz/liBB.js/issues/46
} else this.input[freq].node.stop( now + hold + release + 0.00005);

this means on safari there might be a fraction of a second delay between the call to stop() && the actually hearing the sound stop... but seems a reasonable enough "polyfill" for now.