Re: [android-developers] Re: Audio recording problem - fake sample rate

[Julian Bunn]

That is very curious! Are you using the "VOICE_RECOGNITION" mic stream? I'm
wondering if there is some sort of odd DSP filtering being applied in the
firmware.

On Tue, Feb 9, 2016 at 8:59 AM, 'RLScott' via Android Developers <
android-developers@googlegroups.com> wrote:

> OK, I finally got myself a cheap LG G3 from eBay and did some testing.
> The situation is not exactly as I described before.  Here is what is really
> happening.  I tested my app with a sine-wave tone generator.
>
> When the tone generator is below about 3700 Hz, the spectrum displayed in
> my app shows just one peak at the desired frequency.  As the frequency of
> the tone generator increases toward 4000 Hz, a very tiny mirror image peak
> begins to appear on the other side of 4000 Hz.  It gradually gains in
> amplitude until by 3958 Hz, the amplitude of the image peak is actually a
> bit higher than the peak at the correct frequency.  As the tone goes above
> 4000 Hz, the image peak appears below 4000 Hz, and gradually decreases in
> amplitude as the tone frequency increases.  I ran the tone frequency up to
> 4698 Hz and saw a single peak at 4698 Hz in the spectrum and no image
> peak.  This entirely destroys my supposition that this phone is initially
> sampling at 8000 Hz and then up-sampling to 44100, because if it were,
> there would be no way to show a single peak at 4698 Hz with no image peak,
> right?  I mean, the information that discriminates between 4698 and 3302 is
> totally destroyed if the audio is initially sampled at 8000 Hz.
>
> But something is going on in the phone's audio system that introduces this
> image around 4000 Hz.  Could it be some sort of hetrodyning?  I know in
> single sideband radio there are ways to invert the audio spectrum if the
> detection carrier is set on the wrong side of the signal.  But why would
> things return to normal for tones well away from 4000 Hz?
>
> -Robert Scott
> Hopkins, MN
>
>
> On Tuesday, February 2, 2016 at 12:41:32 PM UTC-6, Julian Bunn wrote:
>>
>> Perhaps you can post your code, and we can take a look to see if we see
>> anything that might be causing this problem? Otherwise, if it really is a
>> firmware "feature" in those two devices, I don't see any good alternatives
>> other than a) marking your APK as incompatible with those devices in Google
>> Play, or b) doing some DSP in your software to detect the condition and
>> work around it somehow. If it were me, I would obtain a G3 and start
>> testing ...
>>
>>
>>
>> On Tue, Feb 2, 2016 at 6:08 AM, 'RLScott' via Android Developers <
>> android-d...@googlegroups.com> wrote:
>>
>>> The theory says if the initial hardware sampling is done at 8000 samples
>>> per second, the aliasing is already "frozen" into the sampled data. You can
>>> see that by observing that 4100 Hz and 3900 Hz look exactly the same -
>>> produce exactly the same samples - after they are sampled at 8000 samples
>>> per second.  No amount of digital signal processing after that point can
>>> distinguish the two cases, so the aliasing in the up-sampled FFT is
>>> inevitable, with or without windowing.
>>>
>>> I may yet get a G3 on Ebay as you say, but I was hoping for some
>>> independent confirmation of this problem with a codebase that had nothing
>>> in common with my code, in case there is something I am doing in the code
>>> that is making the difference.  So if you have an app that processes sound
>>> and can detect frequency content above 4000 Hz, just have someone with one
>>> of these failing devices go to piano and play the highest "B".  That is
>>> usually about 4019 Hz.  If the device is failing as I predict, there should
>>> also be an indication of a tone at 3981 Hz.
>>>
>>> Robert Scott
>>> Hopkins, MN
>>>
>>> On Sunday, January 31, 2016 at 1:39:58 PM UTC-6, Julian Bunn wrote:
>>>
 If you are only getting 8000 sps then even with interpolation to 44100
 you would never see any signal above 4000Hz in an FFT, right? Are you
 windowing the FFT?

 If there are truly problems like this with the audio firmware on the LG
 G3 and Nexus 7, I haven't heard any reports from my users about them.
 That's not to say there can't be an issue, of course :-) If I were you, I
 would obtain a cheap used G3 on Ebay to test with.



 On Saturday, January 30, 2016 at 6:13:08 PM UTC-8, RLScott wrote:
>
> But are you sure you are getting the sample rate you asked for?  How
> would you know?  As you can see from my very first posting, all the checks
> you are doing here work fine for me too, and I actually do get the number
> of samples per second I ask for.  But they are not true samples.  They 
> have
> been faked by up-sampling. The system takes 8000 samples per second and
> then duplicates each sample enough times to make up 44100 or 22050 or
> whatever.  But I know those samples are not true samples because I see
> aliasing around 4000 Hz in the frequency spectrum.  Unless 

Re: [android-developers] Re: Audio recording problem - fake sample rate

['RLScott' via Android Developers]

OK, I finally got myself a cheap LG G3 from eBay and did some testing.  The 
situation is not exactly as I described before.  Here is what is really 
happening.  I tested my app with a sine-wave tone generator.

