ब्लूटूथ LE के ज़रिए, कान की मशीन के साथ काम करने की सुविधा

कान की मशीन (एचए) वाले डिवाइसों को Android पर चलने वाले मोबाइल डिवाइसों पर बेहतर तरीके से ऐक्सेस किया जा सकता है. इसके लिए, ब्लूटूथ लो एनर्जी (बीएलई) पर कनेक्शन-ओरिएंटेड एल2सीएपी चैनल (सीओसी) का इस्तेमाल किया जा सकता है. CoC, कई ऑडियो पैकेट के इलास्टिक बफ़र का इस्तेमाल करता है, ताकि ऑडियो का फ़्लो बना रहे. ऐसा पैकेट के न मिलने पर भी होता है. यह बफ़र, कान की मशीन वाले डिवाइसों के लिए ऑडियो क्वालिटी उपलब्ध कराता है. हालांकि, इससे ऑडियो ट्रांसफ़र होने में लगने वाला समय बढ़ जाता है.

CoC का डिज़ाइन, ब्लूटूथ (BT) कोर स्पेसिफ़िकेशन वर्शन 6.0 के हिसाब से बनाया गया है. मुख्य स्पेसिफ़िकेशन के मुताबिक, इस पेज पर मौजूद सभी मल्टी-बाइट वैल्यू को लिटिल-एंडियन के तौर पर पढ़ा जाना चाहिए.

शब्दावली

सेंट्रल
Android डिवाइस, जो ब्लूटूथ पर विज्ञापन स्कैन करता है.
पेरिफ़ेरल
यह सुनने में मदद करने वाला ऐसा डिवाइस होता है जो ब्लूटूथ पर विज्ञापन वाले पैकेट भेजता है.

नेटवर्क टोपोलॉजी और सिस्टम आर्किटेक्चर

सुनने में मदद करने वाली डिवाइसों के लिए CoC का इस्तेमाल करते समय, नेटवर्क टोपोलॉजी में एक सेंट्रल डिवाइस और दो पेरिफ़ेरल डिवाइस होते हैं. इनमें से एक बाईं ओर और एक दाईं ओर होता है. जैसा कि पहली इमेज में दिखाया गया है. ब्लूटूथ ऑडियो सिस्टम, बाएं और दाएं पेरिफ़ेरल को एक ही ऑडियो सिंक के तौर पर देखता है. अगर मोनोऑरल फ़िट या कनेक्शन न होने की वजह से कोई सहायक डिवाइस मौजूद नहीं है, तो सेंट्रल डिवाइस, बाएँ और दाएँ ऑडियो चैनल को मिक्स करता है. इसके बाद, ऑडियो को बचे हुए सहायक डिवाइस पर भेजता है. अगर सेंट्रल डिवाइस का कनेक्शन दोनों पेरिफ़ेरल डिवाइसों से टूट जाता है, तो सेंट्रल डिवाइस यह मानता है कि ऑडियो सिंक से कनेक्शन टूट गया है. ऐसे मामलों में, सेंट्रल यूनिट ऑडियो को किसी दूसरे आउटपुट पर रूट करती है.

डायग्राम में दिखाया गया है कि एक Android डिवाइस, ब्लूटूथ LE की मदद से दो कान की मशीनों से कनेक्ट है. इनमें से एक मशीन बाएं कान की है और दूसरी दाएं कान की.
पहली इमेज. कान की मशीन को Android फ़ोन या टैबलेट से जोड़ने के लिए टोपोलॉजी. इसके लिए, BLE पर CoC का इस्तेमाल किया जाता है.

जब सेंट्रल डिवाइस, पेरिफ़रल डिवाइस को ऑडियो डेटा स्ट्रीम नहीं कर रहा हो और बीएलई कनेक्शन बनाए रख सकता हो, तो सेंट्रल डिवाइस को पेरिफ़रल डिवाइस से डिसकनेक्ट नहीं होना चाहिए. कनेक्शन बनाए रखने से, पेरिफ़रल पर मौजूद GATT सर्वर को डेटा ट्रांसफ़र किया जा सकता है.

