אודיו Bluetooth עם צריכת אנרגיה נמוכה

התקן Bluetooth Low Energy Audio ‏ (LEA) מבטיח שהמשתמשים יוכלו לקבל אודיו באיכות גבוהה בלי לפגוע בחיי הסוללה, ומאפשר להם לעבור בצורה חלקה בין תרחישי שימוש שונים. ‫Android 13 (רמת API‏ 33) כוללת תמיכה מובנית ב-LEA.

רוב האוזניות עם LEA יהיו במצב כפול עד שנתח השוק של מכשירי המקור עם LEA יגדל. המשתמשים צריכים להיות מסוגלים להתאים ולהגדיר את שני אמצעי התקשורת באוזניות שלהם במצב כפול.

תרחישים לדוגמה

כדאי לשלב LEA במקרים הבאים:

• שיתוף אודיו: משתמשים יכולים לשתף בו-זמנית כמה מקורות אודיו למכשיר אודיו אחד או יותר. האודיו מסונכרן בין מכשיר המקור לבין המכשירים המחוברים.

• שידור אודיו: המשתמשים יכולים לשדר אודיו לחברים ולבני משפחה, וגם להתחבר לשידורים ציבוריים כדי לקבל מידע, ליהנות מבידור או להשתמש בתכונות נגישות.

• תמיכה בקודק אודיו LC3: זהו קודק האודיו שמוגדר כברירת מחדל, והוא מחליף את קודק ה-SBC שמשמש ל-A2DP (מדיה) ול-mSBC ב-HFP (קול). ‫LC3 יעיל יותר, ניתן להגדרה מחדש ואיכותי יותר.

• שיפורים בדגימת אודיו: אוזניות יכולות לשמור על איכות אודיו גבוהה כשמשתמשים במיקרופונים. ב-Bluetooth classic, איכות האודיו נמוכה יותר כשמשתמשים במיקרופונים של Bluetooth. באודיו BLE, הדגימה של הקלט והפלט יכולה להגיע ל-32kHz.

• מיקרופון סטריאו: אוזניות Hearables יכולות להקליט אודיו באמצעות מיקרופונים סטריאו כדי לשפר את האודיו המרחבי.

• תמיכה בפרופיל של מכשירי שמיעה (HAP): פרופיל HAP מציע למשתמשים נגישות ושימוש טובים יותר בהשוואה לפרוטוקולים קודמים של ASHA. המשתמשים יכולים להשתמש במכשירי השמיעה שלהם לשיחות טלפון ולאפליקציות VoIP.

• תמיכה בפרוטוקול EATT (פרוטוקול תכונות משופר): פרוטוקול EATT מאפשר למפתחים לשלוח כמה פקודות בבת אחת לאוזניות שמשויכות למכשיר.

תרחישים מרכזיים

יש ארבע קטגוריות עיקריות של תרחישי שימוש:

1. שיחות: אפליקציות של חייגן ו-VoIP שדורשות ניתוב תקשורת עם זמן אחזור נמוך, מציעות אודיו באיכות גבוהה וצריכת סוללה נמוכה יותר.

2. גיימינג: הפעלה בו-זמנית של המיקרופון והשמעה באיכות גבוהה מאפשרת להזרים אודיו באיכות גבוהה למכשירי שמיעה. אפליקציית משחקים יכולה לגשת לקלט אודיו של BLE כשמשחק מפעיל את מיקרופון ה-Bluetooth כשהוא מוכן לשימוש. לאחר מכן, כששחקן מתחיל שיחה בזמן אמת עם שחקן אחר, אפליקציית המשחק יכולה להשתמש בנתוני המיקרופון ללא עיכוב.

3. מדיה: לאפליקציות מדיה מותר להגדיר את המכשיר המועדף של מנהל האודיו. המשתמש יכול לשנות את ההגדרה הזו על ידי שינוי המכשיר המועדף בהגדרות המערכת.

4. נגישות: עכשיו אפשר להשתמש במיקרופון של מכשירי שמיעה שתומכים באודיו BLE, כך שהמשתמשים יכולים להמשיך להשתמש במכשירי השמיעה שלהם במהלך שיחה.

ממשקי API ושיטות של BLE Audio

