Worin besteht im Web-Audio der Unterschied zwischen der Verwendung von .value (x) und setValueAtTime (x, context.currentTime)?

Question

Ich modifiziere den DelayTime-Audioparameter eines DelayNode. Ich habe versucht, den Wert direkt Eigenschaft verwendet wird, wie in:

delayNode.delayTime.value = x

und auch - was ich dachte, war gleichwertig - die setValueAtTime Methode mit der aktuellen Zeit des Kontexts:

delayNode.delayTime.setValueAtTime(x, context.currentTime)

Werfen wir einen Blick auf die Web-Audio-Spezifikation here, ich lese das in der value Abschnitt der Audio-Parameter:

Der Effekt der Einstellung dieses Attributs (.value) entspricht dem Aufruf von setValueAtTime() mit dem aktuellen currentTime des aktuellen AudioContext und dem angeforderten Wert .

Dennoch bemerkte ich, dass .value direkt verursacht einen großen Audio-Glitch mit, während .setValueAtTime viel weniger laut ist. Sie können durch Klicken auf die Schaltfläche diese in diesen beiden jsFiddles hören (es btw laut ist):

• Change delayTime with .value
• Change delayTime with .setValueAtTime

Meine Frage ist: Was ist der Unterschied besteht darin, die value Attribut zwischen der Verwendung und mit .setValueAtTime mit der aktuellen Zeit? Warum sind sie anders? Was verursacht den Fehler in einem und nicht in dem anderen?

Answer 1

Der Unterschied, den Sie hören, liegt darin, dass das Chrome-Team die Entzifferung, die Chris Rogers ursprünglich in die Implementierung eingegeben hat, nicht entfernt hat. Das Entzerren ist ein allgemeiner Prozess zum Glätten von Parameteränderungen; z.B. Anstatt den Wert direkt zu ändern, könnten Sie setTargetAtTime mit einem kleinen t aufrufen; dann ändert sich der Wert reibungslos.

Für delayTime ist dies besonders problematisch, da jede Änderung zu extremen Störungen führen kann. (Änderungen an einem Verstärkungsparameter können z. B. Störimpulse verursachen, sind aber wahrscheinlich ein wenig weniger dramatisch.)

Chris 'ursprüngliche Implementierung baute Entzippung für alle Parameter auf, so dass Parameteränderungen standardmäßig sein würden glatt, kurz gesagt, wenn Sie den Wert änderten, änderte er nicht wirklich sofort den Wert. Dies verursacht jedoch Probleme bei einigen Parametern (z. B. das Glätten des Frequenzparameters an einem Oszillator erzeugt einen Portamento-ähnlichen Effekt, der häufig unerwünscht ist). Nach vielen Diskussionen (https://github.com/WebAudio/web-audio-api/issues/76) entschied die Web Audio Working Group, dass die Dekomprimierung nicht automatisch sein sollte (Sie können schließlich immer Parameter mit setTargetAtTime glätten); Das Chromium-Team muss es nur aus seinem Code entfernen. (Anscheinend hat Firefox auch ihre Entzippung nicht entfernt.)

In Ihrem Beispiel nehmen Sie eine extreme Änderung an delayTime vor - eine Änderung von vier Sekunden - und es wird über einen sehr kurzen Zeitraum hinweg "geglättet" . Dies ist vergleichbar mit der Verwendung einer analogen Verzögerungsleitung und einer sehr schnellen Änderung der delayTime. (Schauen Sie sich die Demos der Korg Monotron Delay-Einheit an, und Sie werden Geräusche hören, die Ihnen bekannt vorkommen.) Im Gegensatz dazu springt die augenblickliche Änderung (mit setValueAtTime) nur "springend" - es verursacht wahrscheinlich einen Klick, aber Sie nicht höre es sogar im Vergleich.

Kurzgeschichte: Verwenden Sie nicht .value, um die delayTime in dieser Instanz zu setzen, verwenden Sie setTargetAtTime(), wenn Sie es geglättet werden möchten, oder setValueAtTime(), wenn Sie möchten, dass es sofort ist. Große Änderungen an einem delayTime-Parameter verursachen jedoch immer eine Art von Problem. Sie möchten wahrscheinlich zwischen zwei Verzögerungsleitungen oder etwas in der Art überblenden.