بلوٹوتھ ایل ای آڈیو ہینڈ بک سے اقتباس: "میرا فون ٹن کین کی طرح کیوں لگتا ہے؟” AOSP کے نفاذ پر

2000 کی دہائی کے اوائل سے، بلوٹوتھ وائرلیس آڈیو سننے کا غالب طریقہ رہا ہے، جو پہلے مونو ہیڈ سیٹس سے لے کر آج کے واقعی وائرلیس ایئربڈز تک ہر چیز کو طاقت دیتا ہے۔

لیکن بنیادی ٹیکنالوجی نے جس طرح سے ہم اسے استعمال کرتے ہیں اس کے ساتھ رفتار برقرار نہیں رکھی ہے۔ صحیح معنوں میں وائرلیس ایئربڈز، سماعت کے آلات جو سارا دن چلتے ہیں، آڈیو تجربات کا اشتراک کرتے ہیں- جب اصل بلوٹوتھ آڈیو اسٹیک ڈیزائن کیا گیا تھا تو ان میں سے کسی کی بھی توقع نہیں تھی۔

بلوٹوتھ SIG کے ذریعے متعارف کرایا گیا اور 2022 میں حتمی شکل دی گئی، LE آڈیو ایک مکمل طور پر دوبارہ ڈیزائن کیا گیا ہے جو بلوٹوتھ لو انرجی پر تعمیر کردہ بالکل نئے فن تعمیر کے ساتھ کلاسک بلوٹوتھ آڈیو اسٹیک کی جگہ لے لیتا ہے۔ ایک نیا کوڈیک (LC3)، ایک نیا ٹرانسپورٹ پرائمیٹو (آئیسوکرونس چینلز)، مربوط آڈیو سٹریمنگ کے لیے ایک نیا پروفائل، اور اوراکاسٹ نامی ایک بالکل نئی نشریاتی خصوصیت متعارف کرائی گئی ہے۔

یہ تبدیلیاں آڈیو کوالٹی، بجلی کی کھپت، ملٹی ڈیوائس اسٹریمنگ، اور ایکسیسبیلٹی سے متعلق دیرینہ حدود کو دور کرتی ہیں۔

یہ ہینڈ بک LE آڈیو میں ایک جامع تکنیکی گہرا غوطہ ہے۔ ہم اس کا احاطہ کریں گے کہ یہ کیا ہے، یہ کیوں موجود ہے، یہ اسٹیک کی تمام پرتوں پر کیسے کام کرتا ہے، اسے Android (AOSP) میں کیسے لاگو کیا جاتا ہے، اور مزید بہت کچھ۔ ہم تاریخ اور حوصلہ افزائی کے ساتھ شروع کریں گے، بنیادی تصورات کی بدیہی تفہیم پیدا کریں گے، اور پھر فن تعمیر اور کوڈ کی گہرائی میں غوطہ لگائیں گے۔

یہاں آپ کیا سیکھیں گے:

• کلاسک بلوٹوتھ آڈیو اپنی حدوں تک کیوں پہنچ جاتا ہے، ریلے کے مسائل، دو پروفائلز کو تقسیم کرنا، پاور کی رکاوٹیں، براڈکاسٹ کی کمی یا ہیئرنگ ایڈ سپورٹ

• LC3 کوڈیک کیسے کام کرتا ہے اور یہ SBC کے نصف بٹریٹ پر بہتر آڈیو کیوں فراہم کرتا ہے۔

• Isochronous چینلز ایک نیا ٹرانسپورٹ پرائمیٹو ہے جو unicast (CIS) اور براڈکاسٹ (BIS) دونوں فارمیٹس میں آڈیو کے لیے SCO اور ACL کی جگہ لے لیتا ہے۔

• BAP اور PACS جیسی بنیادی خدمات سے لے کر TMAP اور HAP جیسے کیس پروفائلز کو استعمال کرنے کے لیے LE آڈیو پروفائل اسٹیک کی ساخت کیسے بنائی جاتی ہے۔

• ملٹی اسٹریم آڈیو ہر ایئربڈ کے لیے پرائمری سنک اسٹریمز کے ساتھ ایئربڈ ریلے ہیک کو کیسے ختم کرتا ہے

• اوراکاسٹ کیا سپورٹ کرتا ہے: ایک سے کئی براڈکاسٹ آڈیو اور انفراسٹرکچر جو اسے سپورٹ کرتا ہے

• اینڈرائیڈ (AOSP) میں یہ سب کیسے لاگو کیا جاتا ہے، بنیادی C++ اسٹیک کے ذریعے فریم ورک API سے بلوٹوتھ کنٹرولر تک فن تعمیر پر ایک مکمل نظر، بشمول ریاستی مشینیں، کوڈیک گفت و شنید، اور ڈیٹا فلو۔

چاہے آپ بلوٹوتھ انجینئر ہوں، ایک ایمبیڈڈ ڈویلپر، ایک اینڈرائیڈ پلیٹ فارم انجینئر، یا کوئی اس بارے میں جاننے والا ہو کہ ڈیوائسز حقیقت میں کیسے کام کرتی ہیں، اس گائیڈ کا مقصد جدید وائرلیس سسٹمز کے سب سے پیچیدہ حصوں میں سے ایک کو سمجھنا آسان بنانا ہے۔

اگر آپ نے کبھی سوچا ہے کہ آپ کے ایئربڈز میوزک پلے بیک کے لیے کیوں بہت اچھے لگتے ہیں لیکن کالز کے لیے بہترین کیوں نہیں، کیوں ایک ایئربڈ ہمیشہ پہلے مر جاتا ہے، یا آپ اپنے آس پاس کے لوگوں کے ساتھ آڈیو کا اشتراک آسانی سے کیوں نہیں کر سکتے ہیں، پڑھیں۔ تمام جوابات یہاں ہیں۔

انڈیکس

1. ونس اپون اے ٹائم ان بلوٹوتھ لینڈ

2. کلاسک بلوٹوتھ آڈیو کے ساتھ مسائل

3. LE آڈیو سے ملو: ہیرو کی ہمیں ضرورت ہے۔

4. LC3 کوڈیک: بہتر آواز، کم طاقت، زیادہ جادو

5. آئسوکرونس چینلز: نیا پلمبنگ

6. ایل ای آڈیو پروفائل اسٹیک: بہت سے چشموں کا کیک

7. ملٹی اسٹریم آڈیو: مزید بائیں ایئربڈ ریلے نہیں۔

8. اوراکاسٹ: عوام کے لیے آڈیو نشر کریں۔

9. Android/AOSP پر LE آڈیو: نفاذ

10. اے او ایس پی آرکیٹیکچر: ایپ سے اینٹینا تک

11. سرور سائیڈ (ذریعہ) کا نفاذ

12. کلائنٹ سائیڈ (سنک) کا نفاذ

13. ایک ریاستی مشین جو سب کچھ چلاتی ہے۔

14. خلاصہ: LE آڈیو پیکٹ کی زندگی میں ایک دن

15. ختم

1. ونس اپون اے ٹائم ان بلوٹوتھ لینڈ

یہ اب 2003 ہے۔ پلٹائیں فون واقعی بہت اچھے ہیں۔ پہلے بلوٹوتھ ہیڈسیٹ مارکیٹ میں آئے، اور اچانک آپ کال کرتے وقت سائبرگ کی طرح گھوم سکتے تھے۔

مونو، فون کوالٹی آڈیو؟ اس چھوٹی سی چیز کا شکریہ، HFP (ہینڈز فری پروفائل) سی وی ایس ڈی کوڈیک ایک زبردست 64kbps ہے۔ ایسا لگتا ہے کہ کال کرنے والا آبدوز کے اندر سے بات کر رہا ہے، لیکن تاریں نہیں ہیں!

چند سال فاسٹ فارورڈ۔ ہمیں مل گیا A2DP (ایڈوانسڈ آڈیو ڈسٹری بیوشن پروفائل) میوزک اسٹریمنگ کے لیے ایس بی سی (سب بینڈ کوڈیک)، ہونڈا سِوک کے برابر ایک آڈیو کوڈیک۔ یہ چمکدار یا خوفناک ہونے کے بغیر کام کرتا ہے۔ A2DP نے ہمیں سٹیریو میوزک اسٹریمنگ دی اور زندگی اچھی تھی۔

تھوڑی دیر کے لیے۔

بلوٹوتھ اسپیشل انٹرسٹ گروپ (SIG)، ہزاروں کمپنیوں کا ایک کنسورشیم جو بلوٹوتھ کا انتظام کرتا ہے، نے کلاسک بلوٹوتھ آڈیو اسٹیک پر اعادہ کرنا جاری رکھا ہے۔ ہمارے پاس بہتر کوڈیکس ہیں جیسے aptX, اے اے سیاور ایل ڈی اے سی. لیکن مسئلہ یہ ہے کہ وہ سب ایک ہی قدیم پلمبنگ پر بنائے گئے ہیں۔ یہ آپ کے باورچی خانے کی تزئین و آرائش کی طرح ہے جب آپ کے گھر کی بنیاد آہستہ آہستہ ٹوٹ رہی ہے۔

بلوٹوتھ آڈیو اسٹیک اس پر بنایا گیا ہے: BR/EDR (مقامی رفتار/بڑھا ہوا ڈیٹا ریٹ)، ایک "کلاسک بلوٹوتھ” ریڈیو۔ یہ وہی وائرلیس ٹیکنالوجی ہے جو 2000 کی دہائی کے اوائل سے ہے، جب آپ کے فون سے ایک ہی ہیڈسیٹ پر آڈیو سٹریم کرنا جدت کا عروج تھا۔ کسی نے واقعی وائرلیس ایئربڈز، آپ کے فون سے براہ راست نشر ہونے والی سماعت کے آلات، یا ہوائی اڈے کے ٹرمینل میں آڈیو نشر کرنے کا تصور بھی نہیں کیا تھا۔

2010 کی دہائی کے آخر تک، بلوٹوتھ آڈیو پرانا ہو چکا تھا۔ بری طرح

2. کلاسک بلوٹوتھ آڈیو کے ساتھ مسائل

چونکہ یہ تعلیمی ہے، آئیے کلاسک بلوٹوتھ آڈیو کے ساتھ مسائل کو توڑتے ہیں۔

مسئلہ نمبر 1: دوہری شخصیت کی خرابی

کلاسک بلوٹوتھ کی ایک الگ شخصیت تھی۔ موسیقی سننا چاہتے ہیں؟ اچھے معیار کے ساتھ SBC/AAC کے ساتھ A2DP استعمال کریں۔ ایک کال کرنا چاہتے ہیں؟ HFP پر سوئچ کریں، جو نمایاں طور پر کم معیار کا بالکل مختلف کوڈیک (CVSD یا mSBC) استعمال کرتا ہے۔

کیا آپ نے کبھی دیکھا ہے کہ Spotify چلاتے وقت آپ کے وائرلیس ایئربڈز کی آواز کتنی حیرت انگیز ہوتی ہے، لیکن جب آپ زوم کال شروع کرتے ہیں تو ایسا لگتا ہے جیسے آپ پیپر ٹاول ٹیوب کے ذریعے بول رہے ہوں؟ یہ A2DP سے HFP میں منتقلی ہے۔ مختلف پروفائلز، مختلف کوڈیکس، مختلف آڈیو راستے۔ سوئچز خوبصورت نہیں ہیں اور اکثر ان میں قابل سماعت خرابیاں ہوتی ہیں۔

