I am developing an android application which records audio in PCM using the AudioRecord API. I want to adjust the mic sensitivity to low, medium and high as the user chooses it in the settings.
Is it possible to adjust the mic sensitivity? Your answers will be highly appreciated :)
Not really. It's usually possible to get at least two different "sensitivities" (acoustic tunings used by the platform) implicitly by using different AudioSources.There should at least be one tuning for handset recording and one for far-field recording. On some devices you might also have different far-field tunings, e.g. one for recording audio a few decimeters away and one for recording audio a few meters away.
The problem is that you can't really know which AudioSource corresponds to which tuning, as there's no standard for it. CAMCORDER typically means far-field, and VOICE_RECOGNITION often means handset mode, but there's no guarantee for it. You should also keep in mind that vendors typically apply automatic gain control, noise reduction, etc that you as a user / app developer can't disable, in order to meet acoustic requirements for their products.
Your best bet would probably be to use a single AudioSource and then do attenuation of the signal in your app to simulate a lower mic sensitivity. You could do amplification as well, but that would be akin to using digital zoom in the camera app (it works, but doesn't look all that good because you're just scaling the existing data).
Related
My application is measuring volume of captured audio as a function of samples absolute amplitude.
I've noticed and unexpected behavior in android.media.AudioRecord of Android SDK. Let's assume following flow:
Application is launched
Audio volume is being measured
Phone call is answered/dialed
Audio volume is being measured
The noise around the microphone is produced by TV with constant volume setting. Values measured for point 2 are in range [55-65] and values measured for point 4 are in range [15-25] (please see the audio visualization for 2. and 4. below).
I understand that there must be some volume adjustment going on when phone call occurs. Is it possible to monitor those adjustments or to get rid of them?
I've tried AutomaticGainControl but it is not supported on my Nexus 5 and I do not want to use it since the target devices might not support it as well.
Update
This volume adjustment is happening not only after phone call. I've just noticed the same behavior when phone was just lying on the table measuring volume.
In regard to resources that your app is sharing with other apps (the microphone in this matter) - you should always treat them carefully and assume there configuration may change during a phone call or other usage like switching to another app that's using the microphone.
Instead of trying to monitor for changes in gain , which may require root or other elevated privileges - I would take another approach and do the following:
Save the mic sensitivity level to a configuration file (shared_prefs) in your recording activity when the user is recording . do the same if the user changes it of course during usage of your app.
In the onResume proc of your recording activity - load the mic sensitivity level value and set it before continuing to record (How to adjust microphone sensitivity while recording audio in android - Solved)
If there is a phone call that throws your app to the background and takes control of the mic, once it's finished - your app will return to the foreground and retain the mic sensitivity level for further recording.
Hope this helps.
I am developing an android app for recording the sound. In my app i will display the SPL (Sound Pressure Level) in dB. As part of my search, i come across, mobile hardware can only record sounds up to <= 110 dB. The reason is, mobiles are designed for human voice recording and that falls under the range of 60 dB. So if i need to record the sounds which is more than 110 dB how the mobile hardware will respond to that? Do i need to depend upon external devices and not the mobiles? Please provide your comments.
Thanks & regards,
Siva.
Your question is in fact about the dynamic range of the audio input of a mobile phone - any value you record must be capable of being represented in the scale used to measure it.
There is an associated question of what the largest sound pressure level that a particular phone can record, but this is ultimately limited by the dynamic range and the design of transducer used. Any absolutely measure is relative a calibration point - which in digital audio systems is dB FSD (e.g. ratio sample to maximum), yielding negative values.
The dynamic range in dB of a ideal PCM system is limited by quantisation noise and is related directly to bit-depth (Q) of the sample:
SQNR = 20*log10(2 ^ Q) =~ 6.02Q
State-of-the-art ADCs used in pro-audio equipment typically have 24-bit sample depth giving a SQNR of 144dB. It's worth noting, that in silicon ADCs and DACs, the thermal noise floor of the analogue section of the converter is smaller than this, and the LSB might as well be random.
AFAIK, Android is using 16-bit PCM, which has a SQNR of 96dB. This is the same performance as the CD Audio standard. A SNR of 110dB wouldn't be bad for pro-audio equipment.
In practice, audio quality is rarely a headline feature of phones and most get nowhere near this. Most users use crappy headphones or the on-board speaker of their phone for voice calls and won't notice the difference. It's an obvious corner to cut from both a cost and power budget point of view for a phone manufacturer.
Additionally, good digital audio design is a black-art. Factors such as decoupling of digital signals from ground and physical proximity of analogue components come into play. You find that in tear-downs of Apple kit, they often place the codec right next to the headphone jack, and away from the main board of the system. Again, other cost-conscious manufactures don't do this, and it'll degrade the dynamic range of the system.
In order to get meaningful measurements from the audio input you will need to disable both automatic gain control (AGC) and probably the HFP (used to remove DC bias, and often set with Fc > 100Hz for voice calls).
If your intention is to record absolute SPL, you will need to calibrate the audio system of the device to a set-point. There is no standardisation of this between manufacturers (or even devices from any given manufacturer). Unless you fancy doing this for the devices on the market (of which there are a lot), you'll never provide universally accurate measurements.
I am developing an android application in which I have to record an audio from an android phone and find the power of a specific frequency using Goertzel algorithm. Using that power value, I am making some decisions regarding some secret messages sent through the audio.
In order for this application to be used in a variety of android phones, I need to make sure that the microphone gains of all the phones are the same. But unfortunately, different phones have different gains.
(Sony phones have very small gains and Samsung, HTC phones have very large gains). Is there a way to set a common gain to the microphones through android?
One other option is, I can record the audio to the full length and normalize it. However, I cannot do this because, I am doing this processing in real time, i.e. I have to do the processing for each and every frame received from the audiorecorder object and calculate the power value, the app cannot wait until the end of the audio to decide the message.
So, if possible, please suggest me some methods I can try to overcome this.
Hello I was wondering if using the android tone generator class would it be possible to create a tone in one device and listen for this same tone in another device. If this is possible I do have a few other questions.
Taking backround noise into consideration is it possible to listen for only this specific tone?
Would this process be resource intensive?
Could I use a tone that would be inaudable to the human ear or close to it?
Lastly could I use a tone that could only be heard with a couple of feet from the sending device?
Thanks very much for yer time guys and girls :)
Edit >
Thanks For adding the audio processing tag sabastian. Much better discription.
It would be CPU intensive, yes.
The way to it is quite simple: you need a permanent recorder which puts the received data into a FFT (fast fourier transform). FFT basically does one thing: splits the audio into a frequency/power-scale. With this "background noise cleaned" result you can check things like "was there a tone with 1000Hz playing for at least 2 seconds" - and act accordingly.
There is a reasonable speed FFT implementation here: http://www.badlogicgames.com/wordpress/?p=449
FFT can also be used (actually, IS used) for detection of dualtone dialing (DTMF) - 2 frequencies at same time is much better than just using one (as the error rate drop significantly and you can go to shorter duration for the tone sending/detecting).
"Inaudible" won't be possible, as (a) the speaker can not produce such sounds (b) you are limited in sampling rate - so also limited in both producing and recording such high frequencies.
"couple of feet" will be naturally imposed (not very loud speaker, not very good microphone).
Have a look at this other question: "Android: Need to record mic input". I think you can modify that for your task, then with sound bytes you can have filtering or FFT.
Hope it helps
I'm trying to build a gadget that detects pistol shots using Android. It's a part of a training aid for pistol shooters that tells how the shots are distributed in time and I use a HTC Tattoo for testing.
I use the MediaRecorder and its getMaxAmplitude method to get the highest amplitude during the last 1/100 s but it does not work as expected; speech gives me values from getMaxAmplitude in the range from 0 to about 25000 while the pistol shots (or shouting!) only reaches about 15000. With a sampling frequency of 8kHz there should be some samples with considerably high level.
Anyone who knows how these things work? Are there filters that are applied before registering the max amplitude. If so, is it hardware or software?
Thanks,
/George
It seems there's an AGC (Automatic Gain Control) filter in place. You should also be able to identify the shot by its frequency characteristics. I would expect it to show up across most of the audible spectrum, but get a spectrum analyzer (there are a few on the app market, like SpectralView) and try identifying the event by its frequency "signature" and amplitude. If you clap your hands what do you get for max amplitude? You could also try covering the phone with something to muffle the sound like a few layers of cloth
It seems like AGC is in the media recorder. When I use AudioRecord I can detect shots using the amplitude even though it sometimes reacts on sounds other than shots. This is not a problem since the shooter usually doesn't make any other noise while shooting.
But I will do some FFT too to get it perfect :-)
Sounds like you figured out your agc problem. One further suggestion: I'm not sure the FFT is the right tool for the job. You might have better detection and lower CPU use with a sliding power estimator.
e.g.
signal => square => moving average => peak detection
All of the above can be implemented very efficiently using fixed point math, which fits well with mobile android platforms.
You can find more info by searching for "Parseval's Theorem" and "CIC filter" (cascaded integrator comb)
Sorry for the late response; I didn't see this question until I started searching for a different problem...
I have started an application to do what I think you're attempting. It's an audio-based lap timer (button to start/stop recording, and loud audio noises for lap setting). It' not finished, but might provide you with a decent base to get started.
Right now, it allows you to monitor the signal volume coming from the mic, and set the ambient noise amount. It's also using the new BSD license, so feel free to check out the code here: http://code.google.com/p/audio-timer/. It's set up to use the 1.5 API to include as many devices as possible.
It's not finished, in that it has two main issues:
The audio capture doesn't currently work for emulated devices because of the unsupported frequency requested
The timer functionality doesn't work yet - was focusing on getting the audio capture first.
I'm looking into the frequency support, but Android doesn't seem to have a way to find out which frequencies are supported without trial and error per-device.
I also have on my local dev machine some extra code to create a layout for the listview items to display "lap" information. Got sidetracked by the frequency problem though. But since the display and audio capture are pretty much done, using the system time to fill in the display values for timing information should be relatively straightforward, and then it shouldn't be too difficult to add the ability to export the data table to a CSV on the SD card.
Let me know if you want to join this project, or if you have any questions.