2015-08-27 9 views
6

Il comportamento che sto per descrivere accade in Chrome 44, ma che non accadere in Firefox 40.Web inaspettatamente scivolano da una frequenza all'altra in Chrome

Se si crea un oscillatore, impostarlo ad una frequenza di 220 Hz, e quindi modificare la frequenza a 440 Hz un secondo dopo, si può sentire un effetto di portamento distinto: invece di cambiare istantaneamente da 220 a 440, l'oscillatore scivola dalla frequenza originale a quella nuova.

Il codice di seguito illustra questo fenomeno:

var ac = new AudioContext(); 
 

 
var osc = ac.createOscillator(); 
 
osc.connect(ac.destination); 
 

 
osc.type = 'sawtooth'; 
 

 
osc.frequency.value = 220; 
 
osc.start(0); 
 

 
window.setTimeout(function() { 
 
    osc.frequency.value = 440; 
 
}, 1000); 
 

 
window.setTimeout(function() { 
 
    osc.stop(0); 
 
}, 2000);

Ho esaminato la documentazione per l'oggetto OscillatorNode, e non c'è alcuna menzione di questo comportamento.

Ho anche setacciato Google e (sorprendentemente) non riesco a trovare altre menzioni di questo fenomeno.

Cosa sta succedendo? Questo non sembra un comportamento corretto. Se volessi che la frequenza fosse planata, userei il metodo linearRampToValueAtTime(). Impostare la frequenza direttamente su un valore specifico dovrebbe solo ... farlo.

È solo un errore? So che questa API è ancora in flusso, ma questo sembra abbastanza evidente per essere un bug - questo non avrebbe superato il test più superficiale. Ma non riesco nemmeno ad immaginare che Google la implementerebbe in questo modo deliberatamente.

Soprattutto: c'è una soluzione?

+0

Funziona "correttamente" in Firefox, questo è un problema di webkit, quindi funziona anche con Opera e Safari. –

risposta

4

Abbastanza sicuro che questo sia un bug.

Non riesco a trovare nulla nella specifica che dice che l'assegnazione diretta di value su un AudioParam dovrebbe fare qualsiasi tipo di interpolazione.

È possibile che non sia passato inosservato perché in genere le persone probabilmente modificano il valore utilizzando i metodi di automazione. Che mi porta alla tua domanda di soluzioni alternative ...

Se in realtà volevi un ritardo esplicito, puoi semplicemente farlo (nota che non c'è setTimeout).

// change the value to 440Hz 1 second from now 
osc.frequency.setValueAtTime(440, ac.currentTime + 1); 

Se si vuole essere in grado di cambiare la frequenza immediatamente (per esempio, in risposta a un'azione dell'utente), si può solo fare questo:

osc.frequency.setValueAtTime(440, 0); 

Speranza che aiuta.

A proposito, è necessario considerare l'archiviazione di un problema per questo (https://code.google.com/p/chromium/issues/list).

+1

Grazie! Questa soluzione funziona per me. Probabilmente avrei dovuto pensarci anch'io, ma ... sai. Proverò a ricordare di presentare una segnalazione di bug domani. Saluti! – greenie2600

+0

Nessun problema. Per quello che vale, il comportamento è presente anche in Chrome Canary (Chrome 47) - che è un po 'sorprendente. Di solito non vedo i bug del Web Audio restare così a lungo. –

+0

A proposito, perché le persone in genere modificano il valore utilizzando i metodi di automazione? È per mantenere i tempi stretti? (Immagino che sparare manualmente le modifiche nel momento in cui sono necessarie non sia preciso/affidabile come programmarle in anticipo con setValueAtTime() e simili, ma nei casi in cui si sta rispondendo all'input dell'utente, ad esempio, una Evento MIDI o un cambio di parametro tramite un controllo nel browser: non hai davvero scelta.) – greenie2600

4

Questo è l'effetto "dezippering" incorporato, che il gruppo di lavoro ha fatto avanti e indietro più volte. A partire da giugno, il gruppo di lavoro ha infine deciso di rimuovere il dezippering (stato: https://github.com/WebAudio/web-audio-api/issues/76). Quindi sì, questo è un "bug" di Chrome - https://code.google.com/p/chromium/issues/detail?id=496282). Fino a quando non viene corretto, usa setValueAtTime(), come suggerito da Kevin.

+1

Grazie per il chiarimento, Chris. Mi sono imbattuto in un accenno al dezippering mentre mi guardavo intorno, ma potevo solo trovarlo usato in riferimento a GainNode - quindi non volevo fare il salto che forse era anche usato per gli Oscillatori. –

+0

Sì, attualmente accade per .valore su tutti gli AudioParam. – cwilso

Problemi correlati