اوپر دیا گیا خاکہ A2DP (اعلی معیار کے SBC/AAC کا استعمال کرتے ہوئے میوزک سٹریمنگ) سے HFP (کم کوالٹی CVSD/mSBC کا استعمال کرتے ہوئے وائس کالنگ) پر سوئچ کرتے وقت آڈیو کوالٹی میں کمی کو ظاہر کرتا ہے۔ سوئچ قابل سماعت نمونے کا سبب بنتا ہے اور آڈیو کی مخلصی کو نمایاں طور پر کم کرتا ہے۔

مسئلہ نمبر 2: ریلے کا مسئلہ (True Wireless Earbuds)

اگر آپ واقعی وائرلیس ایئربڈز (وائرلیس بائیں اور دائیں ایئربڈز) استعمال کرتے ہیں، تو کلاسک بلوٹوتھ کا تھوڑا سا راز ہے: A2DP ایک وقت میں صرف ایک ڈیوائس پر سٹریم کر سکتا ہے۔

تو اصل میں آپ کے زبردست ایئربڈس کا کیا ہوتا ہے؟

1. آپ کا فون درج ذیل آلات پر سٹیریو آڈیو سٹریم بھیجتا ہے: بنیادی earbuds (عام طور پر دائیں طرف)

2. بنیادی ایئربڈز بائیں اور دائیں دونوں چینلز حاصل کرتے ہیں۔

3. پھر ریلے الگ الگ بلوٹوتھ لنک کے ذریعے مختلف چینلز کو سیکنڈری ایئربڈز سے جوڑیں۔

اس ریلے فن تعمیر کے کئی اہم نتائج ہیں۔ سب سے پہلے، یہ معیاری ایئربڈز کی بیٹری کی کھپت کو دوگنا کرتا ہے۔ یہ ثانوی ایئربڈز کے لیے اسٹینڈ بائی ٹائم کو بھی بڑھاتا ہے۔

بائیں اور دائیں چینلز کے درمیان ممکنہ مطابقت پذیری کے مسائل بھی ہیں۔ اگر بنیادی ایئربڈ کی بیٹری کم ہے یا کنکشن منقطع ہے، تو دونوں ایئربڈز خاموش ہو جائیں گے۔

مسئلہ نمبر 3: بجلی کی کھپت

BR/EDR کو ایک ایسے دور میں ڈیزائن کیا گیا تھا جب "کم پاور” کا مطلب تھا "AA بیٹریوں پر چلتا ہے۔” کلاسیکی بلوٹوتھ پر آڈیو سٹریمنگ نسبتاً طاقتور ہے۔ وائرلیس کو ایک مستقل، اعلی بینڈوتھ کنکشن برقرار رکھنا چاہیے۔ سماعت کے آلات جیسے آلات کے لیے جنہیں سارا دن چھوٹی بیٹریوں پر چلانے کی ضرورت ہوتی ہے، یہ ایک بڑا مسئلہ تھا۔

مسئلہ #4: صرف ایک سے ایک