कान की मशीनों को पेयर और कनेक्ट करते समय, सेंट्रल डिवाइस को यह काम करना होगा:

  • यह कुकी, हाल ही में पेयर किए गए बाएं और दाएं पेरिफ़ेरल को ट्रैक करती है.
  • अगर डिवाइसों के बीच मान्य पेयरिंग मौजूद है, तो मान लें कि सहायक डिवाइसों का इस्तेमाल किया जा रहा है. कनेक्शन टूट जाने पर, सेंट्रल डिवाइस को पेयर किए गए डिवाइस से कनेक्ट करने या फिर से कनेक्ट करने की कोशिश करनी चाहिए.
  • अगर किसी डिवाइस को अनपेयर कर दिया जाता है, तो मान लें कि अब उसका इस्तेमाल नहीं किया जा रहा है.

ऊपर दिए गए मामलों में, पेयरिंग का मतलब, ओएस में दिए गए यूयूआईडी और बाएं/दाएं डेज़िग्नेटर के साथ हियरिंग ऐड के सेट को रजिस्टर करने से है. इसका मतलब, ब्लूटूथ पेयरिंग की प्रोसेस से नहीं है.

सिस्टम की ज़रूरतें

उपयोगकर्ताओं को बेहतर अनुभव देने के लिए, CoC को सही तरीके से लागू करने के लिए, सेंट्रल और पेरिफ़रल डिवाइसों में मौजूद Bluetooth सिस्टम को ये काम करने होंगे:

  • BT 4.2 या इसके बाद के वर्शन के साथ काम करने वाले कंट्रोलर को लागू करें. हमारा सुझाव है कि आप LE Secure Connections का इस्तेमाल करें.
  • सेंट्रल डिवाइस पर, एक साथ कम से कम दो एलई लिंक काम करने चाहिए. साथ ही, ऑडियो पैकेट के फ़ॉर्मैट और टाइमिंग में बताए गए पैरामीटर के मुताबिक काम करने चाहिए.
  • पेरिफ़ेरल पर कम से कम एक LE लिंक काम करना चाहिए. साथ ही, इसमें ऑडियो पैकेट का फ़ॉर्मैट और टाइमिंग में बताए गए पैरामीटर होने चाहिए.
  • एलई क्रेडिट पर आधारित फ़्लो कंट्रोल [बीटी वॉल्यूम 3, पार्ट ए, सेक्शन 10.1] की सुविधा. डिवाइसों में, CoC पर कम से कम 167 बाइट के MTU और MPS साइज़ का इस्तेमाल किया जा सकता हो. साथ ही, वे आठ पैकेट तक बफ़र कर सकते हों.
  • कम से कम 167 बाइट के पेलोड के साथ, एलई डेटा लेंथ एक्सटेंशन [बीटी वॉल्यूम 6, पार्ट बी, सेक्शन 5.1.9] का इस्तेमाल किया जा सकता है.
  • पक्का करें कि सेंट्रल डिवाइस, एचसीआई एलई कनेक्शन अपडेट कमांड के साथ काम करता हो और नॉन-ज़ीरो maximum_CE_Length और minimum_CE_Length पैरामीटर के मुताबिक हो.
  • ऑडियो पैकेट के फ़ॉर्मैट और टाइमिंग में, कनेक्शन इंटरवल और पेलोड साइज़ के साथ, दो LE CoC कनेक्शन के लिए सेंट्रल पर डेटा थ्रूपुट बनाए रखें. ये कनेक्शन, दो अलग-अलग पेरिफ़ेरल डिवाइसों से किए जाते हैं.
  • LL_LENGTH_REQ या LL_LENGTH_RSP फ़्रेम के पेरीफ़ेरल पर मौजूद MaxRxOctets और MaxRxTime पैरामीटर को, ज़रूरी सबसे छोटी वैल्यू पर सेट करें. ये वैल्यू, इन स्पेसिफ़िकेशन के लिए ज़रूरी हैं. इससे सेंट्रल यूनिट को फ़्रेम मिलने में लगने वाले समय का हिसाब लगाने के दौरान, टाइम शेड्यूलर को ऑप्टिमाइज़ करने में मदद मिलती है.

