この記事は Smule Engineering team (David Gayle, Chris Manchester, Mark Gills, Trayko Traykov, Randal Leistikow, Mariya Ivanova) による Android Developers Blog の記事 " Smule Adopts Google’s Oboe to Improve Recording Quality & Completion Rates " を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。
これまでで最も多くダウンロードされたカラオケアプリをリリースしている Smule Inc. は、Android で全般的な音質を向上させる取り組みを進めています。具体的にはレイテンシ (遅延) の改善、例えば歌いながらヘッドセットで自分の声を聴けるようにすることです。1,000 万人以上の Android ユーザーに使われている Smule アプリを OpenSL オーディオ API から Oboe オーディオ ライブラリに移行するため、オーディオと動画の専門チームは 2021 年に必要な変更をしました。これにより、録音完了率が 10% 以上向上しています。
Smule Inc. は、たくさんの人々がお気に入りの歌を歌い、日々それを共有できるカラオケアプリのリーディング企業の 1 社です。Smule アプリは、共同制作に特化することで従来のカラオケの枠を超え、友人やプラットフォーム上の他のシンガー、さらにはお気に入りの音楽アーティストと音楽を共有し共同作業ができるという、他にはない機会をユーザーに提供します。特に重要なのは音質で、Smule チームは 2020 年に Android でのエクスペリエンスを改善する可能性を見いだしました。
世界市場の多様なデバイスをサポートしつつ、最新デバイスの超高速ハードウェアを活用するには、Smule が使っていた以前の OpenSL 実装は適切なものではありませんでした。Smule の開発チームは、オーディオ システムのアップグレードが不可欠で、それは合理的な改善であると判断しました。
この改善には 2 つのアプローチがあります。1 つは、Android O で導入され、低レイテンシが求められるアプリ向けに設計された高パフォーマンス Android C オーディオ API である AAudio を直接ターゲットにする方法。もう 1 つは、内部に AAudio と OpenSL の両方を包含した Oboe (英語) を使う方法です。Smule の開発チームは、慎重に評価を行い、使いやすいコードベース、幅広い互換デバイス、手厚いコミュニティ サポートを特徴とする Oboe を採用することにしました。その結果、レイテンシを最低限にとどめ、利用できるネイティブ オーディオを最大限活用することができました。
Oboe への移行は、アーキテクチャとテクノロジーの大きな進化を意味します。そのため、ロールアウト プロセスは慎重に臨みました。段階的にリリースする計画を立て、少数のデバイスモデルから始めて品質を評価しつつ、週を追うごとに有効化するデバイスを増やしました（Oboe で問題が発生したごく一部のデバイスは、OpenSL に戻しました）。この入念な段階的アプローチにより、リスクを最小化でき、エンジニアリング チームも発生したデバイス固有問題に対応できました。
Smule が Oboe に切り替えたのは、アプリのエクスペリエンス向上のためです。期待した成果は、オーディオ再生時のクラッシュを大幅に減らし、録音時のエコーや雑音などの問題をなくし、オーディオ レイテンシを減らすことでした。Android デベロッパー ブログの昨年の記事には、人気のデバイス上位 20 種類での平均レイテンシが、2017 年の 109 ミリ秒から、Oboe を使う現在では 39 ミリ秒に減少したことが記載されています。109 ミリ秒の遅延があると、明らかなエコーとして聞こえるため、ライブで歌う際に邪魔になります。しかし、39 ミリ秒であれば、リアルタイム アプリに許容されるしきい値内に収まります。現在のトップデバイス間のレイテンシの差は、すべて 22 ミリ秒以内に収まっています。この一貫性も大きなプラスです。
Smule が Oboe を使うようになってから録音完了率が上昇したことも、このレイテンシの改善が関連しているでしょう。レイテンシが低下すると、Smule のワールドクラスのオーディオ効果を適用しながら、エコーなしに自分の歌声をヘッドセットで聴くことができます。
Smule が Oboe を組み込む際、Google のチームも深く関与しました。具体的には Oboe 用の GitHub ポータルによる効率的な共同作業を通した、重要な知見やサポートの提供です。2 つのチームの共同作業により、何百万ものアクティブ ユーザーという、これまでで最大の Oboe 展開をリリースすることができました。Smule チームはいくつかの Oboe コードの問題に対処し、Google のチームは一部のモバイル デバイス メーカーとの調整をし、Oboe の互換性をさらに向上させました。
音質は、シンガーのコミュニティにとって最も重要なもの。共同作業によって、できる限り最高のエクスペリエンスを提供し、Smule での音楽制作をサポートできたことに感謝しています。- Smule CTO 、Eric Dumas 氏
大規模に利用されることを考えれば、デバイス固有の問題に直面するのは当然のことです。その顕著な例が、未処理のオーディオ ストリームにエコー効果を挿入する OS ビルトイン機能でした。このような機能が存在すると、Smule 独自の DSP アルゴリズムやオーディオ フィルタを正しく適用できなくなります。その際、Google チームは迅速にライブラリのアップデートやパッチを提供するよう試みました。Oboe の問題を報告するプロセスをシンプルで明確に定義することで、タイムリーに対応したのです。
Smule は特定のチップセットで発生するエラーなど、その他のデバイス固有の問題も協力して克服しました。例えば、Oboe がモノラルのマイク入力を要求したとき、一部のデバイスではステレオ入力を 1 つにミックスし、疑似的にモノラルのマイク入力を提供したのです。Smule は Oboe の GitHub でチケットを作成し、例を提示して、Oboe テスターアプリで問題を再現しました。
Google が開発した Oboe テスターアプリは、実装の問題を特定して解決するうえで便利なツールでした。特に役に立ったのは Oboe、AAudio、OpenSL ES のさまざまな機能のテスト、Android デバイスのテスト、レイテンシや不具合の測定などです。このアプリには非常に豊富な機能があり、ほぼすべてのオーディオ設定をシミュレーションできます。また、Android Intent を使ってシェル スクリプトから Oboe テスターアプリを起動すれば、自動テストにも利用できます。Smule は、大量のデバイスが対象になることを考慮し、この自動テストを有効活用しました。
Smule は、デバイス固有の問題が解消され、Oboe オーディオが十分安定したと確信できた段階で、大規模なスプリット テスト ロールアウトによるアプローチに切り替えました。わずか数週間のうちに、問題のないデバイスで Oboe の利用比率を 10% から 100% に増やしました。これが実現できたのは、リリースが始まってから Oboe に対して継続的に寄せられていた肯定的なフィードバックと、順調な KPI 指標があったからに他なりません。
良い結果も出ています。Oboe 対応の Smule ユーザーは、より多く歌っているのです。重複を省いたカラオケ録音数や歌唱への参加数（デュエット）は、なんと 8.07% も増加しました。また、重複を省いたアップロード数は 3.84%、最後まで歌われた曲の数は 4.10% 増加しました。2021 年の第 3 四半期と第 4 四半期には、録音完了率 が 10% 以上増加しました。
Smule は Google の Firebase Crashlytics ツールを使い、Oboe を完全リリースして以降、オーディオ関連のクラッシュが減少してアプリの安定性が向上したことを把握しています。これはローエンド デバイスでも同様です。Smule の専属カスタマー サポートチームは、意図しない自動音声やエコーなどといったオーディオ関連の苦情が 33% 減少したことに、喜びの声をあげています。
Oboe に切り替えるという決断は、確かに成果をもたらしました。アプリの動作はこれまで以上に良好になり、オーディオのさらなる進化や最新テクノロジーを搭載したハードウェアに対応する準備も整っています。何より、Smule ユーザーは楽しく音楽制作にあたることが出来ています。
.png)