When the tone generator is below about 3700 Hz, the spectrum displayed in 
my app shows just one peak at the desired frequency.  As the frequency of 
the tone generator increases toward 4000 Hz, a very tiny mirror image peak 
begins to appear on the other side of 4000 Hz.  It gradually gains in 
amplitude until by 3958 Hz, the amplitude of the image peak is actually a 
bit higher than the peak at the correct frequency.  As the tone goes above 
4000 Hz, the image peak appears below 4000 Hz, and gradually decreases in 
amplitude as the tone frequency increases.  I ran the tone frequency up to 
4698 Hz and saw a single peak at 4698 Hz in the spectrum and no image 
peak.  This entirely destroys my supposition that this phone is initially 
sampling at 8000 Hz and then up-sampling to 44100, because if it were, 
there would be no way to show a single peak at 4698 Hz with no image peak, 
right?  I mean, the information that discriminates between 4698 and 3302 is 
totally destroyed if the audio is initially sampled at 8000 Hz.

But something is going on in the phone's audio system that introduces this 
image around 4000 Hz.  Could it be some sort of hetrodyning?  I know in 
single sideband radio there are ways to invert the audio spectrum if the 
detection carrier is set on the wrong side of the signal.  But why would 
things return to normal for tones well away from 4000 Hz?

-Robert Scott
Hopkins, MN


On Tuesday, February 2, 2016 at 12:41:32 PM UTC-6, Julian Bunn wrote:
>
> Perhaps you can post your code, and we can take a look to see if we see 
> anything that might be causing this problem? Otherwise, if it really is a 
> firmware "feature" in those two devices, I don't see any good alternatives 
> other than a) marking your APK as incompatible with those devices in Google 
> Play, or b) doing some DSP in your software to detect the condition and 
> work around it somehow. If it were me, I would obtain a G3 and start 
> testing ...
>
>
>
> On Tue, Feb 2, 2016 at 6:08 AM, 'RLScott' via Android Developers <
> android-d...@googlegroups.com > wrote:
>
>> The theory says if the initial hardware sampling is done at 8000 samples 
>> per second, the aliasing is already "frozen" into the sampled data. You can 
>> see that by observing that 4100 Hz and 3900 Hz look exactly the same - 
>> produce exactly the same samples - after they are sampled at 8000 samples 
>> per second.  No amount of digital signal processing after that point can 
>> distinguish the two cases, so the aliasing in the up-sampled FFT is 
>> inevitable, with or without windowing.
>>
>> I may yet get a G3 on Ebay as you say, but I was hoping for some 
>> independent confirmation of this problem with a codebase that had nothing 
>> in common with my code, in case there is something I am doing in the code 
>> that is making the difference.  So if you have an app that processes sound 
>> and can detect frequency content above 4000 Hz, just have someone with one 
>> of these failing devices go to piano and play the highest "B".  That is 
>> usually about 4019 Hz.  If the device is failing as I predict, there should 
>> also be an indication of a tone at 3981 Hz.
>>
>> Robert Scott
>> Hopkins, MN
>>
>> On Sunday, January 31, 2016 at 1:39:58 PM UTC-6, Julian Bunn wrote:
>>
>>> If you are only getting 8000 sps then even with interpolation to 44100 
>>> you would never see any signal above 4000Hz in an FFT, right? Are you 
>>> windowing the FFT?
>>>
>>> If there are truly problems like this with the audio firmware on the LG 
>>> G3 and Nexus 7, I haven't heard any reports from my users about them. 
>>> That's not to say there can't be an issue, of course :-) If I were you, I 
>>> would obtain a cheap used G3 on Ebay to test with.
>>>
>>>
>>>
>>> On Saturday, January 30, 2016 at 6:13:08 PM UTC-8, RLScott wrote:

 But are you sure you are getting the sample rate you asked for?  How 
 would you know?  As you can see from my very first posting, all the checks 
 you are doing here work fine for me too, and I actually do get the number 
 of samples per second I ask for.  But they are not true samples.  They 
 have 
 been faked by up-sampling. The system takes 8000 samples per second and 
 then duplicates each sample enough times to make up 44100 or 22050 or 
 whatever.  But I know those samples are not true samples because I see 
 aliasing around 4000 Hz in the frequency spectrum.  Unless you 
 specifically 
 look for this problem by testing with a pure tone above 4000 Hz and 
 analyze 
 with an FFT and look for aliasing below 4000 Hz, everything will appear 
 fine.  Again this only happens on a very few models - specifically the LG 
 G3 and the Asus Nexus 7.

 On Wednesday, January 27, 

Re: [android-developers] Re: Audio recording problem - fake sample rate

['RLScott' via Android Developers]

No, I don't know anything about the "VOICE_RECOGNITION" mic stream.  I am 
just using the standard audio input stream set up with the code I posted 
earlier.  However someone in a DSP forum told me that the LG G3 has two 
mics, one in front and one in back, and they do some DSP with those two 
data streams to realize noise cancellation.  This might be some artifact of 
that operation.

-Robert Scott
 Hopkins, MN