हमारा सुझाव है कि सेंट्रल और पेरिफ़ेरल, दोनों डिवाइसों में बीटी 5.0 स्पेसिफ़िकेशन में बताए गए 2M PHY का इस्तेमाल किया जाए. सेंट्रल डिवाइस में, 1M और 2M PHY, दोनों पर कम से कम 64 kbit/s के ऑडियो लिंक काम करने चाहिए. BLE लॉन्ग रेंज फ़िज़िकल लेयर (PHY) का इस्तेमाल नहीं किया जाना चाहिए.

CoC, लिंक लेयर एन्क्रिप्शन और फ़्रीक्वेंसी हॉपिंग के लिए, स्टैंडर्ड ब्लूटूथ मेकेनिज़्म का इस्तेमाल करता है.

ASHA GATT सेवाएं

पेरिफ़रल डिवाइस में, कान की मशीन के लिए ऑडियो स्ट्रीमिंग (एएसएचए) की जीएटीटी सर्वर सेवा लागू होनी चाहिए. इसके बारे में यहां बताया गया है. पेरिफ़रल को, सामान्य तौर पर खोजे जा सकने वाले मोड में इस सेवा का विज्ञापन दिखाना होगा, ताकि सेंट्रल डिवाइस ऑडियो सिंक को पहचान सके. LE ऑडियो स्ट्रीमिंग से जुड़ी सभी कार्रवाइयों के लिए, एन्क्रिप्शन ज़रूरी है. BLE ऑडियो स्ट्रीमिंग में ये सुविधाएं होती हैं:

खासियत प्रॉपर्टी ब्यौरा
ReadOnlyProperties पढ़ें ReadOnlyProperties देखें.
AudioControlPoint लिखें और जवाब दिए बिना लिखें ऑडियो स्ट्रीम के लिए कंट्रोल पॉइंट. AudioControlPoint देखें.
AudioStatusPoint पढ़ें/सूचना दें ऑडियो कंट्रोल पॉइंट के लिए स्टेटस रिपोर्ट फ़ील्ड. AudioStatusPoint देखें.
Volume जवाब दिए बिना लिखना यह -128 और 0 के बीच का बाइट होता है. इससे स्ट्रीम किए गए ऑडियो सिग्नल पर लागू होने वाले एटेन्यूएशन की मात्रा का पता चलता है. इसकी रेंज -48 डीबी से 0 डीबी तक होती है. -128 को पूरी तरह से म्यूट माना जाता है. इसका मतलब है कि सबसे कम वॉल्यूम लेवल -127 होता है, जो -47.625 dB के बराबर होता है. सेटिंग 0 पर, स्ट्रीम की गई रेल-टू-रेल साइन टोन, सुनने में मदद करने वाले डिवाइस पर 100 dBSPL इनपुट के बराबर होनी चाहिए. सेंट्रल डिवाइस को सामान्य तौर पर पूरी रेंज में स्ट्रीम करना चाहिए. साथ ही, इस वैरिएबल का इस्तेमाल करके, पेरिफ़ेरल डिवाइस में प्रज़ेंटेशन का मनमुताबिक लेवल सेट करना चाहिए.
LE_PSM_OUT पढ़ें ऑडियो चैनल को कनेक्ट करने के लिए, PSM का इस्तेमाल किया जाता है. इसे डाइनैमिक रेंज [BT Vol 3, Part A, Sec 4.22] से चुना जाता है.

यहां दी गई टेबल में, सेवा को असाइन किए गए यूयूआईडी और उनकी विशेषताओं के बारे में बताया गया है.

सेवा का यूयूआईडी: {0xFDF0}

खासियत यूयूआईडी
ReadOnlyProperties {6333651e-c481-4a3e-9169-7c902aad37bb}
AudioControlPoint {f0d4de7e-4a88-476c-9d9f-1937b0996cc0}
AudioStatus {38663f1a-e711-4cac-b641-326b56404837}
Volume {00e4ca9e-ab14-41e4-8823-f9e70c7e91df}
LE_PSM_OUT {2d410339-82b6-42aa-b34e-e2e01df8cc1a}

