ऑडियो डीबग करने की सुविधा

इस लेख में, Android ऑडियो को डीबग करने के लिए कुछ सुझाव और तरकीबें बताई गई हैं.

टी सिंक

"टी सिंक" इससे मेल खाता है AudioFlinger डीबग करने की सुविधा, सिर्फ़ कस्टम बिल्ड में उपलब्ध है, ताकि बाद में विश्लेषण करने के लिए, हाल ही के ऑडियो के छोटे हिस्से को बनाए रखा जा सके. इससे असल में सुने गए या रिकॉर्ड किए गए वीडियो के बीच तुलना की जा सकती है उम्मीद के मुताबिक नहीं है.

निजता की सुरक्षा के लिए, सिंक करने की सुविधा डिफ़ॉल्ट रूप से बंद रहती है. हालांकि, कंपाइलेशन के दौरान और सिंक करने के दौरान, रन-टाइम. टी सिंक का इस्तेमाल करने के लिए, आपको उसे फिर से कंपाइल करके चालू करना होगा, ऐसा करने के लिए आपको प्रॉपर्टी सेट करनी होगी. ऐसा करने के बाद, इस सुविधा को बंद करना न भूलें डीबग किया गया; टी सिंक को प्रोडक्शन बिल्ड में चालू नहीं रखा जाना चाहिए.

इस सेक्शन में दिए गए निर्देश, Android 7.x और उसके बाद के वर्शन के लिए हैं. Android के लिए 5.x और 6.x, /data/misc/audioserver को इससे बदलें /data/misc/media. इसके अलावा, आपको किसी userdebug का इस्तेमाल करना होगा या इंजीनियरिंग बिल्ड. अगर किसी userdebug बिल्ड का इस्तेमाल किया जाता है, तो वेरिटी को इसके साथ बंद करें:

adb root && adb disable-verity && adb reboot

कंपाइल-टाइम सेटअप

1. cd frameworks/av/services/audioflinger
2. Configuration.h में बदलाव करें.
3. #define TEE_SINK की टिप्पणी हटाएं.
4. libaudioflinger.so को फिर से बनाएं.
5. adb root
6. adb remount
7. नए libaudioflinger.so को डिवाइस के /system/lib से सिंक करें या पुश करें.

रनटाइम सेटअप

1. adb shell getprop | grep ro.debuggable अभी तक किसी भी व्यक्ति ने चेक इन नहीं किया है
   पुष्टि करें कि आउटपुट यह है: [ro.debuggable]: [1]
2. adb shell
3. ls -ld /data/misc/audioserver
   

   पुष्टि करें कि आउटपुट:

   drwx------ media media ... media
   

   अगर डायरेक्ट्री मौजूद नहीं है, तो इसे इस तरह से बनाएं:

   mkdir /data/misc/audioserver
   chown media:media /data/misc/audioserver
   

4. echo af.tee=# > /data/local.prop अभी तक किसी भी व्यक्ति ने चेक इन नहीं किया है
   जहां af.tee की वैल्यू, नीचे बताई गई संख्या है.
5. chmod 644 /data/local.prop
6. reboot

af.tee प्रॉपर्टी की वैल्यू

af.tee की वैल्यू, 0 से 7 के बीच की कोई संख्या होती है. इससे पता चलता है कि कई बिट का योग, एक प्रति सुविधा. AudioFlinger.cpp में AudioFlinger::AudioFlinger() पर कोड देखें हर बिट की व्याख्या के लिए, लेकिन संक्षेप में:

• 1 = इनपुट
• 2 = FastMixer आउटपुट
• 4 = हर ट्रैक के लिए AudioRecord और AudioTrack

डीप बफ़र या सामान्य मिक्सर के लिए अभी तक कोई संसाधन नहीं मिला है, लेकिन आप "4" का इस्तेमाल करके मिलते-जुलते नतीजे पा सकते हैं.

डेटा की जांच करना और उसे हासिल करना

1. अपना ऑडियो टेस्ट करें.
2. adb shell dumpsys media.audio_flinger
3. dumpsys आउटपुट में कोई लाइन ढूंढें, जैसे कि:
   tee copied to /data/misc/audioserver/20131010101147_2.wav
   यह एक PCM .wav फ़ाइल है.