On Tuesday, February 9, 2016 at 1:20:12 PM UTC-6, Julian Bunn wrote:
>
> That is very curious! Are you using the "VOICE_RECOGNITION" mic stream? 
> I'm wondering if there is some sort of odd DSP filtering being applied in 
> the firmware.
>
> On Tue, Feb 9, 2016 at 8:59 AM, 'RLScott' via Android Developers <
> android-d...@googlegroups.com > wrote:
>
>> OK, I finally got myself a cheap LG G3 from eBay and did some testing.  
>> The situation is not exactly as I described before.  Here is what is really 
>> happening.  I tested my app with a sine-wave tone generator.
>>
>> When the tone generator is below about 3700 Hz, the spectrum displayed in 
>> my app shows just one peak at the desired frequency.  As the frequency of 
>> the tone generator increases toward 4000 Hz, a very tiny mirror image peak 
>> begins to appear on the other side of 4000 Hz.  It gradually gains in 
>> amplitude until by 3958 Hz, the amplitude of the image peak is actually a 
>> bit higher than the peak at the correct frequency.  As the tone goes above 
>> 4000 Hz, the image peak appears below 4000 Hz, and gradually decreases in 
>> amplitude as the tone frequency increases.  I ran the tone frequency up to 
>> 4698 Hz and saw a single peak at 4698 Hz in the spectrum and no image 
>> peak.  This entirely destroys my supposition that this phone is initially 
>> sampling at 8000 Hz and then up-sampling to 44100, because if it were, 
>> there would be no way to show a single peak at 4698 Hz with no image peak, 
>> right?  I mean, the information that discriminates between 4698 and 3302 is 
>> totally destroyed if the audio is initially sampled at 8000 Hz.
>>
>> But something is going on in the phone's audio system that introduces 
>> this image around 4000 Hz.  Could it be some sort of hetrodyning?  I know 
>> in single sideband radio there are ways to invert the audio spectrum if the 
>> detection carrier is set on the wrong side of the signal.  But why would 
>> things return to normal for tones well away from 4000 Hz?
>>
>> -Robert Scott
>> Hopkins, MN
>>
>>
>> On Tuesday, February 2, 2016 at 12:41:32 PM UTC-6, Julian Bunn wrote:
>>>
>>> Perhaps you can post your code, and we can take a look to see if we see 
>>> anything that might be causing this problem? Otherwise, if it really is a 
>>> firmware "feature" in those two devices, I don't see any good alternatives 
>>> other than a) marking your APK as incompatible with those devices in Google 
>>> Play, or b) doing some DSP in your software to detect the condition and 
>>> work around it somehow. If it were me, I would obtain a G3 and start 
>>> testing ...
>>>
>>>
>>>
>>> On Tue, Feb 2, 2016 at 6:08 AM, 'RLScott' via Android Developers <
>>> android-d...@googlegroups.com> wrote:
>>>
 The theory says if the initial hardware sampling is done at 8000 
 samples per second, the aliasing is already "frozen" into the sampled 
 data. 
 You can see that by observing that 4100 Hz and 3900 Hz look exactly the 
 same - produce exactly the same samples - after they are sampled at 8000 
 samples per second.  No amount of digital signal processing after that 
 point can distinguish the two cases, so the aliasing in the up-sampled FFT 
 is inevitable, with or without windowing.

 I may yet get a G3 on Ebay as you say, but I was hoping for some 
 independent confirmation of this problem with a codebase that had nothing 
 in common with my code, in case there is something I am doing in the code 
 that is making the difference.  So if you have an app that processes sound 
 and can detect frequency content above 4000 Hz, just have someone with one 
 of these failing devices go to piano and play the highest "B".  That is 
 usually about 4019 Hz.  If the device is failing as I predict, there 
 should 
 also be an indication of a tone at 3981 Hz.

 Robert Scott
 Hopkins, MN

 On Sunday, January 31, 2016 at 1:39:58 PM UTC-6, Julian Bunn wrote:

> If you are only getting 8000 sps then even with interpolation to 44100 
> you would never see any signal above 4000Hz in an FFT, right? Are you 
> windowing the FFT?
>
> If there are truly problems like this with the audio firmware on the 
> LG G3 and Nexus 7, I haven't heard any reports from my users about them. 
> That's not to say there can't be an issue, of course :-) If I were you, I 
> would obtain a cheap used G3 on Ebay to test with.
>
>
>
> On Saturday, January 30, 2016 at 6:13:08 PM UTC-8, RLScott 

Re: [android-developers] Re: Audio recording problem - fake sample rate

['RLScott' via Android Developers]

New evidence:  I adjusted the frequency of the tone generator to give the 
worst-case spectrum imaging with two peaks of the same amplitude in my 
app.  That turned out to be 3945 Hz with an image at 4055 Hz.  Then I 
closed my app and opened the built-in Voice Recorder app.  I recorded that 
pure tone with the Voice Recorder.  When I played it back it had a nasty 
double-tones-close-together sound.  It was nothing like the pure tone I had 
recorded, but was exactly what I would expect if the Voice Recorder app as 
getting the same imaging artifact as my app - and it was!  So this is not a 
coding problem on my end.  It is a deep inherent problem with this LG G3 
phone.  I guess there is nothing more I can do.