एएसएचए गैट सेवा के अलावा, पेरिफ़रल को डिवाइस की जानकारी देने वाली सेवा भी लागू करनी होगी, ताकि सेंट्रल डिवाइस, पेरिफ़रल के निर्माता के नाम और डिवाइस के नाम का पता लगा सके.

ReadOnlyProperties

ReadOnlyProperties की ये वैल्यू हैं:

बाइट ब्यौरा
0 वर्शन - 0x01 होना चाहिए
1 DeviceCapabilities देखें.
2-9 HiSyncId देखें.
10 FeatureMap देखें.
11-12 RenderDelay. यह मिलीसेकंड में वह समय होता है जब कनेक्ट किया गया दूसरा डिवाइस, ऑडियो फ़्रेम को तब तक प्रोसेस करता है, जब तक वह आउटपुट नहीं दे देता. इन बाइट का इस्तेमाल, वीडियो को ऑडियो के साथ सिंक करने के लिए किया जा सकता है.
13-14 आने वाले समय में इस्तेमाल के लिए रिज़र्व किया गया. शून्य पर सेट करें.
15-16 कोडेक आईडी के साथ काम करता है. यह काम करने वाले कोडेक आईडी का बिटमास्क है. बिट लोकेशन में 1 का मतलब है कि कोडेक काम करता है. उदाहरण के लिए, 0x0002 से पता चलता है कि 16 किलोहर्ट्ज़ पर G.722 काम करता है. अन्य सभी बिट को 0 पर सेट किया जाना चाहिए.

DeviceCapabilities

बिट ब्यौरा
0 डिवाइस की साइड (0: बाईं ओर, 1: दाईं ओर)
1 इससे पता चलता है कि डिवाइस स्टैंडअलोन है और मोनो डेटा पाता है या डिवाइस किसी सेट का हिस्सा है (0: मोनो, 1: बाइनॉरल)
2 डिवाइस पर CSIS काम करता है या नहीं (0: काम नहीं करता, 1: काम करता है)
3-7 रिज़र्व किया गया (0 पर सेट किया गया)

HiSyncId

यह फ़ील्ड, दोनों कानों में लगाए जाने वाले सभी डिवाइसों के लिए यूनीक होना चाहिए. हालांकि, यह बाएं और दाएं सेट के लिए एक जैसा होना चाहिए.

बाइट ब्यौरा
0-1 मैन्युफ़ैक्चरर का आईडी. यह बीटीएसआईजी की ओर से असाइन किया गया कंपनी आइडेंटिफ़ायर है.
2-7 यह सुनने में मदद करने वाले डिवाइस के सेट की पहचान करने वाला यूनीक आईडी होता है. यह आईडी, बाईं और दाईं, दोनों ओर मौजूद डिवाइसों के लिए एक जैसा होना चाहिए.

FeatureMap

बिट ब्यौरा
0 LE CoC ऑडियो आउटपुट स्ट्रीमिंग की सुविधा काम करती है या नहीं (हां/नहीं).
1-7 यह रिज़र्व किया गया है (इसे 0 पर सेट किया गया है).

कोडेक आईडी

अगर बिट सेट है, तो इसका मतलब है कि वह कोडेक काम करता है.

आईडी / बिट नंबर कोडेक और सैंपल रेट ज़रूरी बिटरेट फ़्रेम टाइम सेंट्रल (C) या पेरिफ़ेरल (P) पर ज़रूरी है
0 बुक किया हुआ बुक किया हुआ बुक किया हुआ बुक किया हुआ
1 G.722 @ 16 kHz 64 किलोबिट/सेकंड वैरिएबल C और P
2 से 15 तक के नंबर पहले से इस्तेमाल में हैं.

AudioControlPoint

