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 < [email protected]> 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 < >> [email protected]> 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 >>>>>>>> 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 a topic in the >>> Google Groups "Android Developers" group. >>> To unsubscribe from this topic, visit >>> https://groups.google.com/d/topic/android-developers/4yG4_Gw4Ilc/unsubscribe >>> . >>> To unsubscribe from this group and all its topics, send an email to >>> [email protected]. >>> To post to this group, send email to [email protected]. >>> 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/6b7520f2-8376-4f1c-9f84-8f7f310846ae%40googlegroups.com >>> <https://groups.google.com/d/msgid/android-developers/6b7520f2-8376-4f1c-9f84-8f7f310846ae%40googlegroups.com?utm_medium=email&utm_source=footer> >>> . >>> >>> For more options, visit https://groups.google.com/d/optout. >>> >> >> -- > You received this message because you are subscribed to a topic in the > Google Groups "Android Developers" group. > To unsubscribe from this topic, visit > https://groups.google.com/d/topic/android-developers/4yG4_Gw4Ilc/unsubscribe > . > To unsubscribe from this group and all its topics, send an email to > [email protected]. > To post to this group, send email to [email protected]. > 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/ecdce8c1-e5a8-463d-a9f6-6852749e6c34%40googlegroups.com > <https://groups.google.com/d/msgid/android-developers/ecdce8c1-e5a8-463d-a9f6-6852749e6c34%40googlegroups.com?utm_medium=email&utm_source=footer> > . > 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 [email protected]. To post to this group, send email to [email protected]. 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/CAAxkZQv7-LEe4Ey24nWqkUH5ou-_TFCFA%2BwCciQ%3DcuP9Yf6mMA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