کلاسیکی بلوٹوتھ آڈیو بنیادی طور پر ہے۔ پوائنٹ ٹو پوائنٹ. ایک ذریعہ، ایک سنک (یا بہترین طور پر ایک بہت ہی ہیکی "ڈبل آڈیو” نفاذ جہاں فون دو الگ الگ A2DP کنکشن برقرار رکھتا ہے)۔ ہر سننے والے سے انفرادی تعلق قائم کیے بغیر ایک ہی وقت میں متعدد سامعین کو آڈیو نشر کرنے کا کوئی طریقہ نہیں ہے۔

تصور کریں کہ آپ ہوائی اڈے کے گیٹ پر ہیں اور آپ بورڈنگ کے اعلان کو ہر کسی کے ائرفون پر چلانا چاہتے ہیں۔ کلاسک بلوٹوتھ کا تقاضہ ہے کہ آپ ہر کسی کے آلے کے ساتھ انفرادی طور پر جوڑا بنائیں۔ گیٹ B47 پر گڈ لک۔

مسئلہ #5: سماعت کے آلات کے لیے کوئی معیار نہیں ہے۔

LE آڈیو سے پہلے، سماعت کے آلات کے لیے کوئی سرکاری بلوٹوتھ معیار نہیں تھا۔ ایپل نے اپنا ملکیتی Made for iPhone (MFi) ہیئرنگ ایڈ پروٹوکول بنایا ہے۔ گوگل نے ASHA (اسٹریمنگ آڈیو فار ہیئرنگ ایڈز) کو اینڈرائیڈ کے لیے ایک نیم ملکیتی BLE پر مبنی حل کے طور پر بنایا۔ نہ ہی کوئی سرکاری بلوٹوتھ معیار ہے، اور نہ ہی انٹرآپریبلٹی ہے… آئیے اسے "امید” کہتے ہیں۔

LE آڈیو ان پٹ: ہیرو جس کی ہمیں ضرورت ہے۔

بلوٹوتھ SIG کی نقاب کشائی CES میں جنوری 2020 میں ہوئی تھی۔ آڈیویہ بلوٹوتھ آڈیو کا مکمل دوبارہ تصور ہے، جو کلاسک BR/EDR کی بجائے BLE (Bluetooth Low Energy) پر بنایا گیا ہے۔

بنیادی نقل و حمل کی خصوصیات (isochronous چینلز، EATT، LE پاور کنٹرول) بلوٹوتھ کور اسپیسیفیکیشن v5.2 میں 2019 کے آخر میں / 2020 کے اوائل میں جاری کی گئیں۔ تاہم، LE آڈیو پروفائلز اور خدمات کا مکمل سوٹ 12 جولائی 2022 تک مکمل نہیں ہو گا، جب بلوٹوتھ SIG نے باضابطہ طور پر اعلان کیا ہے کہ تمام مخصوص آڈیو کو اپنا لیا گیا ہے۔

اس کوشش میں 25 سے زیادہ ورکنگ گروپس اور سینکڑوں کمپنیوں کے ہزاروں انجینئرز شامل تھے اور ابتدائی تصور سے تکمیل تک تقریباً سات سال لگے۔ یہ کوئی معمولی اپ ڈیٹ نہیں تھا۔ یہ ایک مکمل ری ڈیزائن تھا۔

LE آڈیو درج ذیل خصوصیات پیش کرتا ہے:

خصوصیت	کلاسک آڈیو	آڈیو
ریڈیو	BR/EDR (کلاسیکی)	BLE (کم توانائی)
مطلوبہ کوڈیک	ایس بی سی	ایل سی 3
اسی بٹ ریٹ پر آڈیو کوالٹی	اچھا	بہتر (LC3 جیت)
بجلی کی کھپت	اعلی	کم
کثیر سلسلہ	نہیں (ریلے ہیکنگ)	ہاں (پہلے سے طے شدہ)
آڈیو نشر کریں	نہیں	ہاں (Auracast)
سماعت امداد کی حمایت	کوئی معیاری نہیں (MFi/ASHA)	ہاں (HAP)
دو طرفہ آڈیو	علیحدہ پروفائلز (A2DP + HFP)	انضمام (BAP)
آڈیو شیئرنگ	بہت محدود	اندرونی سجاوٹ

اس طرح سوچو۔ کلاسک بلوٹوتھ آڈیو لینڈ لائن فون سسٹم کی طرح ہے۔ یہ مستحکم اور اچھی طرح سے سمجھا جاتا ہے، لیکن بنیادی طور پر محدود ہے۔

LE آڈیو VoIP اور سٹریمنگ میں منتقلی کی طرح ہے۔ مقصد ایک ہی ہے (A سے B تک آڈیو حاصل کریں)، لیکن یہ ایک مکمل طور پر نیا انفراسٹرکچر ہے جو ان خصوصیات کو کھولتا ہے جن کو میراثی نظام کبھی سپورٹ نہیں کر سکتے۔

4. LC3 کوڈیک: بہتر آواز، کم طاقت، زیادہ جادو

LE آڈیو کے مرکز میں ایک نیا ضروری کوڈیک ہے۔ ایل سی 3: کم پیچیدگی مواصلاتی کوڈیک۔ اگر SBC ہونڈا سوِک ہے، تو LC3 ایک Tesla ماڈل 3 ہے۔ زیادہ موثر، زیادہ قابل اور جدید دور کے لیے زمین سے ڈیزائن کیا گیا ہے۔

کوڈیک کیا ہے؟

ابتدائیوں کے لیے: کوڈیک (گہاکہ-دسمبرoder) ایک الگورتھم ہے جو آڈیو کو کمپریس کرتا ہے اور پھر اسے دوسرے سرے پر ڈیکمپریس کرتا ہے تاکہ اسے محدود بینڈوتھ وائرلیس لنک پر منتقل کیا جا سکے۔ کوڈیک جتنا بہتر ہوگا، ایک مخصوص بٹریٹ پر آڈیو اتنا ہی بہتر ہوگا اور کمپیوٹنگ میں اس کی بیٹری اتنی ہی کم استعمال ہوگی۔

LC3 تکنیکی وضاحتیں

LC3 Fraunhofer IIS (وہ لوگ جو آپ کو MP3 اور AAC لائے تھے، اس لیے وہ آڈیو کوڈنگ کے بارے میں بہت کچھ جانتے ہیں) اور Ericsson نے تیار کیا تھا۔

کلیدی وضاحتیں شامل ہیں:

• نمونے لینے کی شرح: 8, 16, 24, 32, 44.1, 48kHz

• تھوڑا سا گہرائی: 16، 24 یا 32 بٹ

• فریم کی مدت: 7.5ms اور 10ms

• بٹ ریٹ کی حد: 16~320kbps فی چینل

• الگورتھم لیٹنسی: 7.5ms (7.5ms فریم کے لیے) یا 10ms (10ms فریم کے لیے)

• چینل: مونو یا سٹیریو

LC3 SBC سے بہتر کیوں ہے۔

سب سے بڑی سرخی یہ ہے کہ LC3 SBC کے تقریباً نصف بٹریٹ پر ایک ہی یا بہتر آڈیو کوالٹی فراہم کرتا ہے۔

Fraunhofer کی طرف سے کئے گئے سننے کے ٹیسٹ میں، شرکاء نے LC3 کے 160 kbps کو SBC کے 345 kbps کے برابر یا اس سے بہتر قرار دیا۔ یہ کوئی معمولی بہتری نہیں ہے، یہ کارکردگی میں تقریباً 2 گنا اضافہ ہے۔

اوپر والا بار چارٹ مختلف بٹ ریٹ پر LC3 اور SBC کی سبجیکٹیو آڈیو کوالٹی ریٹنگز کا موازنہ کرتا ہے۔ 160 kbps پر LC3 کو 345 kbps پر SBC کے برابر یا بہتر درجہ دیا گیا ہے، جو تقریباً 2x کارکردگی میں بہتری دکھا رہا ہے۔

یہ کارکردگی کے فوائد براہ راست درج ذیل میں سے ایک (یا دونوں کا مجموعہ) میں ترجمہ کرتے ہیں:

1. اسی طاقت کے ساتھ بہتر آڈیو کوالٹیمعیار کے لیے مزید بٹس استعمال کریں اور فضلہ کم کریں۔

2. کم پاور پر ایک ہی آڈیو کوالٹیجب آپ اسے چارج کریں گے تو آپ کا آلہ زیادہ دیر تک چلے گا۔

LC3 اصل میں کیسے کام کرتا ہے (آسان ورژن)

ایل سی 3 ترمیم شدہ ڈسکریٹ کوزائن ٹرانسفارم (MDCT)ایک ریاضیاتی تکنیک ہے جو آڈیو کو ٹائم ڈومین (waveform) سے فریکوئنسی ڈومین میں تبدیل کرتی ہے (جہاں تعدد موجود ہے)۔ یہ AAC اور دیگر جدید کوڈیکس کی فعالیت سے ملتا جلتا ہے، لیکن LC3 کی تبدیلی کم کمپیوٹیشنل پیچیدگی کے لیے موزوں ہے۔

آسان انکوڈنگ پائپ لائن مندرجہ ذیل ہے:

یہ LC3 انکوڈنگ پائپ لائن کا فلو ڈایاگرام ہے۔ PCM آڈیو ان پٹ کو ٹائم ڈومین سے فریکوئنسی ڈومین میں MDCT (موڈیفائیڈ ڈسکریٹ کوزائن ٹرانسفارم) کے ذریعے تبدیل کیا جاتا ہے۔ اس کے بعد، سپیکٹرل شور کی شکل سازی ایک سائیکوکوسٹک ماڈل کو قابل سماعت فریکوئنسی ڈومین میں کوانٹائزیشن شور کو چھپانے کے لیے لاگو کرتی ہے، اور پھر کوانٹائزیشن اور اینٹروپی کوڈنگ کے ذریعے ایک کمپریسڈ LC3 بٹ اسٹریم تیار کرتی ہے۔

کلیدی بصیرت ہے سپیکٹرل شور کی تشکیل: LC3 تعدد والے خطوں میں گرنے کے لیے کوانٹائزیشن شور (کمپریشن کی وجہ سے ہونے والے نمونے) کی شکل دینے کے لیے ایک سائیکوکوسٹک ماڈل (ایک ماڈل کا استعمال کرتا ہے کہ انسان آواز کو کیسے سمجھتا ہے)۔ آپ کے کان لفظی طور پر تحریف کو نہیں سن سکتے۔ ہوشیار، ٹھیک ہے؟

LC3 بمقابلہ LC3plus

آپ بھی سن سکتے ہیں۔ ایل سی 3 پلسیہ ایک بہتر ورژن ہے جو شامل کرتا ہے:

• الٹرا وائیڈ بینڈ اور فل بینڈوتھ موڈز (48kHz آڈیو بینڈوتھ تک)

• انتہائی کم لیٹنسی ایپلی کیشنز کے لیے اضافی فریم سائز (2.5ms، 5ms)

• بہت کم بٹ ریٹ پر اعلیٰ معیار

LC3plus بیس LE آڈیو تفصیلات کا حصہ نہیں ہے، لیکن کچھ نفاذ میں استعمال ہوتا ہے (جیسے وائرلیس فونز میں DECT NR+)۔

5. Isochronous چینلز: نئی پلمبنگ

یہ وہ جگہ ہے جہاں یہ آرکیٹیکچرل طور پر دلچسپ ہو جاتا ہے۔ کلاسک بلوٹوتھ آڈیو استعمال کریں۔ ایس سی او (ہم وقت ساز کنکشن اورینٹڈ) وائس اور لنک L2CAP پر ACL یہ A2DP سٹریمنگ کا لنک ہے (کوئی غیر مطابقت پذیر کنکشن نہیں)۔ یہ ٹھیک تھا، لیکن یہ باغ کی نلی کو دوبارہ بنانے کی طرح تھا، فعال لیکن آڈیو کے لیے موزوں نہیں تھا۔

ایل ای آڈیو نے لنک لیئر پر ٹرانسپورٹ کا ایک نیا طریقہ کار متعارف کرایا ہے۔ isochronous چینل. یہ ایک پائپ ہے جو خاص طور پر وقت کے حساس ڈیٹا جیسے آڈیو کے لیے بنایا گیا ہے۔

"isochrony” کا کیا مطلب ہے؟

"isochronism” (یونانی: iso = وہی، کرونوس = وقت) کا مطلب ہے "باقاعدہ وقت کے وقفوں پر ہونے والا۔” Isochronous چینلز اس بات کو یقینی بناتے ہیں کہ ڈیٹا بالکل متوقع، باقاعدہ بہاؤ میں آتا ہے جس کی آڈیو کو ضرورت ہوتی ہے۔

اس کے بارے میں اس طرح سوچیں:

• متضاد (ACL): "یہ کچھ ڈیٹا ہے۔ یہ وہاں پہنچ جانے پر پہنچ جائے گا۔” (فائل کی منتقلی کے لیے اچھا، لیکن آڈیو کے لیے اچھا نہیں)

• ہم وقت ساز (SCO): "یہاں ڈیٹا وقت پر پہنچنا چاہیے۔ اگر ایسا نہیں ہوتا ہے تو یہ شرم کی بات ہے۔” (پرانا صوتی لنک، دوبارہ ٹرانسمیشن نہیں)

• isochronism: "یہاں ڈیٹا کو وقت پر پہنچنے کی ضرورت ہے۔ ہم اسے سمارٹ ری ٹرانسمیشن کے ذریعے انجام دینے کی پوری کوشش کریں گے۔” (دونوں جہانوں میں بہترین)

اوپر والا چارٹ بلوٹوتھ ٹرانسمیشن کی تین اقسام کا موازنہ کرتا ہے۔ غیر مطابقت پذیر (ACL) ٹائمنگ گارنٹی کے بغیر ڈیٹا منتقل کرتا ہے، ہم وقت ساز (SCO) بغیر کسی مقررہ شیڈول پر ڈیٹا منتقل کرتا ہے، اور Isochronous ACL کی وشوسنییتا کو SCO کی ٹائمنگ گارنٹیوں کے ساتھ جوڑتا ہے تاکہ سمارٹ ری ٹرانسمیشن کے ساتھ ڈیٹا کو باقاعدہ شیڈول پر منتقل کیا جا سکے۔

دو ذائقے: CIS اور BIS

Isochronous چینلز دو شکلوں میں آتے ہیں، اور یہیں سے جادو ہوتا ہے۔

CIS – متصل آئسوکرونس اسٹریمز

سی آئی ایس پوائنٹ ٹو پوائنٹ آڈیو (یونیکاسٹ)۔ یہ وہی ہے جسے آپ کا فون آپ کے ایئربڈز پر موسیقی چلانے کے لیے استعمال کرتا ہے۔

aboe ایک کنیکٹڈ آئسوکرونس اسٹریم (CIS) سیٹ اپ کا خاکہ ہے۔ فون (یونیکاسٹ کلائنٹ) سنگل کنیکٹڈ آئسوکرونس گروپ (سی آئی جی) کے اندر دو مطابقت پذیر CIS اسٹریمز بھیجتا ہے، ایک بائیں ایئربڈ پر اور ایک دائیں ایئربڈ پر۔ تیر دو طرفہ آڈیو بہاؤ دکھاتے ہیں، جس میں موسیقی ائرفون پر جاتی ہے اور مائیکروفون آڈیو فون پر واپس آتی ہے۔

CIS کی اہم خصوصیات:

• دو طرفہ: آڈیو بیک وقت دونوں سمتوں میں بہہ سکتا ہے (یونیکاسٹ سے ایئربڈز اور مائکروفون آڈیو بیک)۔

• تصدیق شدہ: وصول کنندہ ایک رسید بھیج کر کھوئے ہوئے پیکٹ کو دوبارہ منتقل کر سکتا ہے۔

• سی آئی جی کے ذریعہ گروپ کیا گیا۔: متعدد سی آئی ایس اسٹریمز کو ایک گروپ میں گروپ کیا گیا ہے۔ سی آئی جی (منسلک isochronous گروپس)، یقینی بنائیں کہ وہ مطابقت پذیر ہیں۔

آخری نکتہ اہم ہے۔ CIG اس بات کو یقینی بناتا ہے کہ بائیں اور دائیں ایئربڈس کو سخت مطابقت پذیری میں آڈیو پیکٹ موصول ہوں، لہذا آپ کے پاس اب "بائیں کان دائیں کان سے 50ms آگے ہے” کا مسئلہ نہیں ہے۔

BIS — براڈکاسٹ آئسوکرونس سٹریم

بی آئی ایس ایک سے کئی آڈیو (براڈکاسٹ)۔ یہ اوراکاسٹ کی بنیاد ہے۔

اوپر براڈکاسٹ آئسوکرونس اسٹریم (BIS) سیٹ اپ کا خاکہ ہے۔ ایک واحد براڈکاسٹ ذریعہ آڈیو کو براڈکاسٹ آئسوکرونس گروپ (BIG) پر منتقل کرتا ہے جس میں متعدد BIS اسٹریمز ہوتے ہیں۔ ایک سے زیادہ ریسیورز (براڈکاسٹ سنکس) آزادانہ طور پر ایک ہی آڈیو کو کسی ماخذ سے منسلک کیے بغیر وصول کرتے ہیں، جیسا کہ FM ریڈیو۔

BIS کی اہم خصوصیات:

• ایک راستہ: یہ صرف ایک طرفہ معنی رکھتا ہے (سننے والے کو ذریعہ دینا)۔ آپ کو جواب دینے کے لئے ایک ملین لوگ حاصل نہیں کر سکتے ہیں.

• تصدیق نہیں کی: سامع کی طرف سے کوئی جواب نہیں (ذریعہ یہ بھی نہیں جانتا کہ کون سن رہا ہے)

• BIG کے طور پر درجہ بندی: متعدد BIS سلسلے کو ایک میں ملایا جا سکتا ہے۔ بڑا (براڈکاسٹ isochronous گروپ)

• قابل توسیع: سننے والوں پر کوئی پابندی نہیں، حقیقی ریڈیو نشریات

آئی ایس او ڈیٹا پاتھ

اندرونی طور پر، isochronous ڈیٹا کنٹرولر کے ذریعے ایک مخصوص راستے کی پیروی کرتا ہے۔

اوپر بلوٹوتھ کنٹرولر کے ذریعے آئیسوکرونس ڈیٹا پاتھ کا خاکہ ہے۔ میزبان سے آڈیو فریم HCI سے گزرتے ہیں اور پھر ISO Adaptation Layer (ISO-AL) سے ہوتے ہیں، جو اوور دی ایئر ٹرانسمیشن کے لیے لنک لیئر تک پہنچنے سے پہلے سیگمنٹیشن، ٹائم سٹیمپ، اور فلش ٹائم آؤٹ مینجمنٹ کو سنبھالتا ہے۔

بنیادی اختراع ہے۔ ISO-AL (Isochronous Adaptation Layer)، جو HCI اور لنک پرت کے درمیان واقع ہے۔ یہ سنبھالتا ہے:

• تقسیم: آڈیو فریم کو لنک پرت کے سائز کے ٹکڑوں میں تقسیم کریں۔

• ٹائم سٹیمپ: ہر آڈیو فریم میں ٹائم اسٹیمپ ہوتا ہے لہذا وصول کنندہ کو بخوبی معلوم ہوتا ہے کہ اسے کب چلانا ہے۔

• فلش ٹائم آؤٹ: اگر ایک فریم وقت پر نہیں پہنچایا جا سکتا ہے، تو اسے فلش کر دیا جاتا ہے (کسی فریم کو دیر سے چلانے سے بہتر ہے کہ اسے چھوڑ دیں)۔

6. LE آڈیو پروفائل اسٹیک: مختلف تفصیلات

اگر آپ نے کبھی LE آڈیو چشموں کی فہرست کو دیکھا ہے اور محسوس کیا ہے کہ آپ کی آنکھیں کھلی ہوئی ہیں، تو آپ اکیلے نہیں ہیں۔ ان میں سے بہت سارے ہیں۔ تاہم، یہ ایک منطقی درجہ بندی میں منظم ہے، لہذا ایک بار جب آپ ساخت کو سمجھ لیتے ہیں، تو یہ سب سمجھ میں آتا ہے۔

بصری: پروفائل اسٹیک

ذیل میں LE آڈیو پروفائل اسٹیک کا تین پرتوں کا خاکہ ہے۔

ٹائر 1 (بنیادی) میں BAP، VCP، MCP، CCP، MICP، CSIP، اور BASS شامل ہیں۔ ٹائر 2 (گروپنگ ٹائر) میں CAPs شامل ہیں جو ٹائر 1 پروفائلز کو مربوط کرتے ہیں۔ ٹائر 3 (Use Case Profile) میں ٹیلی فونی اور میڈیا کے لیے TMAP، سماعت کے آلات کے لیے HAP، اور عوامی نشریات کے لیے PBP شامل ہیں۔ ہر پرت اس کے نیچے کی پرت پر بنتی ہے۔

اسے تین درجے والا ویڈنگ کیک سمجھیں۔

ٹائر 1: فاؤنڈیشن (بنیادی خدمات اور پروفائلز)

یہ وہ بلڈنگ بلاکس ہیں جہاں سے باقی سب کچھ بنایا گیا ہے۔

BAP – بنیادی آڈیو پروفائل

بڑا کہونا۔ BAP LE آڈیو اسٹریمز کو دریافت کرنے، ترتیب دینے اور ترتیب دینے کے لیے بنیادی طریقہ کار کی وضاحت کرتا ہے۔ یہ دو کرداروں کی وضاحت کرتا ہے:

BAP کئی GATT خدمات پر انحصار کرتا ہے۔

• پی اے سی ایس (شائع شدہ آڈیو فیچرز سروس): "یہ آڈیو فارمیٹس ہیں جن کی میں حمایت کرتا ہوں۔”

• ASCS (آڈیو اسٹریم کنٹرول سروس): "آڈیو اسٹریمز کو ترتیب دیں اور ان کا نظم کریں”

VCP – والیوم کنٹرول پروفائل

ریموٹ والیوم کنٹرول کو ہینڈل کرتا ہے۔ آپ کا فون آپ کے ایئربڈز پر والیوم کو کنٹرول کر سکتا ہے (اور اس کے برعکس) استعمال کر کے: VCS (حجم کنٹرول سروس)۔

MCP – میڈیا کنٹرول پروفائل

آپ میڈیا پلے بیک کو دور سے کنٹرول کر سکتے ہیں۔ توقف، پلے، اسکپ وغیرہ کے ذریعے۔ ایم سی ایس (میڈیا کنٹرول سروس)۔ LE آڈیو کے لیے AVRCP جیسا ہی۔

CCP – کال کنٹرول پروفائل

فون کال کی حیثیت کا نظم کریں۔ جواب دینے، مسترد کرنے، یا کالوں کو ہولڈ پر رکھ کر۔ ٹی بی ایس (ٹیلی فون فارورڈنگ سروس)۔ یہ HFP کی کال کنٹرول فعالیت کو بدل دیتا ہے۔

MICP – مائیکروفون کنٹرول پروفائل

آلے کے مائیکروفون کو ریموٹ خاموش کرنے/غیر خاموش کرنے کو ہینڈل کرتا ہے۔ سادہ مگر ضروری۔ کیا آپ کبھی کال پر رہے ہیں اور خاموش کرنے کا طریقہ نہیں جان سکے؟ MICP اسے معیاری بناتا ہے۔

CSIP – کوآرڈینیشن سیٹ شناختی پروفائل

یہ "یہ دونوں ایئربڈز ایک ساتھ تعلق رکھتے ہیں” پروفائل ہے۔ کہ CSIS (Coordinated Set Identification Service) فون پر کہتا ہے، "ارے، میں بائیں ایئربڈ ہوں، میرے دوست کے پاس دائیں ایئربڈ ہے۔ ہم ایک سیٹ ہیں۔”

CSIP کے بغیر، آپ کا فون ہر ایئربڈ کو مکمل طور پر خودمختار ڈیوائس کے طور پر دیکھے گا۔ CSIP ہموار "مربوط سیٹ” آپریشن کو قابل بناتا ہے۔

BASS – براڈکاسٹ آڈیو سکیننگ سروس

براڈکاسٹ آڈیو ذرائع کی دریافت کو سنبھالتا ہے۔ BASS فعالیت والے آلات قریبی سٹیشنوں کو سکین کر سکتے ہیں اور دوسرے آلات (مثلاً سماعت کے آلات) کو ان سٹیشنوں میں ٹیون کرنے میں مدد کر سکتے ہیں۔

پرت 2: گروپ بندی کی پرت

CAP – کامن آڈیو پروفائل

CAP ٹائر 1 پروفائل کے اوپر بیٹھتا ہے اور اعلی سطحی پروفائلز کے ذریعہ استعمال کردہ عام طریقہ کار فراہم کرتا ہے۔ یہ مندرجہ ذیل کاموں کو سنبھالتا ہے:

• مربوط ڈیوائس سیٹ دریافت (CSIP کا استعمال کرتے ہوئے)

• یونی کاسٹ آڈیو سٹریم کو مربوط سیٹ میں ترتیب دیں (BAP کا استعمال کرتے ہوئے)

• آڈیو سلسلہ نشر کرنا شروع کریں۔

CAP کو ایک "کوآرڈینیٹر” کے طور پر سوچیں جو تمام ٹائر 1 پروفائلز کو ایک ساتھ کام کرنے کے لیے مربوط کرتا ہے۔

پرت 3: کیس پروفائل استعمال کریں۔

یہاں وہ پروفائلز ہیں جو حقیقی صارف کے منظرناموں کا نقشہ بناتے ہیں:

TMAP — ٹیلی فون اور میڈیا آڈیو پروفائل

عام آڈیو استعمال کے معاملات کے لیے ایک "آل ان ون” پروفائل۔ TMAP مندرجہ ذیل کرداروں کی وضاحت کرتا ہے:

• کال ٹرمینل (CT): آپ کال کر سکتے ہیں اور وصول کر سکتے ہیں۔

• یونی کاسٹ میڈیا بھیجنے والا (UMS): آپ میڈیا آڈیو (موبائل فون) بھیج سکتے ہیں۔

• یونی کاسٹ میڈیا ریسیور (UMR): میڈیا آڈیو موصول کیا جا سکتا ہے (ایئربڈز)

• براڈکاسٹ میڈیا بھیجنے والا (BMS): میڈیا آڈیو براڈکاسٹنگ ممکن ہے۔

• براڈکاسٹ میڈیا ریسیور (BMR): براڈکاسٹ میڈیا آڈیو استقبالیہ ممکن ہے۔

اگر آپ ایک عام فون + ایئربڈز کا تجربہ بنا رہے ہیں، تو TMAP آپ کا پروفائل ہے۔

HAP – سماعت تک رسائی کا پروفائل

سماعت ایڈز کے لیے معیاری پروفائل۔ یہ سرکاری بلوٹوتھ معیار کے طور پر ملکیتی MFi اور ASHA سلوشنز کی جگہ لے لیتا ہے۔ HAP مندرجہ ذیل طریقہ کار کی وضاحت کرتا ہے:

• آڈیو کو اپنے سماعت کے آلات پر سٹریم کریں۔

• ہیئرنگ ایڈ پیش سیٹ کو ایڈجسٹ کریں۔

• آپ کی سماعت امداد کے حجم کو ایڈجسٹ کرنا

یہ ایک بہت بڑا سودا ہے۔ پہلی بار، ہیئرنگ ایڈز معیاری پروٹوکول کا استعمال کرتے ہوئے کسی بھی بلوٹوتھ ڈیوائس کے ساتھ مداخلت کر سکتی ہیں۔

PBP – عوامی نشریاتی پروفائل

عوامی نشریات (Auracast) کو ترتیب دینے اور دریافت کرنے کا طریقہ بیان کرتا ہے۔ یہ وہی ہے جو "ایئرپورٹ ٹرمینل سے آڈیو براڈکاسٹ” کے منظر نامے کو ممکن بناتا ہے۔

7. ملٹی اسٹریم آڈیو: مزید بائیں ایئربڈ ریلے نہیں۔

کلاسک بلوٹوتھ کے ساتھ ریلے کا مسئلہ یاد ہے؟ LE آڈیو اسے مکمل طور پر ختم کرتا ہے۔ ملٹی اسٹریم آڈیو.

LE آڈیو سورس ڈیوائس (موبائل فون) کو ہر ایئربڈ پر براہ راست آزاد، مطابقت پذیر آڈیو اسٹریمز بھیجنے کی اجازت دیتا ہے۔

یہ خاکہ کلاسک بلوٹوتھ ریلے فن تعمیر کا موازنہ کرتا ہے (جہاں فون بنیادی ایئربڈ کو سٹیریو بھیجتا ہے، جو بدلے میں ثانوی ایئربڈ کو بھیجتا ہے) LE آڈیو ملٹی اسٹریم فن تعمیر کے ساتھ (جہاں فون CIG کے اندر الگ الگ CIS چینلز پر براہ راست ہر ایئربڈ پر آزاد ہم آہنگی کے سلسلے بھیجتا ہے)۔ LE آڈیو اپروچ متوازن بیٹری کی کھپت اور کم تاخیر فراہم کرتا ہے۔

یہ کیسے کام کرتا ہے۔

1. دونوں ایئربڈز BLE کے ذریعے آپ کے فون سے آزادانہ طور پر جڑ جاتے ہیں۔

2. فون CSIP کو مربوط سیٹ کے طور پر شناخت کرنے کے لیے استعمال کرتا ہے۔

3. فون ہے۔ سی آئی جی (2 متصل آئسوکرونس گروپس) سی آئی ایس سلسلہ (ایک فی ایئربڈ)

4. فون CIS #1 کے لیے بائیں چینل اور CIS #2 کے لیے دائیں چینل بھیجتا ہے۔

5. CIG اس بات کو یقینی بناتا ہے کہ دونوں اسٹریمز ہم آہنگ ہوں اور ایئربڈز ہر چینل کو بالکل ایک ہی وقت میں چلائیں۔

منافع:

• متوازن بیٹری کی کھپت: دونوں ایئربڈز ایک ہی کام کرتے ہیں۔

• کم تاخیر: کوئی ریلے ہاپس کا مطلب کم تاخیر ہے۔

• بہتر وشوسنییتا: اگر ایک ایئربڈ منقطع ہو جائے تو دوسرا ایئربڈ چلتا رہتا ہے۔

• حقیقی سٹیریو: ہر ایئربڈ کا اپنا خود مختار سلسلہ ہوتا ہے، لہذا اسے ڈی کوڈ کرنے یا تقسیم کرنے کی ضرورت نہیں ہے۔

8. اوراکاسٹ: عوام کے لیے آڈیو نشر کریں۔

اورا کاسٹ یہ LE آڈیو کا براڈکاسٹ فنکشن ہے، اور اسے سب سے جدید حصہ کہا جا سکتا ہے۔ یہ بلوٹوتھ کے لیے ایف ایم ریڈیو کی طرح ہے۔ واحد ذریعہ، لامحدود سامعین۔

اوراکاسٹ کیسے کام کرتا ہے۔

1. ایک نشریاتی ذریعہ ایک براڈکاسٹ آئسوکرونس گروپ (BIG) بناتا ہے جس میں ایک یا زیادہ BIS اسٹریمز ہوتے ہیں۔

2. ذرائع اپنی نشریات کی تشہیر توسیع شدہ اشتہارات کا استعمال کرتے ہوئے کرتے ہیں جن میں میٹا ڈیٹا (سٹریم کا نام، زبان، کوڈیک کنفیگریشن) ہوتا ہے۔

3. براڈکاسٹ سنک اشتہارات کو دریافت کرتا ہے اور اسٹریم پیرامیٹرز حاصل کرنے کے لیے انہیں باقاعدہ اشتہاری ٹرینوں کے ساتھ ہم آہنگ کرتا ہے۔

4. سنک BIG سے جڑ جاتا ہے اور آڈیو موصول ہونا شروع کر دیتا ہے۔

اوپر کا خاکہ اوراکاسٹ نشریاتی بہاؤ کو ظاہر کرتا ہے۔ نشریاتی ذرائع توسیع شدہ اشتہارات کے ذریعے تشہیر کرتے ہیں، براڈکاسٹ سنکس اشتہارات دریافت کرتے ہیں، اسٹریم پیرامیٹرز حاصل کرنے کے لیے متواتر اشتہارات کے ساتھ مطابقت پذیر ہوتے ہیں، اور پھر آڈیو موصول کرنے کے لیے BIG میں شامل ہوتے ہیں۔ ڈوبنے کی تعداد کی کوئی حد نہیں ہے۔

اوراکاسٹ کے استعمال کے معاملات

استعمال کا معاملہ واقعی مجبور ہے۔

• ہوائی اڈے / ٹرین اسٹیشن: بورڈنگ گیٹ کے اعلانات براہ راست مسافروں کے ایئربڈز پر نشر کیے جاتے ہیں (متعدد زبانوں میں!)

• جم: دیوار پر نصب کوئی بھی ٹی وی اپنی آڈیو نشر کر سکتا ہے۔ منتخب کریں کہ کون سا TV سننا ہے۔

• میوزیم: زائرین کے ایئربڈز پر آڈیو گائیڈ سٹریمنگ

• بارز/اسپورٹس ایونٹس: سب کو پریشان کیے بغیر اپنے ائرفون میں کمنٹری کے ساتھ بڑی اسکرین پر گیم دیکھیں۔

• کانفرنس: حاضرین کے لیے ریئل ٹائم ترجمہ چینل نشر کریں۔

• خاموش ڈسکو: ضرور

باس رول: براڈکاسٹ اسسٹنٹ

ایک صاف سپورٹ تصور ہے جسے a کہا جاتا ہے۔ براڈکاسٹ اسسٹنٹ. یہ ایک آلہ ہے (عام طور پر ایک موبائل فون) جو کسی دوسرے آلے (عام طور پر ایک ایئر بڈ) کو اسٹیشن تلاش کرنے اور اس میں ٹیون کرنے میں مدد کرتا ہے۔

کیوں اس کی وجہ یہ ہے کہ چھوٹے ایئربڈز میں خود اسٹیشنوں کو تلاش کرنے اور منتخب کرنے کے لیے پروسیسنگ پاور یا UI نہیں ہو سکتا۔ لہذا آپ کا فون تلاش کرے گا، دستیاب اسٹیشن دکھائے گا اور آپ کے ایئربڈز کو بتائے گا کہ کون سا اسٹیشن سننا ہے۔ بنیاد (براڈکاسٹ آڈیو سکیننگ سروس)۔

اوپر والا خاکہ براڈکاسٹ اسسٹنٹ کا کردار دکھاتا ہے۔ فون دستیاب Auracast اسٹیشنوں کو تلاش کرتا ہے اور انہیں صارف کو دکھاتا ہے۔ جب صارف کسی اسٹیشن کا انتخاب کرتا ہے، تو فون (براڈکاسٹ اسسٹنٹ کے طور پر کام کرتا ہے) صارف کے ایئربڈز کو BASS (براڈکاسٹ آڈیو اسکین سروس) کے ذریعے منتخب اسٹیشن پر ٹیون کرنے کی ہدایت کرتا ہے۔ اس کی وجہ یہ ہے کہ ایئربڈز میں خود تلاش کرنے کے لیے UI یا پروسیسنگ پاور کی کمی ہو سکتی ہے۔

9. Android/AOSP پر LE آڈیو: نفاذ

اب آئیے کوڈ میں آتے ہیں۔ یہ وہ جگہ ہے جہاں ربڑ سڑک سے ملتا ہے۔

اینڈرائیڈ ایل ای آڈیو سپورٹ ٹائم لائن

• Android 12 (2021): ابتدائی LE آڈیو API کا تعارف (ڈیولپر پیش نظارہ معیار)

• Android 13 (2022): مکمل LE آڈیو سپورٹ بشمول یونی کاسٹ کلائنٹ/سرور اور براڈکاسٹ سورس/سنک

• Android 14 (2023): استحکام کو بہتر بناتا ہے، براڈکاسٹ آڈیو کو مضبوط کرتا ہے، LE آڈیو سورس رول کو سپورٹ کرتا ہے۔

• Android 15 (2024): اوراکاسٹ براڈکاسٹ سنک سپورٹ، براڈکاسٹ اسسٹنٹ رول، بہتر آڈیو سیاق و سباق سوئچنگ

• Android 16 (2025): بنیادی Auracast UI فوری سیٹنگز/بلوٹوتھ سیٹنگز میں، بہتر آڈیو شیئرنگ کا تجربہ

بنیادی طور پر AOSP کا LE آڈیو نفاذ بلوٹوتھ ماڈیول (packages/modules/Bluetooth) یہ ہے۔ مین لائن ماڈیولاس کا مطلب ہے کہ آپ مکمل اینڈرائیڈ OS اپ ڈیٹ سے قطع نظر گوگل پلے سسٹم اپ ڈیٹ کے ذریعے اسے اپ ڈیٹ کر سکتے ہیں۔

AOSP کے اہم مقامات

اگر آپ خود کوڈ پر ایک نظر ڈالنا چاہتے ہیں، تو خزانہ کا نقشہ یہ ہے:

عنصر	سڑک
ایل ای آڈیو جاوا سروس	packages/modules/Bluetooth/android/app/src/com/android/bluetooth/le_audio/LeAudioService.java
جے این آئی پل	packages/modules/Bluetooth/android/app/src/com/android/bluetooth/le_audio/LeAudioNativeInterface.java
مقامی LE آڈیو کلائنٹ	packages/modules/Bluetooth/system/bta/le_audio/le_audio_client.cc
کوڈیک مینیجر	packages/modules/Bluetooth/system/bta/le_audio/codec_manager.cc
ریاستی مشین	packages/modules/Bluetooth/system/bta/le_audio/state_machine.cc
LC3 کوڈیک لائبریری	external/liblc3/
فریم ورک API	frameworks/base/core/java/android/bluetooth/BluetoothLeAudio.java
براڈکاسٹ API	frameworks/base/core/java/android/bluetooth/BluetoothLeBroadcast.java

اعلی سطحی فن تعمیر

LE آڈیو کے لیے AOSP بلوٹوتھ اسٹیک اینڈرائیڈ کے کلاسک پرتوں والے فن تعمیر کی پیروی کرتا ہے۔

AOSP بلوٹوتھ LE آڈیو اسٹیک کا تہہ دار آرکیٹیکچر ڈایاگرام اوپر سے نیچے تک ایپلی کیشن لیئر کو دکھاتا ہے، فریم ورک APIs (BluetoothLeAudio، BluetoothLeBroadcast)، LeAudioService (Java)، JNI Bridge، مقامی C++ اسٹیک (le_audio_client، codec_manager، state_manager، اور ریاستی نظام)۔ بلوٹوتھ کنٹرولر ہارڈ ویئر۔

10. AOSP آرکیٹیکچر: ایپ سے اینٹینا تک

آئیے ہر پرت کو قریب سے دیکھیں۔

ٹائر 1: فریم ورک API

اینڈرائیڈ کئی عوامی API کلاسز کے ذریعے LE آڈیو فعالیت کو بے نقاب کرتا ہے: android.bluetooth:

BluetoothLeAudio

یہ unicast LE آڈیو کے لیے بنیادی API ہے۔ ایپ اسے درج ذیل مقاصد کے لیے استعمال کرتی ہے۔

• LE آڈیو آلات سے جڑیں۔

• آڈیو پلے بیک/کیپچر کے لیے ایکٹو ڈیوائس سیٹ کریں۔

• سوال گروپ کی معلومات (کوآرڈینیشن سیٹ)

• کوڈیک کنفیگریشن کو منتخب کریں۔

// Example: Connect to an LE Audio device
BluetoothLeAudio leAudio = bluetoothAdapter.getProfileProxy(
    context, listener, BluetoothProfile.LE_AUDIO);

// Set the LE Audio device as active for media playback
leAudio.setActiveDevice(leAudioDevice);

BluetoothLeBroadcast

براڈکاسٹ آڈیو کے لیے API (Auracast)۔ ایپ اسے درج ذیل مقاصد کے لیے استعمال کرتی ہے۔

• آڈیو براڈکاسٹ شروع/ بند کریں۔

• براڈکاسٹ میٹا ڈیٹا کی ترتیبات (نام، زبان)

• براڈکاسٹ کوڈ ترتیب دیں (انکرپشن پاس ورڈ)

// Start a broadcast
BluetoothLeBroadcast broadcast = bluetoothAdapter.getProfileProxy(
    context, listener, BluetoothProfile.LE_AUDIO_BROADCAST);

broadcast.startBroadcast(contentMetadata, audioConfig, broadcastCode);

BluetoothLeBroadcastAssistant

براڈکاسٹ اسسٹنٹ کے کرداروں کے لیے API، دوسرے آلات کو نشریات کو مربوط کرنے میں مدد کرتا ہے۔

BluetoothVolumeControl

VCP کے ذریعے ریموٹ والیوم کنٹرول کے لیے API۔

BluetoothHapClient

سماعت تک رسائی کے پروفائلز کے لیے API جو ہیئرنگ ایڈ کے پیش سیٹ اور سٹریمنگ کو کنٹرول کرتا ہے۔

پرت 2: LeAudioService (دماغ)

کہ LeAudioService بلوٹوتھ ایپ کے اندر ایک مرکزی سروس جو تمام LE آڈیو فنکشنز کو مربوط کرتی ہے۔ یہ وہ جگہ ہے جہاں جادو ہوتا ہے۔

اہم ذمہ داریاں:

• ڈیوائس مینجمنٹ: منسلک ایل ای آڈیو ڈیوائسز اور ان کے افعال کو ٹریک کریں۔

• گروپ مینجمنٹ: مربوط سیٹ مینجمنٹ (جو آلات ایک ساتھ تعلق رکھتے ہیں)

• آڈیو روٹنگ: تعین کریں کہ پلے بیک/کیپچر کے لیے کون سا آلہ فعال ہونا چاہیے۔

• ریاستی مشین کا انتظام: آڈیو کنکشن کے لائف سائیکل کو ہینڈل کرنا

• پروفائل ایڈجسٹمنٹ: BAP، VCP، MCP، CCP، CSIP ایڈجسٹمنٹ

یہاں طریقہ کار کا ایک آسان نظریہ ہے: LeAudioService ساخت مندرجہ ذیل ہے:

public class LeAudioService extends ProfileService {
    
    // Map of device address -> state machine
    private Map mStateMachines;
    
    // Map of group ID -> group information
    private Map mGroupDescriptors;
    
    // Native interface bridge
    private LeAudioNativeInterface mNativeInterface;
    
    // Active device tracking
    private BluetoothDevice mActiveAudioOutDevice;
    private BluetoothDevice mActiveAudioInDevice;
    
    // Codec configuration
    private BluetoothLeAudioCodecConfig mInputLocalCodecConfig;
    private BluetoothLeAudioCodecConfig mOutputLocalCodecConfig;
    
    public void connect(BluetoothDevice device) {
        // 1. Check if device supports LE Audio (PACS)
        // 2. Create state machine for device
        // 3. Initiate connection via native stack
        // 4. Discover GATT services (PACS, ASCS, VCS, etc.)
        // 5. Read audio capabilities
    }
    
    public void setActiveDevice(BluetoothDevice device) {
        // 1. Look up device's group
        // 2. Find all devices in the coordinated set
        // 3. Configure audio streams via BAP
        // 4. Set up isochronous channels
        // 5. Start audio routing
    }
}

پرت 3: مقامی اسٹیک (C++)

جاوا پرت کے نیچے، بھاری لفٹنگ C++ میں کی جاتی ہے۔ پہلے سے طے شدہ LE آڈیو نفاذ بلوٹوتھ اسٹیک میں ہے (تاریخی طور پر "فلورائڈ” کہلاتا ہے اور "گیبلڈورسے” کے نئے اجزاء بھی شامل ہے)۔

اہم بنیادی اجزاء:

le_audio_client.cc / le_audio_client_impl

LE آڈیو کلائنٹ کا بنیادی C++ نفاذ۔ یہ ہینڈل کرتا ہے:

• GATT کلائنٹ آپریشنز (سروس کی دریافت، خصوصیات پڑھیں)

• آڈیو اسٹریم اینڈ پوائنٹ (ASE) اسٹیٹ مشین مینجمنٹ

• ریموٹ ڈیوائس کے ساتھ کوڈیک مذاکرات

• CIS/BIS تخلیق اور انتظام

state_machine.cc

ہر LE آڈیو ڈیوائس کے لیے کنکشن اسٹیٹ سسٹم کا انتظام کرتا ہے۔

اوپر ایک بنیادی LE آڈیو کنیکٹیویٹی سٹیٹ مشین کا اسٹیٹ ڈایاگرام ہے جس میں ریاستیں منقطع، منسلک، منسلک، اور منقطع ہیں۔ ریاستی مشین کا انتظام ہر ڈیوائس پر بنیادی C++ پرت میں ہوتا ہے اور GATT کنکشن اسٹیبلشمنٹ، سروس کی دریافت، اور منسلک میں منتقل ہونے سے پہلے انتساب پڑھنے کو چلاتا ہے۔

codec_manager.cc

کوڈیک کنفیگریشن کو ہینڈل کرتا ہے۔

• معاون کوڈیک خصوصیات کی فہرست۔

• ڈیوائس کی صلاحیتوں اور استعمال کے کیسز کی بنیاد پر بہترین کوڈیک کنفیگریشن کا انتخاب کریں۔

• LC3 انکوڈر/ڈیکوڈر کے ساتھ انٹرفیس

iso_manager.cc

isochronous چینلز کا انتظام کرتا ہے۔

• یونی کاسٹ کے لیے CIG/CIS کی تخلیق اور ڈی کنسٹرکشن

• نشریات کے لیے BIG/BIS کی تخلیق اور ڈی کنسٹرکشن

• isochronous ڈیٹا کے لیے HCI انٹرفیس کو ہینڈل کرتا ہے۔

audio_hal_client.cc

بلوٹوتھ اسٹیک کو Android آڈیو HAL کے ساتھ منسلک کریں۔

• Android آڈیو فریم ورک سے PCM آڈیو وصول کریں۔

• اسے LC3 انکوڈر پر منتقل کریں۔

• انکوڈ شدہ آڈیو کو ایک آئسوکرونس چینل پر بھیجیں۔

پرت 4: کنٹرولر (ہارڈ ویئر)

بلوٹوتھ کنٹرولر کم سطح کے وائرلیس کاموں کو ہینڈل کرتا ہے۔

• isochronous واقعات کی لنک لیئر شیڈولنگ

• PHY پرت (1M، 2M، یا کوڈ شدہ PHY)

• پیکٹ فارمیٹنگ اور سی آر سی

• کھوئے ہوئے isochronous PDUs کی دوبارہ ترسیل

میزبان (Android) کنٹرولر کے ساتھ اس کے ذریعے بات چیت کرتا ہے: ایچ سی آئی (میزبان کنٹرولر انٹرفیس)، isochronous چینلز کے لیے مخصوص HCI کمانڈز کا استعمال کرتے ہوئے:

• HCI_LE_Set_CIG_Parameters: ایک منسلک آئسوکرونس گروپ بنانا

• HCI_LE_Create_CIS: ایک مربوط آئیسوکرونس اسٹریم بنائیں

• HCI_LE_Create_BIG: براڈکاسٹ آئسوکرونس گروپ بنائیں

• HCI_LE_Setup_ISO_Data_Path: ISO ڈیٹا پاتھ سیٹنگز (HCI اور وینڈر مخصوص)

• HCI_LE_BIG_Create_Sync: BIG سے مطابقت پذیری (براڈکاسٹ وصول کنندہ کے لیے)

11. سرور سائیڈ (ماخذ) کا نفاذ

ایل ای آڈیو کی اصطلاح میں "سرور سائیڈ” کا اصل مطلب ہے۔ یونی کاسٹ سرورایک آلہ (ایئر بڈز) جو آڈیو پیش کرتا ہے۔ ہاں، میں وصول کنندہ کو ‘سرور’ کہنے کے بارے میں الجھن میں ہوں۔ اسے GATT سرور سمجھیں۔ GATT سروس کی میزبانی کرتا ہے جس سے کلائنٹ جڑتے ہیں۔

یونی کاسٹ سرور کیا کرتا ہے۔

یونی کاسٹ سرور (ایئربڈز) کئی GATT خدمات کی میزبانی کرتا ہے۔

مندرجہ بالا خاکہ ایک GATT سروس دکھاتا ہے جس کی میزبانی یونی کاسٹ سرور (ایئربڈز) کرتی ہے۔ سرور چار اہم خدمات کو ظاہر کرتا ہے:

• شائع شدہ آڈیو کیپبلٹی سروس (PACS)، جو آلہ کے تعاون یافتہ کوڈیکس، نمونے لینے کی شرح، فریم کی مدت، اور آڈیو سیاق و سباق کا اعلان کرتی ہے۔

• آڈیو سٹریم کنٹرول سروس (ASCS)، جس میں ایک یا زیادہ آڈیو سٹریم اینڈ پوائنٹ (ASE) خصوصیات شامل ہیں جنہیں کلائنٹ آڈیو سٹریمز کو ترتیب دینے اور کنٹرول کرنے کے لیے استعمال کرتے ہیں۔

• والیوم کنٹرول سروس (VCS)، جو کلائنٹس کو ڈیوائس کے حجم کی سطح کو پڑھنے اور سیٹ کرنے کی اجازت دیتی ہے۔

• اور کوآرڈینیٹڈ سیٹ آئیڈینٹی فکیشن سروس (CSIS)، جو اس ڈیوائس کی شناخت ایک مربوط سیٹ کے حصے کے طور پر کرتی ہے (مثال کے طور پر، "میرے پاس بائیں ایئربڈ ہے اور میرے پارٹنر کے پاس دائیں ایئربڈ ہے”)۔

یونی کاسٹ کلائنٹس (فون) خصوصیات کو دریافت کرنے، اسٹریمز کو ترتیب دینے، اور پلے بیک کو کنٹرول کرنے کے لیے GATT کے ذریعے ان خدمات سے جڑتے ہیں۔

ASE ریاستی مشین (سرور سائیڈ)

ہر ایک اے ایس ای (آڈیو اسٹریم اینڈ پوائنٹ) سرور کے پاس اسٹیٹ مشین ہے۔ یہ آڈیو اسٹریم مینجمنٹ کی کلید ہے۔

اوپر یونی کاسٹ سرور کی ASE (آڈیو اسٹریم اینڈ پوائنٹ) اسٹیٹ مشین کا اسٹیٹ ڈایاگرام ہے۔ حالت: آئیڈل، کوڈیک کنفیگرڈ، QoS کنفیگرڈ، فعال، سٹریمنگ، غیر فعال، غیر فعال۔ کلائنٹ ASE کنٹرول پوائنٹ اوصاف میں آپریشنز (config codec، configure QoS، enable، disable، ٹرن آف) لکھ کر منتقلی کو چلاتا ہے۔

ریاست کی منتقلی:

1. غیر فعال → CODEC_CONFIGURED: مؤکل لکھتا ہے: Config Codec کوڈیک قسم (LC3)، نمونہ کی شرح، فریم کی مدت، وغیرہ کی وضاحت کرکے ASE کنٹرول پوائنٹس کے ساتھ کام کریں۔

2. CODEC_CONFIGURED → QoS_CONFIGURED: مؤکل لکھتا ہے: Config QoS کام، عہدہ:

3. QoS_Configured → چالو کرنا: مؤکل لکھتا ہے: Enable کام سرور آڈیو وصول کرنے کے لیے تیار ہے۔

4. فعال → سلسلہ بندی: CIS سیٹ ہو جاتا ہے اور آڈیو ڈیٹا بہنا شروع ہو جاتا ہے۔ یہ منتقلی اس وقت ہوتی ہے جب کلائنٹ CIS بناتا ہے اور دونوں فریق تیار ہوتے ہیں۔

5. سلسلہ بندی → غیر فعال: مؤکل لکھتا ہے: Disable یہ یا تو کام کر رہا ہے یا منقطع ہے۔

6. تمام ریاستیں → IDLE: مؤکل لکھتا ہے: Release ٹاسک، سٹریم کمپوزیشن کو ڈی کنسٹرکشن کرنا۔

معیاری کوڈیک کنفیگریشن

ایک BAP نامزد کوڈیک کنفیگریشنز کے ایک سیٹ کی وضاحت کرتا ہے جو مخصوص LC3 پیرامیٹرز پر نقشہ بناتا ہے۔ یہ وہ "پریسیٹس” ہیں جن پر آلہ گفت و شنید کرتا ہے:

مرکب	نمونے لینے کی شرح	فریم کی مدت	آکٹیٹ/فریم	بٹریٹ	عام استعمال
8_1	8 کلو ہرٹز	7.5ms	26	~27.7kbps	کم بینڈوتھ کی آواز
8_2	8 کلو ہرٹز	10ms	30	24kbps	کم بینڈوتھ کی آواز
16_1	16 کلو ہرٹز	7.5ms	30	32kbps	ٹیلی فونی (کم تاخیر)
16_2	16 کلو ہرٹز	10ms	40	32kbps	ٹیلی فونی (معیاری)
24_2	24kHz	10ms	60	48kbps	براڈ بینڈ آواز
32_1	32 کلو ہرٹز	7.5ms	60	64kbps	الٹرا وائیڈ بینڈ آواز
32_2	32 کلو ہرٹز	10ms	80	64kbps	الٹرا وائیڈ بینڈ آواز
48_1	48kHz	7.5ms	75	80kbps	موسیقی (کم تاخیر)
48_2	48kHz	10ms	100	80kbps	موسیقی (توازن)
48_4	48kHz	10ms	120	96kbps	موسیقی (اعلی معیار)
48_6	48kHz	10ms	155	124kbps	موسیقی (اعلیٰ ترین معیار)

زیادہ تر صارفین کے ایئربڈز کچھ اس طرح دکھائیں گے: 48_4 (48kHz پر 96kbps) (میڈیا اور 16_2 (16kHz پر 32kbps) فون کالز کے لیے۔ ایک واحد LC3 کوڈیک دونوں استعمال کے معاملات کو ہینڈل کرتا ہے – SBC اور mSBC کے درمیان مزید سوئچنگ نہیں!

آڈیو سیاق و سباق کی قسم

ایل ای آڈیو کی وضاحت کرتا ہے۔ آڈیو سیاق و سباق کی قسممیٹا ڈیٹا جو وصول کرنے والے آلے کو مطلع کرتا ہے۔ کس قسم کا آڈیو چل رہا ہے۔ یہ آلہ کو اپنے رویے کو بہتر بنانے کی اجازت دیتا ہے (مثلاً کال کے دوران شور کی منسوخی کو چالو کرنا یا موسیقی کے دوران باس کو بڑھانا)۔

سیاق و سباق	تھوڑا	جب استعمال کیا جاتا ہے۔
متعین نہیں	0x0001	عام آڈیو، کوئی خاص اصلاح نہیں۔
بات چیت	0x0002	فون کالز، VoIP، دو طرفہ، کم تاخیر
میڈیا	0x0004	موسیقی، پوڈکاسٹ، ویڈیوز، اعلیٰ معیار
کھیل	0x0008	گیمنگ، انتہائی کم تاخیر کی ترجیح
تعلیمی	0x0010	نیویگیشن کے اشارے، اعلانات
آواز اسسٹنٹ	0x0020	"ہیلو گوگل” / "ہیلو سری”
زندہ	0x0040	لائیو آڈیو (کنسرٹ، نشریات)
صوتی	0x0080	UI کلک، کی بورڈ ساؤنڈ
الارم	0x0100	پیغام کی اطلاع، ایپ کی اطلاع
رنگ ٹون	0x0200	آنے والی کال کا رنگ ٹون
انتباہ	0x0400	الارم، ٹائمر کی اطلاع
ہنگامی الارم	0x0800	ہنگامی نشریات کی اطلاع

یہ کلاسک آڈیو سے کہیں زیادہ تفصیلی ہے، جو بنیادی طور پر صرف دو حالتوں کو جانتا ہے: "پلےنگ میوزک” (A2DP) یا "ہائپنگ اے کال” (HFP)۔ LE آڈیو کے ساتھ، ڈیوائس کہتی ہے "یہ ایک گیم ہے۔ کم از کم تاخیر کے لیے 7.5ms فریم استعمال کریں۔” یا "یہ ایک اطلاع ہے، لہذا میں اس میں مداخلت کیے بغیر میوزک اسٹریم کو ملا دوں گا۔”

AOSP یونی کاسٹ سرور کا نفاذ

AOSP میں، یونی کاسٹ سرور کی فعالیت بنیادی طور پر ان صورتوں کے لیے لاگو ہوتی ہے جہاں ایک اینڈرائیڈ ڈیوائس ریسیور کے طور پر کام کرتی ہے، جیسے کہ اینڈرائیڈ پر مبنی ہیئرنگ ایڈ یا Chromebook سے آڈیو وصول کرنا۔

اہم کلاسز:

• LeAudioService.java: جب آلہ سنک رول میں ہوتا ہے تو سرور سائیڈ آپریشنز کو ہینڈل کرتا ہے۔

• مقامی کوڈ میں: le_audio_server.cc PACS، ASCS وغیرہ کی میزبانی کرنے والے GATT سرورز کا انتظام کرتا ہے۔

براڈکاسٹ سورس کا نفاذ

براڈکاسٹ آڈیو (اوراکاسٹ) کے لیے، AOSP کے سورس سائیڈ میں شامل ہیں:

// In LeAudioService.java / BroadcastService
public void startBroadcast(BluetoothLeBroadcastSettings settings) {
    // 1. Configure LC3 encoder with broadcast parameters
    // 2. Set up Extended Advertising with broadcast metadata
    // 3. Set up Periodic Advertising for stream parameters
    // 4. Create BIG via HCI
    // 5. Start sending ISO data on BIS streams
}

پہلے سے طے شدہ نفاذ:

• broadcaster.cc / broadcaster_impl: براڈکاسٹ لائف سائیکل مینجمنٹ

• مرکب توسیعی اشتہار براڈکاسٹ کا نام اور میٹا ڈیٹا پر مشتمل ہے۔

• مرکب باقاعدہ اشتہار BASE (براڈکاسٹ آڈیو سورس اینڈ پوائنٹ) ڈیٹا ڈھانچہ پہنچانے کے لیے

• نسل بڑا BIS اسٹریمز کی مناسب تعداد پر مشتمل ہے۔

• انکوڈ شدہ آڈیو کو BIS ڈیٹا پاتھ پر روٹ کریں۔

12. کلائنٹ سائیڈ (سنک) کا نفاذ

"کلائنٹ کی طرف” ہے یونی کاسٹ کلائنٹیہ عام طور پر سیل فون ہوتا ہے۔ ایل ای آڈیو ڈیوائسز کو دریافت کریں، جڑیں اور کنٹرول کریں۔

کنکشن بہاؤ

یہاں مرحلہ وار بتایا گیا ہے کہ جب آپ LE آڈیو ایئربڈز سے منسلک ہوتے ہیں تو کیا ہوتا ہے:

مراحل: BLE اسکین اور دریافت، GATT کنکشن، سروس دریافت (PACS، ASCS، CSIP، VCS تلاش کریں)، آڈیو فیچرز سیکھنے کے لیے PAC ریکارڈ پڑھیں، مربوط سیٹ ممبرشپ کی شناخت کے لیے CSIS پڑھیں، ASE کنفیگریشن (کوڈیک کنفیگریشن، QoS کنفیگریشن، فعال)، اس کے بعد CIS جنریشن اور آڈیو اسٹریمنگ۔

AOSP کلائنٹ کے نفاذ کی تفصیلات

مرحلہ 1-3: تلاش کریں اور جڑیں۔

// LeAudioService.java
public void connect(BluetoothDevice device) {
    // Creates a new LeAudioStateMachine for this device
    LeAudioStateMachine sm = getOrCreateStateMachine(device);
    sm.sendMessage(LeAudioStateMachine.CONNECT);
    
    // The state machine handles:
    // - GATT connection
    // - Service discovery
    // - Characteristic reads
}

کہ LeAudioStateMachine کنکشن لائف سائیکل کا نظم کریں۔

// LeAudioStateMachine.java (simplified)
class LeAudioStateMachine extends StateMachine {
    
    class Disconnected extends State {
        void processMessage(Message msg) {
            if (msg.what == CONNECT) {
                // Initiate GATT connection via native
                mNativeInterface.connectLeAudio(mDevice);
                transitionTo(mConnecting);
            }
        }
    }
    
    class Connecting extends State {
        void processMessage(Message msg) {
            if (msg.what == CONNECTION_STATE_CHANGED) {
                if (newState == CONNECTED) {
                    transitionTo(mConnected);
                }
            }
        }
    }
    
    class Connected extends State {
        void enter() {
            // GATT services have been discovered
            // Audio capabilities have been read
            // Device is ready for streaming
            broadcastConnectionState(BluetoothProfile.STATE_CONNECTED);
        }
    }
}

مرحلہ 4-6: قابلیت کی دریافت

بیس لیئر پی اے سی ایس کو یہ سمجھنے کے لیے پڑھتی ہے کہ ریموٹ ڈیوائس کن خصوصیات کو سپورٹ کرتی ہے۔

// In native le_audio_client_impl (C++)
void OnGattServiceDiscovery(BluetoothDevice device) {
    // Read PAC records from PACS
    ReadPacsCharacteristics(device);
    
    // Read CSIS for coordinated set info
    ReadCsisCharacteristics(device);
    
    // Read ASCS for ASE count and state
    ReadAscsCharacteristics(device);
}

void OnPacsRead(BluetoothDevice device, PacRecord sink_pac) {
    // sink_pac contains:
    //   codec_id: LC3
    //   sampling_frequencies: 48000, 44100, 32000, 24000, 16000, 8000
    //   frame_durations: 10ms, 7.5ms
    //   channel_counts: 1
    //   octets_per_frame: 40-155  (maps to bitrate range)
    //   supported_contexts: MEDIA, CONVERSATIONAL, GAME
    
    // Store capabilities for later codec negotiation
    device_info.sink_capabilities = sink_pac;
}

مرحلہ 7-12: اپنا سلسلہ ترتیب دیں۔

جب آڈیو پلے بیک شروع ہوتا ہے، کلائنٹ ترتیب دیتا ہے اور سلسلہ کو چالو کرتا ہے۔

// In native codec_manager (C++)
CodecConfig SelectCodecConfiguration(
    PacRecord remote_capabilities,
    AudioContext context  // MEDIA, CONVERSATIONAL, etc.
) {
    // For media playback, prefer high quality:
    //   48 kHz, 10ms frames, 96 kbps per channel
    
    // For voice calls, optimize for latency:
    //   16 kHz, 7.5ms frames, 32 kbps per channel
    
    // Negotiate: intersect local and remote capabilities
    // Select the best configuration both sides support
}

// In native le_audio_client_impl
void GroupStreamStart(int group_id, AudioContext context) {
    auto group = GetGroup(group_id);
    auto codec_config = SelectCodecConfiguration(
        group->GetRemoteCapabilities(), context);
    
    // For each device in the group:
    for (auto& device : group->GetDevices()) {
        // For each ASE on the device:
        for (auto& ase : device->GetAses()) {
            // Step 8: Config Codec
            WriteAseControlPoint(device, OPCODE_CONFIG_CODEC, {
                .ase_id = ase->id,
                .codec_id = LC3,
                .codec_specific = {
                    .sampling_freq = 48000,
                    .frame_duration = 10ms,
                    .channel_allocation = LEFT,  // or RIGHT
                    .octets_per_frame = 120
                }
            });
        }
    }
    // After codec configured notification:
    //   Step 9: Config QoS → Step 10: Enable → Step 11: Create CIS
}

مرحلہ 13: آڈیو ڈیٹا فلو

ایک بار اسٹریمنگ مکمل ہونے کے بعد، یہ ہے کہ آڈیو ڈیٹا AOSP اسٹیک کے ذریعے کیسے جاتا ہے:

اوپر والا خاکہ LE آڈیو سٹریمنگ کے دوران آڈیو ڈیٹا کے بہاؤ کو ظاہر کرتا ہے۔ Android آڈیو فریم ورک سے PCM آڈیو بلوٹوتھ آڈیو HAL تک پہنچتا ہے، اسے LC3 انکوڈر کے ذریعے انکوڈ کیا جاتا ہے، ایک ٹائم اسٹیمپڈ ISO SDU میں پیکٹ کیا جاتا ہے، HCI پر کنٹرولر کو بھیجا جاتا ہے، CIS پر ہوا پر، ایئربڈ کنٹرولر کو موصول ہوتا ہے، ایئربڈ LC3 ڈیکوڈر کے ذریعے ڈی کوڈ کیا جاتا ہے، اور آڈیو کے طور پر پیش کیا جاتا ہے۔

براڈکاسٹ سنک کا نفاذ

براڈکاسٹ آڈیو (Auracast) وصول کرنے کے لیے، AOSP لاگو کرتا ہے:

// Broadcast sink flow (native)
void OnBroadcastSourceFound(AdvertisingReport report) {
    // Parse Extended Advertising for broadcast metadata
    BroadcastMetadata metadata = ParseBroadcastMetadata(report);
    
    // Display: "Airport Gate B47 - English"
    NotifyBroadcastSourceFound(metadata);
}

void SyncToBroadcast(BroadcastMetadata metadata) {
    // 1. Sync to Periodic Advertising
    HCI_LE_Periodic_Advertising_Create_Sync(metadata.sync_info);
    
    // 2. On PA sync established, parse BASE
    BASE base = ParseBASE(periodic_adv_data);
    
    // 3. Select subgroup and BIS streams
    // 4. Sync to BIG
    HCI_LE_BIG_Create_Sync(base.big_params, selected_bis);
    
    // 5. Set up ISO data path
    HCI_LE_Setup_ISO_Data_Path(bis_handle, HCI_DATA_PATH);
    
    // 6. Start receiving and decoding audio
}

13. ایک ریاستی مشین جو ہر چیز کو چلاتی ہے۔

AOSP LE آڈیو نفاذ کئی باہم منسلک ریاستی مشینوں کا استعمال کرتا ہے۔

کنکشن اسٹیٹ مشین

ہر ڈیوائس کے پورے کنکشن لائف سائیکل کا نظم کریں۔

یہ اسٹیٹ ڈایاگرام LE آڈیو کنکشن اسٹیٹ مشین کو چار حالتوں کے ساتھ دکھاتا ہے: منقطع، منسلک، منسلک، اور منقطع۔

ٹرانزیشنز: ایک CONNECT ایونٹ منقطع سے منسلک کی طرف منتقل ہوتا ہے، ایک کامیاب کنکشن منسلک ہوتا ہے، ایک DISCONNECT واقعہ منقطع ہو جاتا ہے، اور COMPLETE واپس منقطع ہو جاتا ہے۔ کنکشن کے دوران ٹائم آؤٹ یا ناکامی کا نتیجہ بھی منقطع کنکشن کی صورت میں نکلے گا۔

گروپ آڈیو سٹیٹ مشین

آڈیو حالت کا نظم کریں۔ گروپ آلات کی تعداد (مربوط سیٹ):

یہ ریاستی خاکہ ہے جس میں گروپ آڈیو سٹیٹ مشین کو درج ذیل حالتوں کے ساتھ دکھایا گیا ہے: Idle، Codec Configuration، QoS کنفیگریشن، فعال، سٹریمنگ، اور غیر فعال۔ آگے کا راستہ ہر حالت میں اس ترتیب سے آگے بڑھتا ہے جس میں آڈیو اسٹریم سیٹ کیا جاتا ہے۔ رہائی کا عمل تمام ریاستوں کو بیکار حالت میں لوٹاتا ہے۔

ٹکڑے ایک ساتھ کیسے فٹ ہوتے ہیں (کوڈ واک تھرو)

یہاں ایک فوری وضاحت ہے کہ جب آپ اپنے LE آڈیو ایئربڈز کے ساتھ منسلک میوزک ایپ میں "پلے” دباتے ہیں تو کیا ہوتا ہے۔

اوپر دیا گیا خاکہ ان واقعات کی ترتیب کا سراغ لگاتا ہے جو اس وقت پیش آتے ہیں جب صارف LE آڈیو ایئربڈز سے منسلک میوزک ایپ میں "پلے” کو دباتا ہے۔

بہاؤ مندرجہ ذیل ہے:

1. میوزک ایپ پی سی ایم آڈیو کو آڈیو ٹریک پر ریکارڈ کرتی ہے۔

2. Android AudioFlinger آڈیو کو بلوٹوتھ آڈیو HAL پر روٹ کرتا ہے۔

3. HAL LeAudioService کو مطلع کرتا ہے کہ آڈیو شروع ہو رہا ہے۔

4. LeAudioService فعال گروپس کو دیکھتی ہے اور گروپ اسٹریم اسٹارٹ کو مرکزی اسٹیک پر متحرک کرتی ہے۔

5. مقامی اسٹیک ہر ڈیوائس پر ASCS کنٹرول پوائنٹ پر لکھ کر دونوں ایئربڈز پر ASE کو ترتیب دیتا ہے (Codec → Configure QoS → Enable)۔

6. ڈیفالٹ اسٹیک HCI پر دو CIS چینلز کے ساتھ ایک CIG بناتا ہے۔

7. دونوں CIS چینلز ایئربڈز پر سیٹ ہیں۔

8. آئی ایس او ڈیٹا پاتھ قائم کیا گیا ہے۔

9. PCM آڈیو HAL سے LC3 انکوڈر میں بہتا ہے، جو کمپریسڈ فریم تیار کرتا ہے۔

10. کمپریسڈ فریم HCI کے ذریعے کنٹرولر کو ISO SDUs کے طور پر بھیجے جاتے ہیں۔

11. کنٹرولر طے شدہ CIS وقفوں پر فریموں کو وائرلیس طور پر منتقل کرتا ہے۔

12. پریزنٹیشن میں تاخیر پر اتفاق رائے کے مطابق ایئر بڈز آڈیو وصول، ڈی کوڈ اور رینڈر کرتے ہیں۔

14. خلاصہ: LE آڈیو پیکٹ کی زندگی کا ایک دن

آئیے میوزک ایپ سے ایئربڈز تک ایک ہی آڈیو پیکٹ کی پیروی کریں۔

مندرجہ بالا خاکہ LE آڈیو پائپ لائن کے تمام مراحل میں ایک ہی آڈیو پیکٹ کی پیروی کرتا ہے۔

اوپر سے: میوزک ایپ PCM آڈیو تیار کرتی ہے جو Android کے AudioFlinger کے ذریعے بلوٹوتھ آڈیو HAL کو بھیجی جاتی ہے۔ HAL LC3 انکوڈر کو PCM کے 10ms نمونے (48kHz پر 480 نمونے) فیڈ کرتا ہے، جو انہیں ~ 120 بائٹ فریموں میں کمپریس کرتا ہے۔

یہ فریم ISO SDU میں لپیٹا جاتا ہے جس میں ٹائم اسٹیمپ اور ترتیب نمبر ہوتا ہے اور پھر HCI کے ذریعے بلوٹوتھ کنٹرولر کو دیا جاتا ہے۔ کنٹرولر SDU کو لنک لیئر PDUs میں تقسیم کرتا ہے، انہیں اگلے CIS ایونٹ کے لیے شیڈول کرتا ہے، اور پھر گفت و شنید شدہ PHY (جیسے 2M PHY) کا استعمال کرتے ہوئے انہیں ہوا پر منتقل کرتا ہے۔

ایئربڈ سائیڈ پر، کنٹرولر PDU وصول کرتا ہے، ISO SDU کو دوبارہ جوڑتا ہے، اور پھر LC3 فریم کو ایئربڈ ڈیکوڈر میں منتقل کرتا ہے۔ ڈیکوڈر 480 بفرڈ پی سی ایم نمونوں کی تشکیل نو کرتا ہے جب تک کہ پریزنٹیشن میں تاخیر کا ٹائم اسٹیمپ نہیں پہنچ جاتا اور پھر انہیں اسپیکر ڈرائیور کو پیش کرتا ہے۔

کل انتظار کا وقت: فون سے ایئربڈز تک ~40ms (10ms فریم + ٹرانسمیشن + پیشکش میں تاخیر)۔ اس کا موازنہ کلاسک بلوٹوتھ A2DP سے کریں، جو عام طور پر 100-200ms پر چلتا ہے!

پیش کش میں تاخیر: ہم آہنگی کا راز

کہ پیشکش میں تاخیر یہ ایک اہم LE آڈیو تصور ہے۔ ایک مقررہ تاخیر جس پر دونوں فریق سٹریم سیٹ اپ کے دوران متفق ہیں۔ تمام آڈیو کو بالکل درج ذیل مقامات پر پیش کیا جانا چاہیے (چلایا):

rendering_time = reference_anchor_point + presentation_delay

یہ یقینی بناتا ہے:

• بائیں اور دائیں ایئربڈز بالکل اسی لمحے آڈیو چلاتے ہیں۔

• یہاں تک کہ اگر ٹرانسمیشن میں تاخیر دو CIS چینلز کے درمیان مختلف ہو۔

• پریزنٹیشن میں تاخیر رسیور کے لیے جھنجھلاہٹ کو جذب کرنے کے لیے "بفر” فراہم کرتی ہے۔

کوئر کنڈکٹر کی طرح سوچیں۔ "ہر کوئی تین سیکنڈ میں گاتا ہے۔ پہلے نہیں، بعد میں نہیں۔ وہ بالکل تین پر گاتے ہیں۔”

15. نتیجہ

بلوٹوتھ ایل ای آڈیو بلوٹوتھ آڈیو میں سب سے اہم اپ گریڈ ہے جب سے یہ ایجاد ہوا ہے۔ خلاصہ کرنے کے لیے:

یہ کیا حل کرتا ہے۔

• بہتر کوڈیک (LC3) — نصف بٹ ریٹ پر ایک جیسا معیار، یا اسی بٹ ریٹ پر بہتر معیار۔

• کثیر سلسلہ — مزید ریلے ایئربڈ آرکیٹیکچر نہیں، متوازن بیٹری لائف

• آڈیو نشر کریں (اوراکاسٹ) – ایک سے کئی سٹریمنگ کے ساتھ مکمل طور پر نئے استعمال کے معاملات کو پیش کرنا

• سماعت امداد کی حمایت (HAP) – آخر کار ایک انٹرآپریبل معیاری حل

• مربوط آڈیو (BAP) — موسیقی اور کال دونوں کے لیے ایک پروفائل، مزید A2DP/HFP سوئچنگ نہیں۔

AOSP اسٹیک

• فریم ورک پرت: BluetoothLeAudio, BluetoothLeBroadcast apis

• سروس کی پرت: LeAudioService ہر چیز کو مربوط کریں

• مقامی پرت: C++ le_audio_client_impl GATT، ASE ریاستی مشین، کوڈیک مذاکرات ہینڈلنگ

• کنٹرولر پرت: CIS/BIS isochronous چینل HCI کے ذریعے منظم کیا جاتا ہے۔

آگے کیا ہے؟

LE آڈیو اب بھی پختگی کے مرحلے میں ہے۔ کلیدی ترقی کے شعبے:

• بہتر انٹرآپریبلٹی مختلف مینوفیکچررز کے آلات پر

• اوراکاسٹ انفراسٹرکچر – مقام پر ایک براڈکاسٹ ٹرانسمیٹر نصب ہونا چاہیے۔

• ڈوئل موڈ سپورٹ – منتقلی کی مدت کے دوران بہت سے آلات کلاسک اور ایل ای آڈیو دونوں کو سپورٹ کریں گے۔

• اعلی معیار جیسے جیسے بلوٹوتھ بینڈوڈتھ بہتر ہوتی ہے، ایل سی 3 زیادہ بٹ ریٹ تک پہنچ سکتا ہے۔

• جوا – بہت کم لیٹنسی کنفیگریشن (7.5ms فریم، کم سے کم پیشکش میں تاخیر)

کلاسک آڈیو سے ایل ای آڈیو میں تبدیلی راتوں رات نہیں ہوتی ہے۔ یہ IPv4 سے IPv6 میں منتقلی کے قریب ہے۔ یہ بتدریج اور بعض اوقات تکلیف دہ ہے، لیکن بالآخر ضروری ہے۔ اچھی خبر یہ ہے کہ دونوں ایک ساتھ رہ سکتے ہیں، اور AOSP کا نفاذ ان آلات کے لیے کلاسک آڈیو کے فال بیک کو سپورٹ کرتا ہے جو LE آڈیو کو سپورٹ نہیں کرتے ہیں۔

لہذا اگلی بار جب آپ اپنے ایئربڈز کو پلگ ان کریں گے اور آڈیو کوالٹی (یا اس کی کمی) پر حیران ہوں گے، تو آپ کو بخوبی معلوم ہو جائے گا کہ اس بڑے پروٹوکول اسٹیک کے کون سے حصے آپ کے فون سے آپ کے کانوں تک آواز کی لہریں پہنچانے کے لیے کام کر رہے ہیں (یا ناکام ہو رہے ہیں)۔

کوڈنگ کا مزہ لیں۔ ہم چاہتے ہیں کہ پیکٹ ہمیشہ الگ الگ رہیں!

حوالہ جات

1. بلوٹوتھ SIG – LE آڈیو تفصیلات

2. بلوٹوتھ SIG – LC3 کا تکنیکی جائزہ

3. AOSP بلوٹوتھ ماڈیول – پیکیج/ماڈیول/بلوٹوتھ

4. Zephyr پروجیکٹ – LE آڈیو اسٹیک دستاویزات

5. Fraunhofer IIS – LC3 کوڈیک