LE CoC बंद होने पर, इस कंट्रोल पॉइंट का इस्तेमाल नहीं किया जा सकता. इस सुविधा को इस्तेमाल करने का तरीका जानने के लिए, ऑडियो स्ट्रीम शुरू करना और बंद करना लेख पढ़ें.

ऑपकोड तर्क GATT की सब-प्रोसीजर ब्यौरा
1 «Start»
  • uint8_t codec
  • uint8_t audiotype
  • int8_t volume
  • int8_t otherstate
 जवाब के साथ लिखें और AudioStatusPoint विशेषता का इस्तेमाल करके, स्थिति के बारे में अतिरिक्त सूचना पाएं. यह निर्देश, पेरिफ़ेरल को कोडेक रीसेट करने और फ़्रेम 0 का प्लेबैक शुरू करने के लिए कहता है. codec फ़ील्ड, इस प्लेबैक के लिए इस्तेमाल किए जाने वाले कोडेक आईडी के बारे में बताता है. उदाहरण के लिए, 16 किलोहर्ट्ज़ पर G.722 के लिए codec फ़ील्ड की वैल्यू `1` होती है.

ऑडियो टाइप बिट फ़ील्ड, स्ट्रीम में मौजूद ऑडियो टाइप दिखाता है:
  • 0 - जानकारी नहीं है
  • 1 - रिंगटोन
  • 2 - फ़ोन कॉल
  • 3 - मीडिया
otherstate फ़ील्ड से पता चलता है कि बाइनॉरल डिवाइस का दूसरा हिस्सा कनेक्ट है या नहीं. जब कोई अन्य पेरिफ़ेरल डिवाइस कनेक्ट होता है, तब फ़ील्ड की वैल्यू 1 होती है. ऐसा न होने पर, वैल्यू 0 होती है.

पेरिफ़रल को, «Stop» ओपकोड मिलने से पहले कनेक्शन अपडेट का अनुरोध नहीं करना चाहिए.
2 «Stop» कोई नहीं जवाब के साथ लिखें और AudioStatusPoint विशेषता का इस्तेमाल करके, स्थिति के बारे में अतिरिक्त सूचना पाएं. यह निर्देश, पेरीफ़ेरल को ऑडियो रेंडर करना बंद करने के लिए कहता है. ऑडियो को फिर से रेंडर करने के लिए, ऑडियो सेटअप करने की नई प्रोसेस शुरू करनी होगी.
3 «Status»
  • uint8_t connected
 जवाब दिए बिना लिखना यह कुकी, कनेक्ट किए गए पेरिफ़ेरल को सूचना देती है कि दूसरे पेरिफ़ेरल पर स्थिति से जुड़ा अपडेट उपलब्ध है. connected फ़ील्ड से अपडेट के टाइप के बारे में पता चलता है:
  • 0 - अन्य सहायक डिवाइस डिसकनेक्ट हो गया
  • 1 - कनेक्ट किया गया अन्य सहायक डिवाइस
  • 2 - किसी एक कनेक्शन पर LE कनेक्शन पैरामीटर अपडेट हुआ

AudioStatusPoint

ऑडियो कंट्रोल पॉइंट के लिए स्टेटस रिपोर्ट फ़ील्ड

ऑपकोड ब्यौरा
0 स्थिति ठीक है
-1 अनजान निर्देश
-2 गैर-कानूनी पैरामीटर

ASHA GATT सेवा के विज्ञापन

सेवा का यूयूआईडी, विज्ञापन पैकेट में होना चाहिए. विज्ञापन या स्कैन रिस्पॉन्स फ़्रेम में, पेरिफ़ेरल में सेवा डेटा टाइप होना चाहिए:

बाइट ऑफ़सेट नाम ब्यौरा
0 विज्ञापन की अवधि >= 0x09
1 विज्ञापन का टाइप 0x16 (सेवा का डेटा - 16-बिट यूयूआईडी)
2-3 सर्विस यूयूआईडी 0xFDF0 (little-endian)