-Robert Scott
 Hopkins, MN

On Tuesday, February 9, 2016 at 1:20:12 PM UTC-6, Julian Bunn wrote:
>
> That is very curious! Are you using the "VOICE_RECOGNITION" mic stream? 
> I'm wondering if there is some sort of odd DSP filtering being applied in 
> the firmware.
>
> On Tue, Feb 9, 2016 at 8:59 AM, 'RLScott' via Android Developers <
> android-d...@googlegroups.com > wrote:
>
>> OK, I finally got myself a cheap LG G3 from eBay and did some testing.  
>> The situation is not exactly as I described before.  Here is what is really 
>> happening.  I tested my app with a sine-wave tone generator.
>>
>> When the tone generator is below about 3700 Hz, the spectrum displayed in 
>> my app shows just one peak at the desired frequency.  As the frequency of 
>> the tone generator increases toward 4000 Hz, a very tiny mirror image peak 
>> begins to appear on the other side of 4000 Hz.  It gradually gains in 
>> amplitude until by 3958 Hz, the amplitude of the image peak is actually a 
>> bit higher than the peak at the correct frequency.  As the tone goes above 
>> 4000 Hz, the image peak appears below 4000 Hz, and gradually decreases in 
>> amplitude as the tone frequency increases.  I ran the tone frequency up to 
>> 4698 Hz and saw a single peak at 4698 Hz in the spectrum and no image 
>> peak.  This entirely destroys my supposition that this phone is initially 
>> sampling at 8000 Hz and then up-sampling to 44100, because if it were, 
>> there would be no way to show a single peak at 4698 Hz with no image peak, 
>> right?  I mean, the information that discriminates between 4698 and 3302 is 
>> totally destroyed if the audio is initially sampled at 8000 Hz.
>>
>> But something is going on in the phone's audio system that introduces 
>> this image around 4000 Hz.  Could it be some sort of hetrodyning?  I know 
>> in single sideband radio there are ways to invert the audio spectrum if the 
>> detection carrier is set on the wrong side of the signal.  But why would 
>> things return to normal for tones well away from 4000 Hz?
>>
>> -Robert Scott
>> Hopkins, MN
>>
>>
>> On Tuesday, February 2, 2016 at 12:41:32 PM UTC-6, Julian Bunn wrote:
>>>
>>> Perhaps you can post your code, and we can take a look to see if we see 
>>> anything that might be causing this problem? Otherwise, if it really is a 
>>> firmware "feature" in those two devices, I don't see any good alternatives 
>>> other than a) marking your APK as incompatible with those devices in Google 
>>> Play, or b) doing some DSP in your software to detect the condition and 
>>> work around it somehow. If it were me, I would obtain a G3 and start 
>>> testing ...
>>>
>>>
>>>
>>> On Tue, Feb 2, 2016 at 6:08 AM, 'RLScott' via Android Developers <
>>> android-d...@googlegroups.com> wrote:
>>>
 The theory says if the initial hardware sampling is done at 8000 
 samples per second, the aliasing is already "frozen" into the sampled 
 data. 
 You can see that by observing that 4100 Hz and 3900 Hz look exactly the 
 same - produce exactly the same samples - after they are sampled at 8000 
 samples per second.  No amount of digital signal processing after that 
 point can distinguish the two cases, so the aliasing in the up-sampled FFT 
 is inevitable, with or without windowing.

 I may yet get a G3 on Ebay as you say, but I was hoping for some 
 independent confirmation of this problem with a codebase that had nothing 
 in common with my code, in case there is something I am doing in the code 
 that is making the difference.  So if you have an app that processes sound 
 and can detect frequency content above 4000 Hz, just have someone with one 
 of these failing devices go to piano and play the highest "B".  That is 
 usually about 4019 Hz.  If the device is failing as I predict, there 
 should 
 also be an indication of a tone at 3981 Hz.

 Robert Scott
 Hopkins, MN

 On Sunday, January 31, 2016 at 1:39:58 PM UTC-6, Julian Bunn wrote:

> If you are only getting 8000 sps then even with interpolation to 44100 
> you would never see any signal above 4000Hz in an FFT, right? Are you 
> windowing the FFT?
>
> If there are truly problems like this with 

Re: [android-developers] Re: Audio recording problem - fake sample rate

[Julian Bunn]

I think that you should perhaps use the VOICE_RECOGNITION stream which is
*supposed* to be devoid of filtering and AGC etc..

http://developer.android.com/reference/android/media/MediaRecorder.AudioSource.html#VOICE_RECOGNITION

It's possible to select which Mic is being used, too. (My app offers a
choice between "FRONT" and "Main" mics - the Front one is typically next to
the front facing camera lens, and makes sense for video ...)



On Tue, Feb 9, 2016 at 1:19 PM, 'RLScott' via Android Developers <
android-developers@googlegroups.com> wrote:

