تحديثات صوتية على الويب في Chrome 49

Chris Wilson

يعمل Chrome باستمرار وبهدوء على تحسين توافقه مع Web Audio API. في الإصدار 49 من Chrome (الإصدار التجريبي اعتبارًا من شباط/فبراير 2016، ونتوقع أن يكون الإصدار الثابت متاحًا في آذار/مارس 2016)، عدّلنا العديد من الميزات لتتبُّع المواصفات، وأضفنا أيضًا عقدة جديدة.

تُرجِع دالة decodeAudioData() الآن وعدًا.

تُعرِض الآن الطريقة decodeAudioData() في AudioContext القيمة 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()

للوهلة الأولى، قد يبدو من الغريب استخدام suspend() في OfflineAudioContext. بعد كل شيء، تمت إضافة suspend() إلى AudioContext لتفعيل وضع الاستعداد في الأجهزة الصوتية، ما يبدو غير مجدٍ في السيناريوهات التي يتم فيها معالجة المحتوى في ذاكرة تخزين مؤقت (وهو الغرض من OfflineAudioContext بالطبع). ومع ذلك، فإنّ الهدف من هذه الميزة هو أن تتمكّن من إنشاء جزء فقط من "النتيجة" في المرة الواحدة، لتقليل استخدام الذاكرة. يمكنك إنشاء المزيد من العقد أثناء تعليقها في منتصف عملية التقديم.

على سبيل المثال، تحتوي سوناتا Moonlight على حوالي 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، ولكنه يسمح بتحديد كامل لمَعلمات استجابة الفلتر (بدلاً من BiquadFilterNode AudioParams السهلة الاستخدام في BiquadFilterNode للنوع والتردد وQ وما إلى ذلك). تسمح بنية IIRFilterNode بتحديد دقيق للفلاتر التي لم يكن بالإمكان إنشاؤها في السابق، مثل فلاتر الطلب الواحد. ومع ذلك، يتطلب استخدام IIRFilterNode معرفة عميقة بكيفية عمل فلاتر IIR، ولا يمكن أيضًا جدولتها مثل BiquadFilterNodes.

التغييرات السابقة

أريد أيضًا الإشارة إلى بعض التحسينات التي تم إجراؤها سابقًا: في Chrome 48، بدأ تشغيل BiquadFilter node automation بمعدّل الصوت. لم يتم إجراء أي تغييرات على واجهة برمجة التطبيقات لتنفيذ ذلك، ولكن هذا يعني أنّ عمليات تصفية المحتوى ستبدو أكثر سلاسة. في الإصدار 48 من Chrome، أضفنا التسلسل إلى طريقة AudioNode.connect() من خلال عرض العقدة التي نتصل بها. يسهّل ذلك إنشاء سلاسل من العقد، كما هو موضّح في هذا المثال:

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

هذا كلّ ما لدينا الآن. طاب يومك.