ध्यान दें: यह एक अस्थायी आईडी है.
4 प्रोटोकॉल वर्शन 0x01
5 अनुमतियां
  • 0 - बाईं (0) या दाईं (1) ओर
  • 1 - सिंगल (0) या ड्युअल (1) डिवाइस.
  • 2 - डिवाइस पर CSIS की सुविधा काम करती है (<0: काम नहीं करती, 1: काम करती है)
  • 3-7 - आरक्षित. ये बिट शून्य होने चाहिए.
6-9 काट-छांट की गई HiSyncId HiSyncId के चार सबसे अहम बाइट. ये बाइट, आईडी का सबसे रैंडम हिस्सा होना चाहिए.

पेरिफ़ेरल में पूरा लोकल नेम डेटा टाइप होना चाहिए. इससे सुनने में मदद करने वाले डिवाइस का नाम पता चलता है. इस नाम का इस्तेमाल, मोबाइल डिवाइस के यूज़र इंटरफ़ेस पर किया जाता है, ताकि उपयोगकर्ता सही डिवाइस चुन सके. नाम में बाएं या दाएं चैनल की जानकारी नहीं होनी चाहिए, क्योंकि यह जानकारी DeviceCapabilities में दी जाती है.

अगर पेरिफ़ेरल डिवाइस, नाम और एएसएचए सेवा के डेटा टाइप को एक ही फ़्रेम टाइप (ADV या SCAN RESP) में रखते हैं, तो दोनों डेटा टाइप ("डिवाइस का पूरा नाम" और "एएसएचए सेवा के लिए सेवा डेटा") एक ही फ़्रेम में दिखने चाहिए. इससे मोबाइल डिवाइस के स्कैनर को, स्कैन के एक ही नतीजे में दोनों तरह का डेटा मिल जाता है.

शुरुआती पेयरिंग के दौरान, यह ज़रूरी है कि पेरिफ़ेरल डिवाइस, तेज़ी से विज्ञापन दिखाएं, ताकि मोबाइल डिवाइस उन्हें तुरंत ढूंढ सके और उनसे कनेक्ट हो सके.

बाएं और दाएं पेरिफ़ेरल डिवाइसों को सिंक करना

Android फ़ोन या टैबलेट पर ब्लूटूथ की सुविधा काम करे, इसके लिए यह ज़रूरी है कि पेरिफ़ेरल डिवाइस सिंक किए गए हों. बाईं और दाईं ओर मौजूद पेरिफ़ेरल डिवाइसों पर, वीडियो चलाने की सुविधा को समय के साथ सिंक करना ज़रूरी है. दोनों पेरिफ़ेरल डिवाइसों को, सोर्स से ऑडियो सैंपल एक ही समय पर चलाने चाहिए.

पेरिफ़रल डिवाइस, ऑडियो पेलोड के हर पैकेट में जोड़े गए क्रम संख्या का इस्तेमाल करके, अपने समय को सिंक कर सकते हैं. सेंट्रल डिवाइस यह पक्का करता है कि हर पेरिफ़रल डिवाइस पर एक ही समय में चलाए जाने वाले ऑडियो पैकेट का क्रम एक जैसा हो. हर ऑडियो पैकेट के बाद, क्रम संख्या में एक की बढ़ोतरी होती है. हर क्रम संख्या 8-बिट लंबी होती है. इसलिए, 256 ऑडियो पैकेट के बाद क्रम संख्याएं दोहराई जाती हैं. हर कनेक्शन के लिए, ऑडियो पैकेट का साइज़ और सैंपल रेट तय होता है. इसलिए, दोनों पेरिफ़ेरल डिवाइस, ऑडियो चलने का समय तय कर सकते हैं. ऑडियो पैकेट के बारे में ज़्यादा जानकारी के लिए, ऑडियो पैकेट का फ़ॉर्मैट और समय देखें.