> No, I don't know anything about the "VOICE_RECOGNITION" mic stream.  I am
> just using the standard audio input stream set up with the code I posted
> earlier.  However someone in a DSP forum told me that the LG G3 has two
> mics, one in front and one in back, and they do some DSP with those two
> data streams to realize noise cancellation.  This might be some artifact of
> that operation.
>
> -Robert Scott
>  Hopkins, MN
>
> On Tuesday, February 9, 2016 at 1:20:12 PM UTC-6, Julian Bunn wrote:
>>
>> That is very curious! Are you using the "VOICE_RECOGNITION" mic stream?
>> I'm wondering if there is some sort of odd DSP filtering being applied in
>> the firmware.
>>
>> On Tue, Feb 9, 2016 at 8:59 AM, 'RLScott' via Android Developers <
>> android-d...@googlegroups.com> wrote:
>>
>>> OK, I finally got myself a cheap LG G3 from eBay and did some testing.
>>> The situation is not exactly as I described before.  Here is what is really
>>> happening.  I tested my app with a sine-wave tone generator.
>>>
>>> When the tone generator is below about 3700 Hz, the spectrum displayed
>>> in my app shows just one peak at the desired frequency.  As the frequency
>>> of the tone generator increases toward 4000 Hz, a very tiny mirror image
>>> peak begins to appear on the other side of 4000 Hz.  It gradually gains in
>>> amplitude until by 3958 Hz, the amplitude of the image peak is actually a
>>> bit higher than the peak at the correct frequency.  As the tone goes above
>>> 4000 Hz, the image peak appears below 4000 Hz, and gradually decreases in
>>> amplitude as the tone frequency increases.  I ran the tone frequency up to
>>> 4698 Hz and saw a single peak at 4698 Hz in the spectrum and no image
>>> peak.  This entirely destroys my supposition that this phone is initially
>>> sampling at 8000 Hz and then up-sampling to 44100, because if it were,
>>> there would be no way to show a single peak at 4698 Hz with no image peak,
>>> right?  I mean, the information that discriminates between 4698 and 3302 is
>>> totally destroyed if the audio is initially sampled at 8000 Hz.
>>>
>>> But something is going on in the phone's audio system that introduces
>>> this image around 4000 Hz.  Could it be some sort of hetrodyning?  I know
>>> in single sideband radio there are ways to invert the audio spectrum if the
>>> detection carrier is set on the wrong side of the signal.  But why would
>>> things return to normal for tones well away from 4000 Hz?
>>>
>>> -Robert Scott
>>> Hopkins, MN
>>>
>>>
>>> On Tuesday, February 2, 2016 at 12:41:32 PM UTC-6, Julian Bunn wrote:

 Perhaps you can post your code, and we can take a look to see if we see
 anything that might be causing this problem? Otherwise, if it really is a
 firmware "feature" in those two devices, I don't see any good alternatives
 other than a) marking your APK as incompatible with those devices in Google
 Play, or b) doing some DSP in your software to detect the condition and
 work around it somehow. If it were me, I would obtain a G3 and start
 testing ...



 On Tue, Feb 2, 2016 at 6:08 AM, 'RLScott' via Android Developers <
 android-d...@googlegroups.com> wrote:

> The theory says if the initial hardware sampling is done at 8000
> samples per second, the aliasing is already "frozen" into the sampled 
> data.
> You can see that by observing that 4100 Hz and 3900 Hz look exactly the
> same - produce exactly the same samples - after they are sampled at 8000
> samples per second.  No amount of digital signal processing after that
> point can distinguish the two cases, so the aliasing in the up-sampled FFT
> is inevitable, with or without windowing.
>
> I may yet get a G3 on Ebay as you say, but I was hoping for some
> independent confirmation of this problem with a codebase that had nothing
> in common with my code, in case there is something I am doing in the code
> that is making the difference.  So if you have an app that processes sound
> and can detect frequency content above 4000 Hz, just have someone with one
> of these failing devices go to piano and play the highest "B".  That is
> usually about 4019 Hz.  If the device is failing as I predict, there 
> should
> also be an indication of a tone at 3981 Hz.
>
> Robert Scott
> Hopkins, MN
>
> On Sunday, January 31, 2016 at 1:39:58 PM 

Re: [android-developers] Re: Audio recording problem - fake sample rate

['RLScott' via Android Developers]

Well if that don't beat all!  It worked!  I just replaced 
MediaRecorder.AudioSource.MIC with 
MediaRecorder.AudioSource.VOICE_RECOGNITION in my "new AudioRecord(...)" 
and now the artifacts around 4000 Hz are gone.  I can sweep a tone above 
and below 4kHz and all I get is one nice peak in the FFT.  Thanks a lot for 
the suggestion.  Now I just need to test and see if my app will suffer due 
to the loss AGC.

-Robert Scott
 Hopkins, MN