כדי לתמוך במכשירי שמיעה עם אודיו ב-BLE, צריך להשתמש בממשקי ה-API ובשיטות הבאים:

AudioManager

• ‫setCommunicationDevice() בחירת מכשיר האודיו שבו יש להשתמש בתרחישי תקשורת, למשל שיחות קוליות או שיחות וידאו. אפליקציות של שיחות קוליות או וידאו צ'אט יכולות להשתמש בשיטה הזו כדי לבחור מכשיר אודיו אחר במקום המכשיר שנבחר כברירת מחדל על ידי הפלטפורמה. ממשק ה-API הזה מחליף את ממשקי ה-API הבאים שהוצאו משימוש: ‫startBluetoothSco(), ‫stopBluetoothSco(), ו-setSpeakerphoneOn().
• clearCommunicationDevice() מופעל אחרי שהאפליקציה מסיימת שיחה או סשן, כדי לוודא שהמשתמש ייהנה מחוויה מעולה כשהוא עובר בין אפליקציות שונות.

BluetoothProfile

• ‫BluetoothLeAudio שולט בשירות ה-Bluetooth באמצעות אובייקט proxy.

Telecom InCallService

• ‫InCallService#requestCallEndpointChange() מחליף את ממשקי ה-API שהוצאו משימוש InCallService.setAudioRoute() ו-InCallService.requestBluetoothAudio(), כדי לאפשר לאפליקציות לשלוח בקשה לניתוב אודיו אל CallEndpoint ספציפי. הלקוחות לא צריכים להגדיר CallEndpoint משלהם כשהם מבקשים שינוי. במקום זאת, נקודת הקצה החדשה צריכה להיות אחת מנקודות הקצה התקפות שסופקו על ידי InCallService.onAvailableCallEndpointsChanged(java.util.List).
• ‫CallEndpoint.TYPE_BLUETOOTH מפנה את שידור האודיו דרך Bluetooth.
• ממשקי ה-API שצוינו למעלה InCallService מיועדים לשימוש באפליקציית הטלפון שמוגדרת כברירת מחדל בטלפון Android, או בממשקים אחרים לשיחות כמו מכשירים לבישים, מכוניות או מכשירי Bluetooth אחרים שעשויים להשפיע על ניתוב האודיו.

Telecom CallControl

• הסיווג החדש CallControl נוסף ברמת API‏ 34 כדי להחליף את Connection ואת ConnectionService באפליקציות VoIP בלבד.
• CallControl.requestCallEndpointChange() מבקש גם לשנות את CallEndpoint. ה-API הזה מחליף את ממשקי ה-API Connection.requestBluetoothAudio() ו-Connection.setAudioRoute() שהוצאו משימוש.
• בנוסף לממשקי ה-API המעודכנים של פלטפורמת Telecom, מומלץ מאוד להשתמש בספריית Telecom Jetpack כשמפתחים אפליקציות לשיחות קוליות או לשיחות וידאו. הספרייה הזו יכולה לפשט מאוד את תהליך השילוב ולשפר את השיחות ב-VoIP בכל הפלטפורמות של Android.

פרטי מכשיר האודיו

• ‫AudioDeviceInfo.TYPE_BLE_HEADSET מתאר את סוג מכשיר האודיו כמכשיר LEA. משמש לזיהוי אם המכשיר השמיעתי הוא מכשיר LEA.

מקליט אודיו

• ‫setPreferredDevice() מגדיר את המכשיר המועדף לשימוש בניתובי אודיו. המשתמש יכול לשנות את ההגדרה הזו בהגדרות המערכת.

מתאם Bluetooth

• ‫isLeAudioSupported(): מחזירה קבוע @BluetoothStatusCodes (FEATURE_SUPPORTED,‏ FEATURE_NOT_SUPPORTED או קוד שגיאה) שמציין אם חומרת המכשיר תומכת ב-LE Audio.
• ‫isLeAudioBroadcastSourceSupported(): מחזירה קבוע @BluetoothStatusCodes (FEATURE_SUPPORTED,‏ FEATURE_NOT_SUPPORTED או קוד שגיאה) שמציין אם חומרת המכשיר תומכת במקור שידור של LE Audio.

מדריכים לפי תרחיש שימוש

בהמשך מפורטות הנחיות להטמעה של LEA על סמך תרחישי שימוש ספציפיים.