सेंट्रल डिवाइस, बाइनॉरल डिवाइसों को ट्रिगर उपलब्ध कराता है, ताकि सिंक्रनाइज़ेशन किया जा सके. ये ट्रिगर, हर पेरिफ़ेरल को उसके पेयर किए गए पेरिफ़ेरल डिवाइस की स्थिति के बारे में बताते हैं. ऐसा तब होता है, जब कोई ऐसी कार्रवाई होती है जिससे सिंक्रनाइज़ेशन पर असर पड़ सकता है. ये ट्रिगर हैं:

  • AudioControlPoint की «Start» कमांड के तहत, दोनों कानों में पहने जाने वाले डिवाइसों के दूसरे हिस्से के कनेक्शन की मौजूदा स्थिति दी जाती है.
  • जब किसी एक पेरिफ़रल डिवाइस पर कनेक्शन, डिसकनेक्शन या कनेक्शन पैरामीटर अपडेट करने का ऑपरेशन होता है, तो AudioControlPoint की «Status» कमांड, दोनों कानों में पहने जाने वाले डिवाइसों के दूसरे हिस्से को भेजी जाती है.

ऑडियो पैकेट का फ़ॉर्मैट और समय

ऑडियो फ़्रेम (सैंपल के ब्लॉक) को पैकेट में पैक करने से, सुनने में मदद करने वाला डिवाइस, लिंक लेयर के टाइमिंग ऐंकर से टाइमिंग का पता लगा पाता है. इसे लागू करने की प्रक्रिया को आसान बनाने के लिए:

  • ऑडियो फ़्रेम को हमेशा कनेक्शन इंटरवल से मेल खाना चाहिए. उदाहरण के लिए, अगर कनेक्शन इंटरवल 20 मि॰से॰ है और सैंपल रेट 16 किलोहर्ट्ज़ है, तो ऑडियो फ़्रेम में 320 सैंपल होने चाहिए.
  • सिस्टम में सैंपल रेट, 8 किलोहर्ट्ज़ के मल्टीपल तक सीमित होते हैं, ताकि फ़्रेम के समय या कनेक्शन इंटरवल से कोई फ़र्क़ न पड़े और फ़्रेम में हमेशा पूर्णांक संख्या में सैंपल हों.
  • ऑडियो फ़्रेम से पहले एक सीक्वेंस बाइट होना चाहिए. सीक्वेंस बाइट को रैप-अराउंड के साथ गिना जाना चाहिए. साथ ही, इससे पेरिफ़ेरल को बफ़र के न मिलने या कम होने का पता चलना चाहिए.
  • ऑडियो फ़्रेम हमेशा एक LE पैकेट में फ़िट होना चाहिए. ऑडियो फ़्रेम को अलग L2CAP पैकेट के तौर पर भेजा जाना चाहिए. LE LL PDU का साइज़ यह होना चाहिए:
    ऑडियो पेलोड का साइज़ + 1 (सीक्वेंस काउंटर) + 6 (L2CAP हेडर के लिए 4, SDU के लिए 2)
  • कनेक्शन इवेंट हमेशा इतना बड़ा होना चाहिए कि इसमें दो ऑडियो पैकेट और दो खाली पैकेट शामिल हों. इससे ACK के लिए बैंडविड्थ को फिर से ट्रांसफ़र करने के लिए सुरक्षित रखा जा सकता है. ध्यान दें कि ऑडियो पैकेट को सेंट्रल डिवाइस के ब्लूटूथ कंट्रोलर से फ़्रैगमेंट किया जा सकता है. पेरिफ़रल को हर कनेक्शन इवेंट में, दो से ज़्यादा फ़्रैगमेंट किए गए ऑडियो पैकेट मिल पाने चाहिए.

सेंट्रल को कुछ हद तक फ़्लेक्सिबिलिटी देने के लिए, G.722 पैकेट की लंबाई तय नहीं की गई है. G.722 पैकेट की लंबाई, सेंट्रल डिवाइस के सेट किए गए कनेक्शन इंटरवल के आधार पर बदल सकती है.

G.722 आउटपुट ऑक्टेट फ़ॉर्मैट, Rec. ITU-T G.722 (09/2012) सेक्शन 1.4.4 "मल्टीप्लेक्सर" को रेफ़रंस देता है.