On Tuesday, February 9, 2016 at 5:29:00 PM UTC-6, Julian Bunn wrote:
>
> I think that you should perhaps use the VOICE_RECOGNITION stream which is 
> *supposed* to be devoid of filtering and AGC etc..
>
>
> http://developer.android.com/reference/android/media/MediaRecorder.AudioSource.html#VOICE_RECOGNITION
>
> It's possible to select which Mic is being used, too. (My app offers a 
> choice between "FRONT" and "Main" mics - the Front one is typically next to 
> the front facing camera lens, and makes sense for video ...)
>
>
>
> On Tue, Feb 9, 2016 at 1:19 PM, 'RLScott' via Android Developers <
> android-d...@googlegroups.com > wrote:
>
>> No, I don't know anything about the "VOICE_RECOGNITION" mic stream.  I am 
>> just using the standard audio input stream set up with the code I posted 
>> earlier.  However someone in a DSP forum told me that the LG G3 has two 
>> mics, one in front and one in back, and they do some DSP with those two 
>> data streams to realize noise cancellation.  This might be some artifact of 
>> that operation.
>>
>> -Robert Scott
>>  Hopkins, MN
>>
>> On Tuesday, February 9, 2016 at 1:20:12 PM UTC-6, Julian Bunn wrote:
>>>
>>> That is very curious! Are you using the "VOICE_RECOGNITION" mic stream? 
>>> I'm wondering if there is some sort of odd DSP filtering being applied in 
>>> the firmware.
>>>
>>> On Tue, Feb 9, 2016 at 8:59 AM, 'RLScott' via Android Developers <
>>> android-d...@googlegroups.com> wrote:
>>>
 OK, I finally got myself a cheap LG G3 from eBay and did some testing.  
 The situation is not exactly as I described before.  Here is what is 
 really 
 happening.  I tested my app with a sine-wave tone generator.

 When the tone generator is below about 3700 Hz, the spectrum displayed 
 in my app shows just one peak at the desired frequency.  As the frequency 
 of the tone generator increases toward 4000 Hz, a very tiny mirror image 
 peak begins to appear on the other side of 4000 Hz.  It gradually gains in 
 amplitude until by 3958 Hz, the amplitude of the image peak is actually a 
 bit higher than the peak at the correct frequency.  As the tone goes above 
 4000 Hz, the image peak appears below 4000 Hz, and gradually decreases in 
 amplitude as the tone frequency increases.  I ran the tone frequency up to 
 4698 Hz and saw a single peak at 4698 Hz in the spectrum and no image 
 peak.  This entirely destroys my supposition that this phone is initially 
 sampling at 8000 Hz and then up-sampling to 44100, because if it were, 
 there would be no way to show a single peak at 4698 Hz with no image peak, 
 right?  I mean, the information that discriminates between 4698 and 3302 
 is 
 totally destroyed if the audio is initially sampled at 8000 Hz.

 But something is going on in the phone's audio system that introduces 
 this image around 4000 Hz.  Could it be some sort of hetrodyning?  I know 
 in single sideband radio there are ways to invert the audio spectrum if 
 the 
 detection carrier is set on the wrong side of the signal.  But why would 
 things return to normal for tones well away from 4000 Hz?

 -Robert Scott
 Hopkins, MN


 On Tuesday, February 2, 2016 at 12:41:32 PM UTC-6, Julian Bunn wrote:
>
> Perhaps you can post your code, and we can take a look to see if we 
> see anything that might be causing this problem? Otherwise, if it really 
> is 
> a firmware "feature" in those two devices, I don't see any good 
> alternatives other than a) marking your APK as incompatible with those 
> devices in Google Play, or b) doing some DSP in your software to detect 
> the 
> condition and work around it somehow. If it were me, I would obtain a G3 
> and start testing ...
>
>
>
> On Tue, Feb 2, 2016 at 6:08 AM, 'RLScott' via Android Developers <
> android-d...@googlegroups.com> wrote:
>
>> The theory says if the initial hardware sampling is done at 8000 
>> samples per second, the aliasing is already "frozen" into the sampled 
>> data. 
>> You can see that by observing that 4100 Hz and 3900 Hz look exactly the 
>> same - produce exactly the same samples - after they are sampled at 8000 
>> samples per second.  No amount of digital signal processing after that 
>> point can distinguish the two cases, so the aliasing in the up-sampled 
>> FFT 
>> is inevitable, with or without windowing.
>>
>> I may yet get 

Re: [android-developers] Re: Audio recording problem - fake sample rate

[Julian Bunn]

Excellent news!



On Tue, Feb 9, 2016 at 6:24 PM, 'RLScott' via Android Developers <
android-developers@googlegroups.com> wrote:

