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
>>>>>> 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-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/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 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/CAAxkZQsfS7Y8Ym20Ohqii8FpmA_cYqYp6%3Dh2UiX%3DbqnLsFWc7Q%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to