किसी सहायक डिवाइस (जैसे, कीबोर्ड, माउस, मॉनिटर, वेबकैम वगैरह) के साथ काम करने वाले सभी कोडेक के लिए, यह ज़रूरी है कि वह यहां दिए गए कनेक्शन पैरामीटर के साथ काम करता हो. यह उन कॉन्फ़िगरेशन की आंशिक सूची है जिन्हें सेंट्रल लागू कर सकता है.

कोडेक बिटरेट कनेक्शन इंटरवल सीई की लंबाई (10 लाख/20 लाख फ़िज़िकल लेयर) ऑडियो पेलोड का साइज़
G.722 @ 16 kHz 64 किलोबिट/सेकंड 20 मि॰से॰ 5000/3750 us 160 बाइट

ऑडियो स्ट्रीम शुरू और बंद करना

ऑडियो स्ट्रीम शुरू करने से पहले, सेंट्रल डिवाइस, पेरिफ़ेरल डिवाइसों से क्वेरी करता है और एक सामान्य डिनॉमिनेटर कोडेक सेट अप करता है. इसके बाद, स्ट्रीम सेटअप करने की प्रोसेस इस क्रम में आगे बढ़ती है:

  1. पीएसएम और RenderDelay को पढ़ा जाता है. हालांकि, RenderDelay को पढ़ना ज़रूरी नहीं है. इन वैल्यू को सेंट्रल सर्वर पर कैश मेमोरी में सेव किया जा सकता है.
  2. CoC L2CAP चैनल खुल गया है – पेरिफ़रल को शुरुआत में आठ क्रेडिट देने होंगे.
  3. लिंक को चुने गए कोडेक के लिए ज़रूरी पैरामीटर पर स्विच करने के लिए, कनेक्शन अपडेट किया जाता है. सेंट्रल, पिछले चरण में CoC कनेक्शन से पहले यह कनेक्शन अपडेट कर सकता है.
  4. सेंट्रल और पेरिफ़रल, दोनों डिवाइस अपडेट पूरा होने वाले इवेंट का इंतज़ार करते हैं.
  5. ऑडियो एन्कोडर को फिर से शुरू करें और पैकेट के क्रम की संख्या को 0 पर रीसेट करें. AudioControlPoint पर, ज़रूरी पैरामीटर के साथ «Start» निर्देश दिया जाता है. सेंट्रल डिवाइस, स्ट्रीमिंग शुरू करने से पहले, पेरिफ़ेरल डिवाइस से «Start» कमांड के लिए, स्टेटस की सूचना मिलने का इंतज़ार करता है. इस इंतज़ार से, पेरिफ़रल डिवाइस को ऑडियो चलाने की पाइपलाइन तैयार करने का समय मिल जाता है. ऑडियो स्ट्रीमिंग के दौरान, हर कनेक्शन इवेंट पर रेप्लिका उपलब्ध होनी चाहिए. भले ही, मौजूदा रेप्लिका की लेटेन्सी शून्य न हो.
  6. पेरिफ़रल, अपनी इंटरनल कतार से पहला ऑडियो पैकेट (सीक्वेंस नंबर 0) लेता है और उसे चलाता है.

सेंट्रल डिवाइस, ऑडियो स्ट्रीम बंद करने के लिए «Stop» निर्देश देता है. इस कमांड के बाद, हर कनेक्शन इवेंट पर पेरिफ़ेरल का उपलब्ध होना ज़रूरी नहीं है. ऑडियो स्ट्रीमिंग फिर से शुरू करने के लिए, ऊपर दिया गया क्रम अपनाएं. इसके लिए, पांचवें चरण से शुरू करें. जब सेंट्रल डिवाइस ऑडियो स्ट्रीम नहीं कर रहा हो, तब भी उसे GATT सेवाओं के लिए LE कनेक्शन बनाए रखना चाहिए.

पेरिफ़रल को सेंट्रल डिवाइस के लिए, कनेक्शन अपडेट जारी नहीं करना चाहिए. बैटरी बचाने के लिए, जब सेंट्रल डिवाइस से ऑडियो स्ट्रीम नहीं किया जा रहा होता है, तब वह पेरिफ़रल डिवाइस को कनेक्शन अपडेट भेज सकता है.