Welcome to XDA

Search to go directly to your device's forum

Register an account

Unlock full posting privileges

Ask a question

No registration required
Post Reply

[MOD] [ROOT] Camcorder Audio Quality Fix with Stereo Recording and Playback Support

OP chdloc

Today, 11:13 AM   |  #541  
myfluxi's Avatar
Recognized Developer
Thanks Meter: 3,680
 
668 posts
Join Date:Joined: Jun 2011
Donate to Me
Quote:
Originally Posted by chdloc

Looks good to me.

A few comments/questions:

  • what is the use-case for "handset-stereo-dmic-ef"?
  • your default gains seem overly hot to me, you will quickly run into clipping/saturation issues.
  • I really like the idea of being able to modify device acdb identifiers via an xml file.
    This means no more messing with the audio HAL required to select a different identifier for the CAMCORDER device.
  • from your mixer_paths.xml file it appears that you are defaulting to stereo recording when the camcorder is being used.
    On hammerhead, there is some structured noise audible in the auxiliary microphone channel (left). I'm not sure where it comes
    from, but it seems louder during a camcorder recording and somewhat softer (and different in nature) during an audio-only
    recording. I did correlate some of the noise to mpdecision as it manipulates the processor cores. I am able to lower the noise somewhat by locking all four cores to 1.19GHz. At this point my best guess is that the analog microphone traces run close to some high-speed data signals that feed into the MSM. Long story short, you may not want to default to stereo recording as some folks may object to the noise.

I am using the codeaurora version [1] of the audio HAL (well, their CM flavor [2] to be exact). handset-stereo-dmic-ef is used by some apps, such as WhatsApp.

Can you push your changes to github? This would make tracking, understanding and cherry-picking much easier. Uploading blobs is confident for the end user, but not for everyone else. You just had to clone the hammerhead devicetree and audio HAL from https://android.googlesource.com/device/lge/hammerhead/ and https://android.googlesource.com/pla...re/qcom/audio/ and probably https://android.googlesource.com/pla...frameworks/av/ as well.

[1] https://www.codeaurora.org/cgit/quic...BF.1.1.1_rb1.8
[2] https://github.com/CyanogenMod/andro...-12.0-caf-8974
The Following User Says Thank You to myfluxi For This Useful Post: [ View ]
Today, 05:29 PM   |  #542  
OP Senior Member
Thanks Meter: 410
 
237 posts
Join Date:Joined: Jul 2010
More
Quote:
Originally Posted by myfluxi

I am using the codeaurora version [1] of the audio HAL (well, their CM flavor [2] to be exact). handset-stereo-dmic-ef is used by some apps, such as WhatsApp.

Can you push your changes to github? This would make tracking, understanding and cherry-picking much easier. Uploading blobs is confident for the end user, but not for everyone else. You just had to clone the hammerhead devicetree and audio HAL from https://android.googlesource.com/device/lge/hammerhead/ and https://android.googlesource.com/pla...re/qcom/audio/ and probably https://android.googlesource.com/pla...frameworks/av/ as well.

[1] https://www.codeaurora.org/cgit/quic...BF.1.1.1_rb1.8
[2] https://github.com/CyanogenMod/andro...-12.0-caf-8974

I'd be happy to share the sources for my camcorder audio mod but I'm sure it won't be accepted, in its current form,
by AOSP (or CM) for the reasons outlined below. Although I wouldn't mind somebody else (AOSP, ideally) maintaining this
fix across future versions of Android...
  • the most fundamental change to improve the audio quality for services that use the "CAMCORDER" device is to modify the acdb identifier
    (from now on called acdb_id) of the SND_DEVICE_IN_CAMCORDER_MIC from 61 (stock) to ACDB_ID_VOICE_DMIC_EF_TMUS (which is 89).
    Why 89? No idea. Only those with proper documentation of the acdb interface will ever be able to find out. Maybe the CAF guys do know?
    When acdb_id=61, overly aggressive noise suppression is applied to the microphone signal. Via trial and error I found that when acdb_id=89,
    noise suppression and a suspect (buggy?) high-pass filter are disabled. This is not a true fix, but only an ugly workaround. This is in
    essence the "simple" version of my fix. BTW, I believe the suspect high-pass filter is the culprit as to why the Nexus 5 and some other Qualcomm
    devices are unable to record even only moderately loud (especially low-frequency) signals. I think the microphone/ADC combination itself is
    quite capable of recording sound pressure levels all the way up to between 120 dB and 130 dB.
  • the "advanced" version of my fix is even more of a hack. The microphones used in our Nexus 5's are pretty noisy, offering only 58 dB of SNR. By
    comparison, I believe the microphones used in the iPhone or other flagship Android devices offer close to 70 dB of SNR. This is a huge
    difference. Due to the high noise floor, I do understand why Google and/or LG enabled noise suppression (after people had been complaining
    about hiss, i.e. white noise) in one of the KitKat updates. However, Google went too far with the noise suppression crank.
    Completely disabling noise suppression may not be the best solution, either. In pursuit of finding a better solution I hacked the invocation
    of webRTC noise suppression algorithm (external/webrtc) into the audioflinger service (Threads.cpp and Effects.cpp) for cases where an (any) app
    requests the "Noise Suppression" effect. In order to keep the impact on libaudioflinger as low as possible I decided to have Threads.cpp communicate
    necessary data to Effects.cpp via (gasp!) global variables. Very ugly and against any coding standard on this planet.
    Also, at this point, this scheme only works for 48 kHz sampling rate as I did not want to introduce additional buffering.
    48 kHz is the standard sampling rate for camcorder recordings and many good audio-only recording apps (like "Easy Voice Recorder Pro") can be
    adjusted in their settings to support this sampling rate. This is good enough for me. However, there may be some apps that are choking on this
    restriction. I personally have not seen any, but I'm guessing that "Cyberion Voice Commander" as mentioned by someone in a previous post may be
    having problems because of the current sampling rate restriction.
    All of this could certainly be improved relatively easily by a seasoned developer like yourself.

Let me know how you would like to proceed.
Last edited by chdloc; Today at 06:15 PM.
The Following User Says Thank You to chdloc For This Useful Post: [ View ]
Post Reply Subscribe to Thread
Previous Thread Next Thread
Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes