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 < > [email protected] <javascript:>> 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] <javascript:>. >> To post to this group, send email to [email protected] >> <javascript:>. >> 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/82b542ae-7bc9-48d9-993d-7921e53a0f98%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