> Well if that don't beat all!  It worked!  I just replaced
> MediaRecorder.AudioSource.MIC with
> MediaRecorder.AudioSource.VOICE_RECOGNITION in my "new AudioRecord(...)"
> and now the artifacts around 4000 Hz are gone.  I can sweep a tone above
> and below 4kHz and all I get is one nice peak in the FFT.  Thanks a lot for
> the suggestion.  Now I just need to test and see if my app will suffer due
> to the loss AGC.
>
> -Robert Scott
>  Hopkins, MN
>
> On Tuesday, February 9, 2016 at 5:29:00 PM UTC-6, Julian Bunn wrote:
>>
>> I think that you should perhaps use the VOICE_RECOGNITION stream which is
>> *supposed* to be devoid of filtering and AGC etc..
>>
>>
>> http://developer.android.com/reference/android/media/MediaRecorder.AudioSource.html#VOICE_RECOGNITION
>>
>> It's possible to select which Mic is being used, too. (My app offers a
>> choice between "FRONT" and "Main" mics - the Front one is typically next to
>> the front facing camera lens, and makes sense for video ...)
>>
>>
>>
>> On Tue, Feb 9, 2016 at 1:19 PM, 'RLScott' via Android Developers <
>> android-d...@googlegroups.com> wrote:
>>
>>> No, I don't know anything about the "VOICE_RECOGNITION" mic stream.  I
>>> am just using the standard audio input stream set up with the code I posted
>>> earlier.  However someone in a DSP forum told me that the LG G3 has two
>>> mics, one in front and one in back, and they do some DSP with those two
>>> data streams to realize noise cancellation.  This might be some artifact of
>>> that operation.
>>>
>>> -Robert Scott
>>>  Hopkins, MN
>>>
>>> On Tuesday, February 9, 2016 at 1:20:12 PM UTC-6, Julian Bunn wrote:

 That is very curious! Are you using the "VOICE_RECOGNITION" mic stream?
 I'm wondering if there is some sort of odd DSP filtering being applied in
 the firmware.

 On Tue, Feb 9, 2016 at 8:59 AM, 'RLScott' via Android Developers <
 android-d...@googlegroups.com> wrote:

> OK, I finally got myself a cheap LG G3 from eBay and did some
> testing.  The situation is not exactly as I described before.  Here is 
> what
> is really happening.  I tested my app with a sine-wave tone generator.
>
> When the tone generator is below about 3700 Hz, the spectrum displayed
> in my app shows just one peak at the desired frequency.  As the frequency
> of the tone generator increases toward 4000 Hz, a very tiny mirror image
> peak begins to appear on the other side of 4000 Hz.  It gradually gains in
> amplitude until by 3958 Hz, the amplitude of the image peak is actually a
> bit higher than the peak at the correct frequency.  As the tone goes above
> 4000 Hz, the image peak appears below 4000 Hz, and gradually decreases in
> amplitude as the tone frequency increases.  I ran the tone frequency up to
> 4698 Hz and saw a single peak at 4698 Hz in the spectrum and no image
> peak.  This entirely destroys my supposition that this phone is initially
> sampling at 8000 Hz and then up-sampling to 44100, because if it were,
> there would be no way to show a single peak at 4698 Hz with no image peak,
> right?  I mean, the information that discriminates between 4698 and 3302 
> is
> totally destroyed if the audio is initially sampled at 8000 Hz.
>
> But something is going on in the phone's audio system that introduces
> this image around 4000 Hz.  Could it be some sort of hetrodyning?  I know
> in single sideband radio there are ways to invert the audio spectrum if 
> the
> detection carrier is set on the wrong side of the signal.  But why would
> things return to normal for tones well away from 4000 Hz?
>
> -Robert Scott
> Hopkins, MN
>
>
> On Tuesday, February 2, 2016 at 12:41:32 PM UTC-6, Julian Bunn wrote:
>>
>> Perhaps you can post your code, and we can take a look to see if we
>> see anything that might be causing this problem? Otherwise, if it really 
>> is
>> a firmware "feature" in those two devices, I don't see any good
>> alternatives other than a) marking your APK as incompatible with those
>> devices in Google Play, or b) doing some DSP in your software to detect 
>> the
>> condition and work around it somehow. If it were me, I would obtain a G3
>> and start testing ...
>>
>>
>>
>> On Tue, Feb 2, 2016 at 6:08 AM, 'RLScott' via Android Developers <
>> android-d...@googlegroups.com> wrote:
>>
>>> The theory says if the initial hardware sampling is done at 8000
>>> samples per second, the aliasing is already "frozen" into the sampled 
>>> data.
>>> You can see that by observing that 4100 Hz and 3900 Hz look exactly the
>>> same - produce exactly the same samples - after they are sampled at 8000
>>> samples per second.  No amount of digital 

Re: [android-developers] Re: Audio recording problem - fake sample rate

[Julian Bunn]

Perhaps you can post your code, and we can take a look to see if we see
anything that might be causing this problem? Otherwise, if it really is a
firmware "feature" in those two devices, I don't see any good alternatives
other than a) marking your APK as incompatible with those devices in Google
Play, or b) doing some DSP in your software to detect the condition and
work around it somehow. If it were me, I would obtain a G3 and start
testing ...



On Tue, Feb 2, 2016 at 6:08 AM, 'RLScott' via Android Developers <
android-developers@googlegroups.com> wrote:

