D
Answers:In the example it declares a samplerate name variable = 8000. That's right.
variable represents the number of samples that the cell phone microphone
Will you take it for a second?A: Samplerate = 8000hz means that every second 8000 microphone samples are captured, if it were 44100hz every second 44100 samples would be captured... The reverse is true, after vc saved and codified or its audio(mp3, wav, flac, etc) to play the audio in time and exact frequencies it is necessary to pour these samples into the same sampling in which it was recorded/managed, to play an audio sampled at 8000Hz your player has to play 8000 samples per second for your sound box, what happens if v100 has a sound recorded will happen something called downsample you are taking less samples per second than the audio has been generated, the audio will play much slower and seemingly coming from hell (severe frequencies).If there is the downsample process there will also be the upsample process, an audio generated at 8000hz and played at 16000hz for example, it will play twice faster and with the octave frequencies (frequencies twice higher) your audio will look like squirrels.The digital process has some characteristics of the analog process, this upsample/downsample phenomenon also happened on the vinyl records, I don't know its age, but formerly when I went into my great-grandmother's house I didn't understand what happened, she had a discs twisting to 78RPM or it would be 78 rotations per minute (mechanically had a motor that turned the disk axis at this speed) and I played .The RECORDER_AUDIO_ENCODING variable is the number of possibilities (216)
I can use to relate voltage values in digital form
with binary numbers?It is really the way you will represent the voltage values, not in binary, will be in PCM format a short int or float point, you can send plotting these values, it will be represented in the format you chose, for example if vc shrinks an audio into short int (ENCODING_PCM_16BIT) the representations of your tenders will vary between integer numbers ranging from -32768 até 32767 for an audio coded in float point ENCODING_PCM_FLOAT representations vary from -1 até 1, it's just a way of representation, some prefer short int other float point, some systems can only play in values represented in float point, in android for example there is performance difference, low-end ARM processors have worse performance with float point audios...At a certain time it takes the minimo buffer with the method
getminBufferSize(). Why does he have to do that? I can't use
the buffer size I want?Android is a system known for latency problems, OS and Hardware are problematic and working with audio on android it is necessary to be magical rsrs, the getminBufferSize() is a parameter generated by the developers of google that tries to ensure a minimum size and acceptable so that you can record your audio with less latency possible if you put a buffer size smaller than the one returned by getminBufferSize() will demand more processing and for this reason this has been stopped, and what happens if you want to put a larger buffer? will work? will this depend on your hardware and OS, the device has enough memory to work with the buffer of your choice? are questions that I will not be able to answer you...If you notice in your code the variable bufferSize is not being used anywhere, in fact the last parameter(int bufferSizeInBytes) used in your AudioRecordAudioRecord (int audioSource,
int sampleRateInHz,
int channelConfig,
int audioFormat,
int bufferSizeInBytes)
It's from 2048int BufferElements2Rec = 1024;only 1024
int BytesPerElement = 2
See:BufferElements2Rec * BytesPerElement
Just remembering that getminBufferSize() automatically generates different buffer values depending on the device, in theory you do not need to be calculating and worrying about it.