אפליקציות לתקשורת קולית

אפליקציות לתקשורת קולית יכולות לנהל את ניתוב האודיו ואת מצב המכשיר בעצמן, או להשתמש ב-Telecom API שמבצע את ניתוב האודיו ואת לוגיקת המצב בשבילכם.

• בניהול עצמי: אם האפליקציות משתמשות כרגע ב-startBluetoothSco(),‏ stopBluetoothSco() ו-setSpeakerphoneOn() או שאתם רוצים לנהל בעצמכם את מצב ניתוב האודיו, אתם יכולים להיעזר במדריך לניהול עצמי של Audio Manager.

• מנוהל: משתמשים בספריית Telecom Jetpack או בממשקי API של פלטפורמת Telecom כדי ליצור אפליקציה לשיחות אודיו או וידאו.

שני הפתרונות האלה מאפשרים לכם לשלוט במהירות ובקלות בניתוב אודיו ולעבור בין מכשירי Bluetooth. מידע נוסף זמין במדריך לניהול שיחות בטלפון.

אפליקציות להקלטת אודיו

• כלי הקלטת מדיה: כשמקליטים אודיו באמצעות כלי הקלטת המדיה, אפשר עכשיו להקליט בסטריאו אם מכשיר השמיעה עם Bluetooth תומך ב-LEA. כדאי לעיין במדריך להקלטת אודיו.

המלצות לאוזניות

ככל שיותר אוזניות LEA יוצאות לשוק, אנחנו מגלים בעיות בבדיקות בעולם האמיתי שפוגעות בחוויית המשתמש. המפרט לא כולל את כל הבעיות האלה. בטבלה הבאה מפורטות המלצות ליצרני אוזניות LEA, שיעזרו להם לשפר את חוויית השימוש הכוללת של משתמשי Android.

