इस लेख में, 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
कंपाइल-टाइम सेटअप
cd frameworks/av/services/audioflinger
Configuration.h
में बदलाव करें.#define TEE_SINK
की टिप्पणी हटाएं.libaudioflinger.so
को फिर से बनाएं.adb root
adb remount
- नए
libaudioflinger.so
को डिवाइस के/system/lib
से सिंक करें या पुश करें.
रनटाइम सेटअप
adb shell getprop | grep ro.debuggable
अभी तक किसी भी व्यक्ति ने चेक इन नहीं किया है
पुष्टि करें कि आउटपुट यह है:[ro.debuggable]: [1]
adb shell
ls -ld /data/misc/audioserver
पुष्टि करें कि आउटपुट:
drwx------ media media ... media
अगर डायरेक्ट्री मौजूद नहीं है, तो इसे इस तरह से बनाएं:
mkdir /data/misc/audioserver
chown media:media /data/misc/audioserver
echo af.tee=# > /data/local.prop
अभी तक किसी भी व्यक्ति ने चेक इन नहीं किया है
जहांaf.tee
की वैल्यू, नीचे बताई गई संख्या है.chmod 644 /data/local.prop
reboot
af.tee प्रॉपर्टी की वैल्यू
af.tee
की वैल्यू, 0 से 7 के बीच की कोई संख्या होती है. इससे पता चलता है कि
कई बिट का योग, एक प्रति सुविधा.
AudioFlinger.cpp
में AudioFlinger::AudioFlinger()
पर कोड देखें
हर बिट की व्याख्या के लिए, लेकिन संक्षेप में:
- 1 = इनपुट
- 2 = FastMixer आउटपुट
- 4 = हर ट्रैक के लिए AudioRecord और AudioTrack
डीप बफ़र या सामान्य मिक्सर के लिए अभी तक कोई संसाधन नहीं मिला है, लेकिन आप "4" का इस्तेमाल करके मिलते-जुलते नतीजे पा सकते हैं.
डेटा की जांच करना और उसे हासिल करना
- अपना ऑडियो टेस्ट करें.
adb shell dumpsys media.audio_flinger
dumpsys
आउटपुट में कोई लाइन ढूंढें, जैसे कि:
tee copied to /data/misc/audioserver/20131010101147_2.wav
यह एक PCM .wav फ़ाइल है.- फिर अपनी पसंद की कोई भी
/data/misc/audioserver/*.wav
फ़ाइलेंadb pull
; ध्यान दें कि ट्रैक-विशिष्ट डंप फ़ाइल नामdumpsys
आउटपुट, हालांकि, ट्रैक बंद होने पर भी/data/misc/audioserver
में सेव किए जाएंगे. - लोगों के साथ शेयर करने से पहले, निजता से जुड़ी समस्याओं के लिए डंप फ़ाइलों की समीक्षा करें.
सुझाव
ज़्यादा काम के नतीजे पाने के लिए, ये आइडिया आज़माएं:
- टेस्ट आउटपुट में आने वाली रुकावटों को कम करने के लिए, टच साउंड और बटन पर क्लिक की सुविधा बंद करें.
- सभी वॉल्यूम को सबसे ज़्यादा करें.
- माइक्रोफ़ोन से आवाज़ या रिकॉर्ड करने वाले ऐप्लिकेशन बंद करें, अगर उन्हें आपके टेस्ट में दिलचस्पी नहीं है.
- ट्रैक वाले डंप सिर्फ़ तब सेव किए जाते हैं, जब ट्रैक बंद हो; आपको किसी ऐप्लिकेशन के ट्रैक-खास डेटा को डंप करने के लिए ज़बरदस्ती बंद करना पड़ सकता है
- जांच के तुरंत बाद
dumpsys
करें; रिकॉर्डिंग के लिए सीमित जगह उपलब्ध होती है. - यह पक्का करने के लिए कि आप अपनी डंप फ़ाइलें न खो दें, समय-समय पर उन्हें अपने होस्ट पर अपलोड करें. सिर्फ़ कुछ डंप फ़ाइलें सुरक्षित की जाती हैं; यह सीमा पूरी होने पर, पुराने डंप हटा दिए जाते हैं.
वापस लाएं
जैसा कि ऊपर बताया गया है, टी सिंक की सुविधा को चालू नहीं करना चाहिए. अपने बिल्ड और डिवाइस को इस तरह से वापस लाएं:
- सोर्स कोड में किए गए बदलावों को
Configuration.h
में पहले जैसा करें. libaudioflinger.so
को फिर से बनाएं.- वापस लाए गए
libaudioflinger.so
को पुश या सिंक करें डिवाइस के/system/lib
तक. adb shell
rm /data/local.prop
rm /data/misc/audioserver/*.wav
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 से पहले का आर्किटेक्चर](https://source.android.com/static/docs/core/audio/images/medialog_before.png?authuser=1&hl=hi)
पहला डायग्राम. Media.log से पहले का आर्किटेक्चर
अहम बातें:
init
फ़ोर्क औरmediaserver
को एक्ज़ीक्यूट करता है.init
,mediaserver
की मौत का पता लगाता है और ज़रूरत के मुताबिक फिर से फ़ोर्क करता है.ALOGx
को लॉग करने की जानकारी नहीं दिखती.
नीचे दिया गया डायग्राम, कॉम्पोनेंट के नए संबंध को दिखाता है,
media.log
को आर्किटेक्चर में जोड़ने के बाद:
![Media.log के बाद आर्किटेक्चर](https://source.android.com/static/docs/core/audio/images/medialog_after.png?authuser=1&hl=hi)
दूसरा डायग्राम. 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