[Nexus 5 Android Development] chdloc:
New release (fix + aMGC v0.3)

Update 01/27/2015: modified the mixer_paths.xml file to fix the bug described here. Thanks [MENTION=4136633]marquimsp[/MENTION] !

The updated archive is called camcorder_audio_fix_plus_stereo_playback_LRX22C_v2_1.tar.gz

The main new feature of this release is that -- in combination with aMGC -- camcorder recordings are significantly more robust to

high-level, low-frequency sounds as described in the "Gory details" section below.

The attached archive, camcorder_audio_fix_plus_stereo_playback_LRX22C_v2.tar.gz, contains all files required to run the new

camcorder audio quality fix as well as the ones required to run aMGC v0.3.

Changelog (compared to camcorder_audio_fix_plus_stereo_playback_LRX22C_v1.tar.gz and aMGC v0.2

audio.primary.msm8974.so (audio HAL):

new device identifier used for the camcorder device. See "Gory details" section below for an explanation.

libaudioflinger.so:

the microphone level(s) are now calculated and reported to logcat as real RMS values (200ms average and peak levels)

mixer_paths.xml:

added a high-pass filter (150 Hz cut-off frequency) to the "speaker" device in an attempt to avoid distortion by keeping the

codec to produce signals that the loudspeaker(s) cannot deal with anyway.

added some entries in the "camcorder-stereo" section to mute unused signal paths to avoid cross-talk. Not sure it really helps,

but it does not hurt, either.

reduced the default DEC gain by 6 dB (97 down from 103).

added comments throughout the file

aMGC:

takes advantage of the fact that true RMS values are reported by libaudioflinger and considers the peak values for UI feedback.

now supports an excellent third-part camcorder, i.e. "Cinema FV-5". One thing I really don't like about the Google camcorder app

is that it keeps refocussing even when it appears unnecessary, thereby causing the video to be jittery.

Cinema FV-5 does not seem to suffer from this issue and allows much more granular camcorder control.

Gory details

Up until now, the device identifier used for camcorder recordings in the audio HAL, i.e. audio.primary.msm8974.so, has been selected

as "SND_DEVICE_IN_VOICE_REC_MIC" (while stock uses the "CAMCORDER" device identifier with disastrous quality consequences).

Many people have been observing that the Nexus 5 is unable to produce any useable recordings in loud acoustic environments, in particular

club or concert hall settings. After spending a lot of time doing detective work, I found that the problem can be traced to a high-pass filter (HPF)

being active in either the codec itself (WCD9320) or the main chipset (MSM8974) while most available device identifiers are used, including

"CAMCORDER" and "SND_DEVICE_IN_VOICE_REC_MIC". I'm suspecting two problems with this HPF. One, I think that the HPF itself may be causing

distortions. Second, by filtering out low frequencies, the microphone level estimate that I'm performing inside the audioflinger service is biased in that it

cannot take into consideration the low frequencies that actually hit the analog-to-digital converter, which will eventually cause it to clip.

I found that the "ACDB_ID_VOICE_DMIC_EF_TMUS" identifier in the audio HAL disables the HPF filter. Now the level estimate that is being used by

aMGC is bias-less. Clipping can be properly detected and action can be taken with the aMGC UI to appropriately lower the microphone gain as needed.

An explanation why low-frequency clipping is much worse than clipping at higher frequencies:

In general, clipping (when a signal exceeds full-scale representation of a digital system) causes the introduction of even-order harmonics.

Assume you want to record a 50 Hz sinusoidal signal. Clipping of that signal will cause the recording to not only include a 50 Hz tone (0-th order harmonic),

but also a 150 Hz tone (2-nd order harmonic), a 250 Hz tone (4-th order harmonic), etc. In all, more than a hundred additional tones will show up in your

recording, albeit at progressively lower levels than the 0-th order harmonic. That original pure sine wave now sounds more like a "rectangular wave".

Imagine what happens when a more complex low-frequency signal is getting clipped. The recording is ruined.

On the other hand, a clipped 1000 Hz sinusoidal signals will "only" produce seven additional harmonics in the frequency range that the Nexus 5 is capable

of recording (approximately less than 16 kHz). Don't get me wrong, clipping is bad no matter the frequency (and a professional avoids clipping like the plague),

but the effect is much more dramatic when clipping is happening at low frequencies.

Detailed installation instructions are listed in the READMEs that can be found in the attached archive. An introduction to aMGC can be found here.

[MENTION=3163883]spacetaxi[/MENTION] will be providing an updated installer shortly. has provided an updated installer