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 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/6b7520f2-8376-4f1c-9f84-8f7f310846ae%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
