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 

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

[paul zazzarino]

WORKAROUND

Instead of restricting your app for those devices when your recording fails 
to meet the sample rate then pop up a dialog and ask the user if your app 
should "Emit" the required tone instead of recording.

The end user can then repeatedly play the desired frequency on you app via 
a button, they can adjust the piano string to match the frequency they hear 
from the device.  [ inverse mode ]

They should hear "beats" when the frequencies approach each other.


On Wednesday, December 23, 2015 at 11:16:41 AM UTC-5, Robert Scott wrote:
>
> There is an audio recording problem with some devices, even newer ones.  
> The native audio recording sample rate appears to be a puny 8000 Hz, which 
> means it can only render frequencies up to 4000 Hz.  This is a problem for 
> my piano tuning app which must detect frequencies above 4000 Hz. to tune 
> the top few notes.
>
> So far I have only gotten reports of this problem on certain models of the 
> LG G3 and the Nexus 7 (Asus).  The worst part is these devices do not 
> return an error when we try to set up an audio input stream and request a 
> sample rate of 22050 Hz.  Instead they take their 8000 samples per second 
> and up-sample by duplicating each sample 2 or 3 times to give us audio that 
> appears to be sampled at 22050 samples per second as requested, but it 
> still cannot faithfully render frequencies above 4000 Hz, so our piano 
> tuning app gives very strange results for the top few notes on the piano.
>
> Does anyone here work with audio input apps and can you confirm this 
> problem on any other devices?  You can test it out by sideloading our app 
> from
>
>   www.tunelab-world.com/atl.html
>
> It will run in free-trial mode well enough to test this out.  To test for 
> the sampling rate problem, tap on the large "A4" and select the note "B7" 
> by tapping on the "7" first.  Then on a different device or computer, 
> generate a tone at 3950 Hz.  One such on-line source is 
>
>   onlinetonegenerator.com/
>
> If this tone produces just one peak in the spectrum display at 3950 Hz, 
> then everything is fine.  But if this produces two peaks - one at 3950 and 
> the other at 4050, then you have a device that is sampling at 8000 Hz and 
> then up-sampling to feed our app a fake 22050 samples per second.
>
> -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/460bc1e6-5fd5-4cb7-83be-3c8dfd77b8d1%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

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

['RLScott' via Android Developers]

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?
>

No, 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 4263 Hz.  If the device is failing as I predict, there should 
also be an indication of a tone at 3737 Hz.

>
>
>
>
> 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 
> believe the system will drop you down to 8kHz sample rate, which is what 
> you are seeing (I think?).
>
>
> On Wednesday, December 23, 2015 at 9:52:37 AM UTC-8, Robert Scott 
> wrote:
>>
>> 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] Re: Audio recording problem - fake sample rate

['RLScott' via Android Developers]

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 
> believe the system will drop you down to 8kHz sample rate, which is what 
> you are seeing (I think?).
>
>
> On Wednesday, December 23, 2015 at 9:52:37 AM UTC-8, Robert Scott 
> wrote:
>>
>> 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 

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

[Julian Bunn]

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 
 believe the system will drop you down to 8kHz sample rate, which is what 
 you are seeing (I think?).


 On Wednesday, December 23, 2015 at 9:52:37 AM UTC-8, Robert Scott wrote:
>
> 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/006d2392-ebc3-449d-b632-278699e5c55f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

['RLScott' via Android Developers]

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 
>>> believe the system will drop you down to 8kHz sample rate, which is what 
>>> you are seeing (I think?).
>>>
>>>
>>> On Wednesday, December 23, 2015 at 9:52:37 AM UTC-8, Robert Scott wrote:

 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/c04a2d86-42bd-46dc-892e-4ef32b4b6759%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[Julian Bunn]

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 
>> believe the system will drop you down to 8kHz sample rate, which is what 
>> you are seeing (I think?).
>>
>>
>> On Wednesday, December 23, 2015 at 9:52:37 AM UTC-8, Robert Scott wrote:
>>>
>>> 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/d0543519-0ea3-4eb4-9200-1ac60d465cc1%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

['RLScott' via Android Developers]

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 believe the 
> system will drop you down to 8kHz sample rate, which is what you are seeing 
> (I think?).
>
>
> On Wednesday, December 23, 2015 at 9:52:37 AM UTC-8, Robert Scott wrote:
>>
>> 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/b8184f0f-de72-457f-98c9-bc63d98343d7%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[Robert Scott]

Not even 44,100 works correctly on the LG-G3.  I got one of my customers to 
try an experimental version of my app on their LG-G3.  This experimental 
version used 44,100 samples per second right from the beginning.  It turns 
out that on the LG-G3 this customer has, the audio is first sampled at only 
8000 samples per second, and the up-sampled to create 44,100 samples per 
second, which does not contain all the frequency content it would have had 
if it were sampled at 44,100 to being with.  I see no way around it.


On Wednesday, December 23, 2015 at 11:52:37 AM UTC-6, Robert Scott wrote:
>
> 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/1f4c4b7a-8490-4151-963c-c2ed43837755%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[Julian Bunn]

I have a free app called "AudioCaps" on Play, which will iterate through 
all standard play/record modes/rates and create a list of them with the min 
buffer sizes, that your user can then email to you. I found this helpful 
when I initially released AudioTool - maybe it will provide more "remote 
insight" for you? 

Julian

On Wednesday, December 23, 2015 at 9:52:37 AM UTC-8, Robert Scott wrote:
>
> 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/e02e3415-1020-4344-8e57-0d405ba99df0%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[Julian Bunn]

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 believe the 
system will drop you down to 8kHz sample rate, which is what you are seeing 
(I think?).


On Wednesday, December 23, 2015 at 9:52:37 AM UTC-8, Robert Scott wrote:
>
> 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/b1513818-8928-4d64-b106-99d75a76ea69%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[Robert Scott]

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.

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.