Dear Glenn, I want to ask other questions about Glitch Test in Audio Quality Verifier.
What theory does Glitch Test determine which sample is a glitch? We have tried two ways to verify this issue. One was to set the default input sampling rate to 16kHz in HAL. If we used this way, AudioFlinger will not apply the resampling algorithm to the stream, because the request sampling rate from the application is the same as the default input sampling rate which HAL provides. The resampling procedure is applied by ALSA lib, and it makes the sampling rate of the stream from 48kHz to 16kHz. Another way is to set the default input sampling rate to 48kHz in HAL. Because input 48kHz sampling rate can be supported by the audio codec, ALSA lib does not have to resample the stream. However, the application still needs 16kHz sampling rate stream data, so AudioFlinger will apply the resampling algorithm to the stream to make it from 48kHz to 16kHz. We discovered that both ways have simliar result that one of the two glitch test items may failed. As we know, Glitch Test cannot have any glitch detected, and Glitch Test(7) allows 1-7 glitches detected during testing. The most of the failed reasons we got for Glitch Test were 1 glitch detected, and the reasons for Glitch Test(7) were often 0 glitch detected So, I want to ask whether both Glitch Test items are easily affected by the background noise and sound. Is it possible that the resampling algorithm has the chance to eliminate or weaken some glitch samples during interpolating that makes Glitch Test can not find the glich samples? Thank you Best regards, Audi Audi Huang於 2012年6月15日星期五UTC+8下午11時21分58秒寫道： > > Dear Glenn, > > First, thank for your reply and help. > > Glenn Kasten於 2012年6月14日星期四UTC+8下午11時50分28秒寫道： >> >> I would like to help you with this, but need more information. >> >> Is this for output (speaker) or input (microphone)? >> >> > This is a test for verifying the input stream quality of MIC. > Glitch test is a loopback test in Audio Quality Verifier which generates > a 625Hz tone and playback it with a external speaker which is connected > with the jack. > The internal MIC of the device has to capture the tone from the speaker. > Glitch test application analyzes the stream captured by the MIC to find > the glitches. > Because the audio codec only supports 44kHz and above sampling rate, the > input streams have to resample to 16kHz which CTSVerifier requests. > So, this case is for input stream. > > >> By "AndroidResampler", which source file do you mean (full pathname in >> the source code tree)? >> (there are a few resamplers so I want to make sure I know which one you >> are talking about) >> > > As I know, the default resampler which AudioFlinger uses now is > AndroidResamplerOrder1 defined in > frameworks/base/service/audioflinger/AudioResampler.cpp. > > >> >> > You mentioned "the default sampling rate in HAL is 8kHz". Why is that? >> > > I don't know why the default sampling rate for stream capturing is set to > 8kHz in the code base I have now. > 8kHz is supported for most embedded audio codec IC, but in our platform, a > HD audio codec is adopted and it only supports at least 44kHz for capturing > streams. > > > >> Which section of CTSVerifier failed? >> > > Now, we have "Glitch Test" and "Glitch Test(7)" failed in Audio Quality > Verifier. > > >> By "HD Audio Codec" do you mean a specific codec chip (in which case >> please give the manufacturer and model), >> or any generic "high definition" codec? >> > > The platform uses a Conexant 20590 HD audio codec and a Fortemedia D-MIC. > > Thank you. > Best regards, > Audi > -- unsubscribe: android-porting+unsubscr...@googlegroups.com website: http://groups.google.com/group/android-porting