תיאור	הקשר
תמיכה ב-Cross Transport Key Derivation (CTKD) לאוזניות במצב כפול: תמיכה בנגזרת מפתח להתאמה מ-Classic ל-LE ולהתאמה מ-LE ל-Classic.	רוב האוזניות החדשות של LEA יהיו במצב כפול עד שנתח השוק של מכשיר המקור של LEA יגדל. חשוב שהמשתמשים יוכלו להתאים את האוזניות שלהם למצב כפול בצורה חלקה ולהגדיר את שני הפרוטוקולים. זה חשוב גם לטכנולוגיית ההתאמה המהירה של Google.
תמיכה בהודעות ממוקדות (TA) אם רוצים שאוזניות LEA יתחברו מחדש באופן מהימן למכשירי המקור. אוזניות LE Audio צריכות להשתמש ב-TA כדי לבקש חיבור נכנס ממכשירים מרכזיים. התוכן יתווסף ל-BT SIG הקרוב.	בניגוד למודל האיתות של BR/EDR שבו אפשר ליצור חיבור באמצעות הטלפון או האוזניות, ב-LEA החיבור חייב להתבצע באמצעות המכשיר המרכזי. בשלב הזה, הרבה אוזניות לא משתמשות ב-TA, מה שאומר שהמכשיר המרכזי לא יוכל להתחבר מחדש למכשיר ההיקפי בלי להוסיף אותו לרשימת ההיתרים. עם זאת, פתרון עקיפה של רשימת ההיתרים עשוי למנוע מהאוזניות להתחבר למכשיר מרכזי אחר. לכן, חשוב שאוזניות LEA יתמכו בצורה נכונה ב-TA, כדי שהמכשיר המרכזי יוכל להתחבר מחדש בצורה מהימנה ללא פתרונות עקיפים שעלולים לשבש חיבורים מרובי נקודות.
יכולת גילוי משופרת של אוזניות במצב כפול האוזנייה הראשית – רכיב BR/EDR צריכה לפרסם באמצעות הכתובת הציבורית שלה, לאפשר סריקה של דפים ושאילתות עם השם שלה שזמין דרך EIR, ולהגדיר את ביט 14 של LE Audio ל-1 ב-Major Service Classes של Class of Device ‏ (CoD). האוזנייה הראשית – רכיב LE: האוזנייה הראשית צריכה לבצע פרסום של חיבור וגילוי (מוגבל או כללי) באמצעות אותה כתובת ציבורית כמו רכיב BR/EDR, ואותו שם מקומי מלא כמו רכיב BR/EDR, עם הגדרת קטגוריית המראה שלה כקטגוריית מראה מתאימה שתואמת לסוג המכשיר המרוחק, מתוך ציפייה שהמכשיר המרכזי ישתמש במידע הזה כדי להתאים את ממשק המשתמש ואת מדיניות ניתוב האודיו שלו. האוזנייה המשנית – LE בלבד: האוזנייה המשנית צריכה לבצע שידור של מודעה שאפשר להתחבר אליה, שלא ניתן לגלות אותה, עם הגדרת Appearance Category (קטגוריית מראה) מתאימה שתואמת לסוג המכשיר שמחובר לרשת אחרת, מתוך ציפייה שהמכשיר המרכזי ישתמש במידע הזה כדי להתאים את ממשק המשתמש ואת מדיניות ניתוב האודיו שלו. אחת מאוזניות ה-earbuds צריכה להיבחר באופן דינמי מתוך קבוצת ה-CSIP כמכשיר הראשי. אם האוזנייה היא במצב כפול, המכשיר הראשי חייב להיות במצב כפול כדי להבטיח שגם הפונקציות של LE וגם הפונקציות של Classic יפעלו בצורה תקינה אחרי ההתאמה.	כך נמנעת הצגה של אוזניות LEA במצב כפול כרשומות כפולות בהגדרות ה-Bluetooth, מה שעלול לבלבל את המשתמשים ולפגוע בחוויית ההתאמה של LEA. בחירת מנהיג דינמית חשובה במיוחד למכשירים במצב כפול שמזווגים באופן מצטבר. לדוגמה, אם רק אוזנייה אחת זמינה בזמן ההתאמה הראשונית, היא צריכה להציג את עצמה כמכשיר במצב כפול. כשמשתמש מצמיד אוזנייה שנייה בשלב מאוחר יותר, הוא צריך להצמיד רק את רכיב ה-LE, ו-CSIP יוודא שהן יקובצו יחד ב-Android. מומלץ להשתמש בכתובת הזהות במהלך ההתאמה כי רכיב ה-BR/EDR כבר חושף את הכתובת הציבורית של המכשיר למכשירים קרובים.
תמיכה בפרוטוקול מאפיינים מתקדם (EATT).	מקצר את זמן ההמתנה לחיבור ולצימוד.
תמיכה בשמירת מטמון חזקה של GATT.	הפחתת זמן האחזור של החיבור, במיוחד באוזניות TWS.
תמיכה בדירוג משנה של חיבור.	ההגדרה מאפשרת תזמון גמיש יותר של מנות נתונים וחיסכון פוטנציאלי בסוללה.
חשוב לוודא שבמהלך העיבוד המקדים והעיבוד שלאחר מכן, הן בהפעלה והן בלכידה, צינור העיבוד של האות יכול לפעול בתדרים של 16, 24, 32 ו-48 קילוהרץ, וגם לתמוך בתדרים גבוהים יותר.	הוא מנצל את שיעורי הדגימה הגבוהים יותר שנתמכים בנתיבי לכידה של שיחות LEA או VoIP ובהפעלת מדיה.
תמיכה בבקרת צריכת חשמל ב-LE	ניהול צריכת חשמל משופר

תמיכה בסוג הקשר

תיאור	הקשר
צריך להשתמש בכל סוגי ההקשר שצוינו בAssigned Numbers 6.12.3, אלא אם האוזניות לא תומכות באופן מפורש בסוג הקשר מסוים.	לדוגמה, אם סוג ההקשר 'משחק' לא נתמך, מערכת Android תשלח צלילים של משחק. חשוב לשים לב שההגדרה 'לא צוין' לסוג ההקשר לא אומרת 'כל סוג הקשר', והיא לא כוללת סוגי הקשר שלא נתמכים.
כשמכשיר מרכזי מתקשר עם ASCS של מכשיר היקפי, המכשיר ההיקפי צריך להתחבר ל-MCS ול-TBS של המכשיר המרכזי. יכול להיות שהמכשיר המרכזי לא תמיד ישתמש באודיו LE כנתיב סטרימינג, כי יכול להיות שהוא יחזור להשתמש ב-A2DP או ב-HFP. המכשיר ההיקפי יכול להשתמש באינטראקציה של ASCS כאינדיקציה לכך שהמכשיר המרכזי ישתמש ב-LE Audio להזרמה. דוגמאות לאינטראקציות עם ASCS הן קריאה, כתיבה ורישום לקבלת הודעות.