4. फिर अपनी पसंद की कोई भी /data/misc/audioserver/*.wav फ़ाइलें adb pull; ध्यान दें कि ट्रैक-विशिष्ट डंप फ़ाइल नाम dumpsys आउटपुट, हालांकि, ट्रैक बंद होने पर भी /data/misc/audioserver में सेव किए जाएंगे.
5. लोगों के साथ शेयर करने से पहले, निजता से जुड़ी समस्याओं के लिए डंप फ़ाइलों की समीक्षा करें.

सुझाव

ज़्यादा काम के नतीजे पाने के लिए, ये आइडिया आज़माएं:

• टेस्ट आउटपुट में आने वाली रुकावटों को कम करने के लिए, टच साउंड और बटन पर क्लिक की सुविधा बंद करें.
• सभी वॉल्यूम को सबसे ज़्यादा करें.
• माइक्रोफ़ोन से आवाज़ या रिकॉर्ड करने वाले ऐप्लिकेशन बंद करें, अगर उन्हें आपके टेस्ट में दिलचस्पी नहीं है.
• ट्रैक वाले डंप सिर्फ़ तब सेव किए जाते हैं, जब ट्रैक बंद हो; आपको किसी ऐप्लिकेशन के ट्रैक-खास डेटा को डंप करने के लिए ज़बरदस्ती बंद करना पड़ सकता है
• जांच के तुरंत बाद dumpsys करें; रिकॉर्डिंग के लिए सीमित जगह उपलब्ध होती है.
• यह पक्का करने के लिए कि आप अपनी डंप फ़ाइलें न खो दें, समय-समय पर उन्हें अपने होस्ट पर अपलोड करें. सिर्फ़ कुछ डंप फ़ाइलें सुरक्षित की जाती हैं; यह सीमा पूरी होने पर, पुराने डंप हटा दिए जाते हैं.

वापस लाएं

जैसा कि ऊपर बताया गया है, टी सिंक की सुविधा को चालू नहीं करना चाहिए. अपने बिल्ड और डिवाइस को इस तरह से वापस लाएं:

1. सोर्स कोड में किए गए बदलावों को Configuration.h में पहले जैसा करें.
2. libaudioflinger.so को फिर से बनाएं.
3. वापस लाए गए libaudioflinger.so को पुश या सिंक करें डिवाइस के /system/lib तक.
4. adb shell
5. rm /data/local.prop
6. rm /data/misc/audioserver/*.wav
7. reboot

Media.log

ALOGx मैक्रो

Android SDK में, स्टैंडर्ड Java लैंग्वेज लॉग एपीआई इस्तेमाल करें android.util.Log.

Android NDK में इससे जुड़ा C लैंग्वेज एपीआई है __android_log_print अभी तक किसी भी व्यक्ति ने चेक इन नहीं किया है <android/log.h> में एलान किया गया था.

Android फ़्रेमवर्क के मूल हिस्से में, हम ALOGE, ALOGW नाम वाले मैक्रो पसंद करें, ALOGI, ALOGV वगैरह. इनका एलान किया गया है <utils/Log.h> और इस लेख के उद्देश्यों के लिए हम सामूहिक रूप से उन्हें ALOGx कहेंगे.

ये सभी एपीआई इस्तेमाल में आसान हैं और समझने में आसान हैं. इसलिए, ये ज़्यादा बड़े होते हैं पूरे Android प्लैटफ़ॉर्म पर दिखते हैं. खास तौर पर, mediaserver प्रक्रिया, जिसमें AudioFlinger साउंड सर्वर शामिल है, बड़े पैमाने पर ALOGx.

फिर भी, ALOGx और दोस्तों के लिए कुछ सीमाएं हैं:

• इन पर "स्पैम लॉग इन किया जा सकता है": लॉग बफ़र एक शेयर किया गया संसाधन है ताकि यह गैर-ज़रूरी लॉग एंट्री की वजह से आसानी से ओवरफ़्लो हो सके. इसकी वजह से छूटी हुई जानकारी. ALOGV वैरिएंट को इस पर बंद कर दिया जाता है: डिफ़ॉल्ट रूप से कंपाइल-टाइम. हालांकि, इससे लॉग स्पैम भी हो सकता है अगर यह चालू है.
• मौजूदा कर्नेल सिस्टम कॉल ब्लॉक हो सकते हैं, जिसकी वजह से प्राथमिकता में आने वाले व्युत्क्रम और नतीजतन मेज़रमेंट में आने वाली रुकावटें और गड़बड़ियां. यह इसका है FastMixer और FastCapture जैसे समय के हिसाब से संवेदनशील थ्रेड के लिए खास चिंता.
• अगर स्पैम लॉग को कम करने के लिए, किसी लॉग को बंद कर दिया गया है, तो उस लॉग से कैप्चर की गई कोई भी जानकारी खो जाती है. किसी खास लॉग को रेट्रोऐक्टिव रूप से चालू नहीं किया जा सकता, के बाद यह साफ़ हो जाता है कि लॉग दिलचस्प होता.

NBLOG, Media.log, और MediaLogService

NBLOG एपीआई और उससे जुड़े media.log प्रोसेस और MediaLogService सेवा मिलकर मीडिया के लिए एक नया लॉगिंग सिस्टम तैयार करती है और खास तौर पर ऊपर बताई गई समस्याओं को हल करने के लिए डिज़ाइन किया गया है. हम इस शब्द का बहुत कम इस्तेमाल करेंगे "media.log" का उल्लेख करें, लेकिन NBLOG को सख्ती से C++ लॉगिंग एपीआई, media.log एक Linux प्रोसेस का नाम है और MediaLogService लॉग की जांच करने के लिए, एक Android बाइंडर सेवा है.

media.log "टाइमलाइन" एक सीरीज़ है लॉग एंट्री के लिए जिनके मिलते-जुलते क्रम को सुरक्षित रखा गया है. कन्वेंशन के मुताबिक, हर थ्रेड को अपनी टाइमलाइन का इस्तेमाल करना चाहिए.

फ़ायदे

media.log सिस्टम के ये फ़ायदे हैं:

• मुख्य लॉग को तब तक स्पैम नहीं करता, जब तक ज़रूरी न हो.
• mediaserver के क्रैश होने या हैंग हो जाने पर भी जांच की जा सकती है.
• यह हर टाइमलाइन के हिसाब से ब्लॉक न हो.
• इससे परफ़ॉर्मेंस पर कोई असर नहीं पड़ता. (बेशक, किसी भी तरह की लॉगिंग पूरी तरह से रुकावट नहीं डालता.)

भवन निर्माण

नीचे दिया गया डायग्राम, mediaserver प्रोसेस के साथ संबंध दिखाता है media.log के लॉन्च होने से पहले की init प्रोसेस:

पहला डायग्राम. Media.log से पहले का आर्किटेक्चर

अहम बातें:

• init फ़ोर्क और mediaserver को एक्ज़ीक्यूट करता है.
• init, mediaserver की मौत का पता लगाता है और ज़रूरत के मुताबिक फिर से फ़ोर्क करता है.
• ALOGx को लॉग करने की जानकारी नहीं दिखती.

नीचे दिया गया डायग्राम, कॉम्पोनेंट के नए संबंध को दिखाता है, media.log को आर्किटेक्चर में जोड़ने के बाद:

दूसरा डायग्राम. Media.log के बाद आर्किटेक्चर

ज़रूरी बदलाव:

• क्लाइंट, लॉग एंट्री बनाने और उन्हें उनमें जोड़ने के लिए, NBLOG एपीआई का इस्तेमाल करते हैं शेयर की गई मेमोरी में एक सर्कुलर बफ़र.
• MediaLogService किसी भी समय सर्कुलर बफ़र की सामग्री को डंप कर सकता है.
• सर्कुलर बफ़र को इस तरह से डिज़ाइन किया गया है कि शेयर की गई मेमोरी, MediaLogService को क्रैश नहीं करेगी. हालांकि, ऐसा तब भी होगा, जब उस बफ़र का इस्तेमाल किया जा सकता है जिस पर इस गड़बड़ी का असर नहीं हुआ है.
• सर्कुलर बफ़र, लिखने, दोनों के लिए ब्लॉक नहीं करता और लॉक-फ़्री होता है नई एंट्री करने और मौजूदा एंट्री को पढ़ने से भी रोका जा सकता है.
• सर्कुलर बफ़र में लिखने या उससे पढ़ने के लिए, किसी कर्नेल सिस्टम कॉल की ज़रूरत नहीं है (वैकल्पिक टाइमस्टैंप के अलावा).

यहां इस्तेमाल करें

Android 4.4 के बाद के वर्शन में, AudioFlinger में कुछ ही लॉग पॉइंट होते हैं जो media.log सिस्टम का इस्तेमाल करते हैं. हालांकि नए API ALOGx के तौर पर इस्तेमाल करना आसान है, लेकिन ये भी ज़्यादा मुश्किल नहीं हैं. हम चाहते हैं कि आप लॉग इन करने के नए सिस्टम के बारे में जानें उन मौकों पर इस्तेमाल किया जा सकता है जब इसकी ज़रूरत न हो. खास तौर पर, हमारा सुझाव है कि ऐसे AudioFlinger थ्रेड के लिए बार-बार, समय-समय पर और रोक लगाए बिना चलता है, जैसे कि FastMixer और FastCapture थ्रेड.

कैसे इस्तेमाल करें

लॉग जोड़ें

सबसे पहले, आपको अपने कोड में लॉग जोड़ने होंगे.

FastMixer और FastCapture थ्रेड में, इस तरह के कोड का इस्तेमाल करें:

logWriter->log("string");
logWriter->logf("format", parameters);
logWriter->logTimestamp();

क्योंकि इस NBLog टाइमलाइन का इस्तेमाल सिर्फ़ FastMixer और FastCapture थ्रेड, बाहर रहने वाले लोगों को एक-दूसरे से बाहर करने की ज़रूरत नहीं है.

अन्य AudioFlinger थ्रेड में, mNBLogWriter का इस्तेमाल करें:

mNBLogWriter->log("string");
mNBLogWriter->logf("format", parameters);
mNBLogWriter->logTimestamp();

FastMixer और FastCapture के अलावा, अन्य थ्रेड के लिए थ्रेड की NBLog टाइमलाइन का इस्तेमाल थ्रेड, दोनों के लिए किया जा सकता है और बाइंडर ऑपरेशन से. NBLog::Writer कोई जानकारी उपलब्ध नहीं कराता है हर टाइमलाइन में इंप्लिसिट म्युचुअली एक्सक्लूज़न, इसलिए पक्का करें कि सभी लॉग मौजूद हों जहां थ्रेड का म्यूटक्स mLock होल्ड पर रखा गया हो.

लॉग जोड़ने के बाद, AudioFlinger फिर से बनाएं.

चेतावनी: हर थ्रेड के लिए, एक अलग NBLog::Writer टाइमलाइन ज़रूरी है, ताकि थ्रेड की सुरक्षा को पक्का किया जा सके, क्योंकि टाइमलाइन में म्यूटेक्स को डिज़ाइन के हिसाब से हटा दिया जाता है. अगर आपको एक ही टाइमलाइन का इस्तेमाल एक से ज़्यादा थ्रेड के लिए किया जा सकता है. इसके लिए, मौजूदा म्यूटेक्स (जैसा कि mLock के लिए ऊपर बताया गया है). या आप यह कर सकते हैं: NBLog::Writer के बजाय NBLog::LockedWriter रैपर का इस्तेमाल करें. हालांकि, ऐसा करने से इस एपीआई के मुख्य फ़ायदे पर रोक लग जाती है: यह एपीआई सेवा को ब्लॉक नहीं करता व्यवहार.

पूरा NBLog एपीआई frameworks/av/include/media/nbaio/NBLog.h पर मौजूद है.

Media.log चालू करें

media.log की सुविधा डिफ़ॉल्ट रूप से बंद रहती है. यह सिर्फ़ तब चालू होता है, जब प्रॉपर्टी ro.test_harness 1 है. इसे चालू करने के लिए:

adb root
adb shell
echo ro.test_harness=1 > /data/local.prop
chmod 644 /data/local.prop
reboot

फिर से चालू करने के दौरान कनेक्शन टूट जाता है, इसलिए:

adb shell

अभी तक किसी भी व्यक्ति ने चेक इन नहीं किया है आदेश ps media अब दो प्रक्रियाएं दिखाएगा:

• Media.log
• मीडिया सर्वर

mediaserver के प्रोसेस आईडी को बाद के लिए नोट करें.

समयावधि दिखाएं

लॉग डंप को मैन्युअल तरीके से किसी भी समय अनुरोध किया जा सकता है. यह निर्देश सभी चालू और हाल ही की टाइमलाइन से लॉग दिखाता है और फिर उन्हें मिटा देता है:

dumpsys media.log

ध्यान दें कि डिज़ाइन की टाइमलाइन अलग-अलग होती है, और टाइमलाइन मर्ज करने की कोई सुविधा नहीं है.

मीडिया सर्वर के बंद होने के बाद लॉग वापस पाएं

अब mediaserver प्रोसेस को बंद करने की कोशिश करें: kill -9 #, जहां # है उस प्रोसेस आईडी का इस्तेमाल करें जिसे आपने पहले नोट किया था. आपको media.log से डंप दिखेगा मुख्य logcat में, क्रैश होने के लिए इस्तेमाल होने वाले सभी लॉग दिखाए गए हैं.

dumpsys media.log