Chrome 49 में वेब ऑडियो अपडेट

Chris Wilson
Chris Wilson

Chrome, Web Audio API के साथ काम करने की सुविधा को लगातार और चुपचाप बेहतर बना रहा है. Chrome 49 (फ़रवरी 2016 तक बीटा वर्शन और मार्च 2016 में स्टैबल वर्शन) में, हमने स्पेसिफ़िकेशन को ट्रैक करने के लिए कई सुविधाओं को अपडेट किया है. साथ ही, एक नया नोड भी जोड़ा है.

decodeAudioData() अब एक प्रॉमिस दिखाता है

AudioContext पर मौजूद decodeAudioData() वाला तरीका अब Promise दिखाता है. इससे, Promise पर आधारित असाइनिश्नल पैटर्न को एक साथ मैनेज करने की सुविधा चालू होती है. decodeAudioData() मेथड में, सफलता और गड़बड़ी के कॉलबैक फ़ंक्शन को हमेशा पैरामीटर के तौर पर लिया जाता है:

context.decodeAudioData( arraybufferData, onSuccess, onError);

हालांकि, अब ऑडियो डेटा को डिकोड करने के लिए, स्टैंडर्ड Promise तरीके का इस्तेमाल किया जा सकता है:

context.decodeAudioData( arraybufferData ).then(
        (buffer) => { /* store the buffer */ },
        (reason) => { console.log("decode failed! " + reason) });

हालांकि, एक उदाहरण में यह ज़्यादा शब्दों वाला लगता है, लेकिन प्रॉमिस की मदद से, असाइनिओं के साथ प्रोग्रामिंग करना आसान और बेहतर होता है. साथ काम करने के लिए, स्पेसिफ़िकेशन के मुताबिक, अब भी सफलता और गड़बड़ी वाले कॉलबैक फ़ंक्शन काम करते हैं.

OfflineAudioContext अब suspend() और resume() के साथ काम करता है

पहली नज़र में, OfflineAudioContext पर suspend() का इस्तेमाल करना अजीब लग सकता है. आखिरकार, suspend() को AudioContext में इसलिए जोड़ा गया था, ताकि ऑडियो हार्डवेयर को स्टैंडबाय मोड में रखा जा सके. हालांकि, बफ़र में रेंडर करने के दौरान ऐसा करना बेमतलब है. बेशक, OfflineAudioContext का मकसद यही है. हालांकि, इस सुविधा का मकसद एक बार में "स्कोर" का सिर्फ़ एक हिस्सा बनाना है, ताकि मेमोरी का इस्तेमाल कम से कम हो. रेंडरिंग के बीच में रोके जाने पर, ज़्यादा नोड बनाए जा सकते हैं.

उदाहरण के लिए, बीथोवन के मूनलाइट सोनाटा में करीब 6,500 नोट हैं. ऐसा हो सकता है कि हर "नोट" को कम से कम दो ऑडियो ग्राफ़ नोड में बांटा जाए. जैसे, AudioBuffer और Gain नोड. अगर आपको OfflineAudioContext की मदद से सात आधे मिनट के वीडियो को बफ़र में रेंडर करना है, तो शायद आपको एक साथ सभी नोड नहीं बनाने हैं. इसके बजाय, इन्हें समय के हिसाब से बनाया जा सकता है:

var context = new OfflineAudioContext(2, length, sampleRate);
scheduleNextBlock();
context.startRendering().then( (buffer) => { /* store the buffer */ } );

function scheduleNextBlock() {
    // create any notes for the next blockSize number of seconds here
    // ...

    // make sure to tell the context to suspend again after this block;
    context.suspend(context.currentTime + blockSize).then( scheduleNextBlock );

    context.resume();
}

इससे, रेंडरिंग की शुरुआत में पहले से बनाए जाने वाले नोड की संख्या कम की जा सकती है. साथ ही, मेमोरी की मांग भी कम की जा सकती है.

IIRFilterNode

इस स्पेसिफ़िकेशन में, ऑडियोफ़ाइल के लिए एक नोड जोड़ा गया है. इससे वे अपनी पसंद के मुताबिक, सटीक इनफ़ाइनाइट-इंपल्स-रिस्पॉन्स बना सकते हैं: IIRFilterNode. यह फ़िल्टर, BiquadFilterNode के साथ काम करता है. हालांकि, यह फ़िल्टर, टाइप, फ़्रीक्वेंसी, Q वगैरह के लिए BiquadFilterNode के आसानी से इस्तेमाल किए जा सकने वाले AudioParams के बजाय, फ़िल्टर के जवाब के पैरामीटर की पूरी जानकारी देता है. IIRFilterNode का इस्तेमाल करके, ऐसे फ़िल्टर बनाए जा सकते हैं जिन्हें पहले नहीं बनाया जा सकता था. जैसे, सिंगल-ऑर्डर फ़िल्टर. हालांकि, IIRFilterNode का इस्तेमाल करने के लिए, IIR फ़िल्टर के काम करने के तरीके के बारे में अच्छी तरह से जानना ज़रूरी है. साथ ही, इन्हें BiquadFilterNode की तरह शेड्यूल नहीं किया जा सकता.

पिछले बदलाव

हम कुछ ऐसे सुधारों के बारे में भी बताना चाहते हैं जो पहले किए गए थे: Chrome 48 में, BiquadFilter नोड ऑटोमेशन, ऑडियो रेट पर चलने लगा. ऐसा करने के लिए, एपीआई में कोई बदलाव नहीं किया गया है. हालांकि, इसका मतलब है कि आपके फ़िल्टर स्वीप ज़्यादा बेहतर तरीके से काम करेंगे. साथ ही, Chrome 48 में हमने AudioNode.connect() तरीके में चेनिंग जोड़ी है. इसके लिए, हमने उस नोड को दिखाया है जिससे कनेक्ट किया जा रहा है. इससे नोड की चेन बनाना आसान हो जाता है, जैसा कि इस उदाहरण में दिखाया गया है:

sourceNode.connect(gainNode).connect(filterNode).connect(context.destination);

अभी के लिए बस इतना ही. वीडियो बनाते रहें!