המלצות למשדרים של Auracast

בקטע הזה מפורטות המלצות להגדרת משדרי Auracast.

שידורים לסירוגין

הודעות קוליות במקומות ציבוריים, כמו מסופי תחבורה, הן לרוב לסירוגין ומופרדות על ידי תקופות ארוכות של שקט. הזרמה רציפה של שקט או אודיו ברקע בין ההודעות מבזבזת את הסוללה של המקלט ומונעת מהמשתמשים להאזין לזרם האודיו העיקרי שלהם, כמו מדיה מקומית או זרם Auracast פעיל אחר.

כדי לשפר את חוויית המשתמש, מומלץ שמכשירי שידור של Auracast יפעלו לפי ההנחיות הבאות לטיפול בשידורים לסירוגין.

הגדרות

• אודיו שמעניין: תוכן המידע העיקרי שמיועד למשתמש, כמו הודעה על שער או על רכבת.
• שמע ברקע: שקט ברקע, רעש סטטי או מוזיקה סביבתית שמועברים בין תקופות של שמע שמעניין.
• שידור לסירוגין: שידור שמתחלף בין תקופות של אודיו שמעניין את המשתמש לבין תקופות של אודיו ברקע או ללא אודיו בכלל.

זיהוי שידורים לסירוגין

כדי להגדיר שידור כשידור לסירוגין, הגורם המשדר צריך לכלול את מבנה ה-LTV (אורך-סוג-ערך) של מטא-נתונים של Audio_Active_State [1] בשני מקומות:

1. מטא-נתונים ברמה 2 של מבנה BASE (פרסומים תקופתיים) [2]
2. מטא-נתונים של הודעות לציבור (פרסומות מורחבות) [3]

כדי לעזור למקבל לזהות את השידור לסירוגין ולהחליט אם להפעיל את הסטרימינג, הגורם המשדר צריך גם להגדיר בצורה מדויקת את מבנה ה-LTV של המטא-נתונים Streaming_Audio_Context [1].

זיהוי אודיו שמעניין אתכם

כדי לסמן באופן דינמי אם שידור לסירוגין מכיל אודיו מעניין בכל זמן נתון, המשדר משתמש במבני מטא-נתונים של LTV מסוג Audio_Active_State.

• מטא-נתונים של מבנה BASE ברמה 2: ערך של 0x01 מציין שתת-הקבוצה של BIS מכילה כרגע אודיו שמעניין את המשתמש.
• מטא-נתונים של הודעה על שידור ציבורי: ערך של 0x01 מציין שלפחות אחד מ-BIS בתוך BIG מכיל אודיו שמעניין את המשתמש.

ערכי ה-LTV של המטא-נתונים Audio_Active_State צריכים להיות מוגדרים ל-0x01 זמן קצר לפני השידור של Audio-of-Interest, כדי לאפשר למכשיר סורק לבצע סנכרון למקור שידור ציבורי. לעומת זאת, צריך להגדיר אותו ל-0x00 זמן קצר אחרי סיום השידור.

שימוש בהקשר של סטרימינג אודיו

הצגת הקשר באופן מפורש עוזרת למסגרת Android ולמכשירים המקבלים לתעדף את הזרמים הנכנסים. לדוגמה, במערכת כריזה (PA) אפשר להגדיר את סוג ההקשר של אודיו בסטרימינג כהדרכה כדי לאפשר להודעות להפריע בצורה חלקה להפעלת מדיה מקומית במכשיר של המשתמש, ולחדש את ההפעלה בצורה חלקה לאחר מכן.

קובצי עזר

‫[1] Bluetooth Assigned Numbers, https://www.bluetooth.com/specifications/assigned-numbers/
‫[2] Basic Audio Profile, https://www.bluetooth.com/specifications/specs/basic-audio-profile-1-0-3/
‫[3] Public Broadcast Profile, https://www.bluetooth.com/specifications/specs/public-broadcast-profile-1-0-2/