> The theory says if the initial hardware sampling is done at 8000 samples
> per second, the aliasing is already "frozen" into the sampled data. You can
> see that by observing that 4100 Hz and 3900 Hz look exactly the same -
> produce exactly the same samples - after they are sampled at 8000 samples
> per second.  No amount of digital signal processing after that point can
> distinguish the two cases, so the aliasing in the up-sampled FFT is
> inevitable, with or without windowing.
>
> I may yet get a G3 on Ebay as you say, but I was hoping for some
> independent confirmation of this problem with a codebase that had nothing
> in common with my code, in case there is something I am doing in the code
> that is making the difference.  So if you have an app that processes sound
> and can detect frequency content above 4000 Hz, just have someone with one
> of these failing devices go to piano and play the highest "B".  That is
> usually about 4019 Hz.  If the device is failing as I predict, there should
> also be an indication of a tone at 3981 Hz.
>
> Robert Scott
> Hopkins, MN
>
> On Sunday, January 31, 2016 at 1:39:58 PM UTC-6, Julian Bunn wrote:
>
>> If you are only getting 8000 sps then even with interpolation to 44100
>> you would never see any signal above 4000Hz in an FFT, right? Are you
>> windowing the FFT?
>>
>> If there are truly problems like this with the audio firmware on the LG
>> G3 and Nexus 7, I haven't heard any reports from my users about them.
>> That's not to say there can't be an issue, of course :-) If I were you, I
>> would obtain a cheap used G3 on Ebay to test with.
>>
>>
>>
>> On Saturday, January 30, 2016 at 6:13:08 PM UTC-8, RLScott wrote:
>>>
>>> But are you sure you are getting the sample rate you asked for?  How
>>> would you know?  As you can see from my very first posting, all the checks
>>> you are doing here work fine for me too, and I actually do get the number
>>> of samples per second I ask for.  But they are not true samples.  They have
>>> been faked by up-sampling. The system takes 8000 samples per second and
>>> then duplicates each sample enough times to make up 44100 or 22050 or
>>> whatever.  But I know those samples are not true samples because I see
>>> aliasing around 4000 Hz in the frequency spectrum.  Unless you specifically
>>> look for this problem by testing with a pure tone above 4000 Hz and analyze
>>> with an FFT and look for aliasing below 4000 Hz, everything will appear
>>> fine.  Again this only happens on a very few models - specifically the LG
>>> G3 and the Asus Nexus 7.
>>>
>>> On Wednesday, January 27, 2016 at 10:57:45 AM UTC-6, Julian Bunn wrote:

 Yes, that looks fine to me ... In case it helps, here is a snippet of
 what I do to check a samplerate is going to work:

 minBuffer = AudioRecord
   .getMinBufferSize(rate, config, encoding);
 if (minBuffer != AudioRecord.ERROR_BAD_VALUE
   && minBuffer != AudioRecord.ERROR) {
boolean bGood = true;
try {
   audio = new AudioRecord(audioSource, rate, config,
 encoding, minBuffer);
   int istate = audio.getState();
   if (istate != AudioRecord.STATE_INITIALIZED)
  bGood = false;
} catch (Exception e) {
   bGood = false;
}
audio.release();
audio = null;
if (bGood)
   return rate;


 On Tuesday, January 26, 2016 at 12:49:46 PM UTC-8, RLScott wrote:
>
> I am calling
> AudioRecord.getMinBufferSize(44100,AudioFormat.CHANNEL_IN_MONO,AudioFormat.ENCODING_PCM_16BIT)
> and using the returned minAudioRecordBufSize in
>
>   new AudioRecord(MediaRecorder.AudioSource.MIC,
> 44100,AudioFormat.CHANNEL_IN_MONO,
>AudioFormat.ENCODING_PCM_16BIT,
> minAudioRecordBufSize);
>
> Is that sizing the buffers correctly?
>
> Thanks for the offer for the enumeration app, but I do not have a
> failing device at my disposal.  Only a few devices are failing, and they
> are all owned by my customers.  I can't ask too much of them in the way of
> debugging help.
>
>
> On Friday, January 15, 2016 at 1:34:15 AM UTC-6, Julian Bunn wrote:
>>
>> Make sure you are sizing the buffers correctly i.e. respecting the
>> minimum recording buffer size (in bytes) required. If you don't then I

Re: [android-developers] Re: Audio recording problem - fake sample rate

[Massimo Messore]

>From my experience you should first try with 44100 and use 48000 or 22050
just as fallback.

Regards.
Il 23/dic/2015 18:53, "Robert Scott"  ha scritto:

> I first call *AudioRecord.getMinBufferSize(22050...*  If this returns an
> error (<1) then I call *AudioRecord.getMinBufferSize(44100...*  Whichever
> one of these calls succeeds, I use that rate in my call to "*new
> AudioRecord(..,sampleRate..)*"
>
> I don't actually have one of these misbehaving devices, so my experiments
> so far have been with the help of my customers.
>
> -Robert Scott
>  Hopkins, MN
>
> --
> You received this message because you are subscribed to the Google Groups
> "Android Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to android-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to android-developers@googlegroups.com.
> Visit this group at https://groups.google.com/group/android-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/android-developers/061e6451-424d-4d40-b262-b869d7371ab5%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Android Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to android-developers+unsubscr...@googlegroups.com.
To post to this group, send email to android-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/android-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/android-developers/CAMUXMhvToP_y1ErY8oXx-2rBKZ7ZRimPxoUbTs9iCy2hE8XThA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.