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 <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 <
>>> 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, 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
>>>> android-developers+unsubscr...@googlegroups.com.
>>>> To post to this group, send email to android-d...@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/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
>> android-developers+unsubscr...@googlegroups.com <javascript:>.
>> To post to this group, send email to android-d...@googlegroups.com
>> <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 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/c5530388-6a11-4e52-890e-94ae55dd7a78%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
