Mic not working after a custom ROM flash: pulling the audio config from stock firmware

After installing LineageOS 20 on my Lenovo TB-8703N, everything worked except the microphone. Speaker output was fine. Headphone jack was fine. Recording apps ran without crashing — they just captured silence.

It is fixed now. But the way I got there was slow and avoidable, and the wrong assumption I made at the start is one I see people make constantly.

The mistake: reflashing the same ROM, over and over

My first assumption was that I had installed something wrong. So I did what felt logical: wiped, reflashed LineageOS 20, and tested again. Silence. So I did it again. And again.

I lost a lot of time this way, and the reasoning behind it was flawed in a way worth spelling out. If the problem is a configuration file that ships inside the ROM, reflashing that ROM reinstalls the exact same broken configuration. There is no version of "flash it more carefully" that produces a different config file. The install was never the problem — the build was.

Confirming the hardware was fine

Before going deeper into software, I flashed back to stock firmware and tested the microphone there. It recorded normally.

That single test is worth doing early, and I would recommend it before any config work. It splits the problem cleanly in half: mic works on stock means the hardware is intact and you have a software problem. Mic dead on stock too means you are looking at a physical fault — a disconnected flex cable, a damaged mic module, or corrosion — and no amount of ROM editing will help.

Why the mic breaks when everything else works

This asymmetry confuses people, and understanding it points straight at the cause.

Audio playback on Qualcomm devices is relatively forgiving. Capture is not. The input path depends on calibration data specific to the exact hardware — which physical microphone is wired to which codec input, what gain to apply, which processing profile to load for a phone call versus a voice memo versus camera recording.

That mapping lives in the audio HAL (Hardware Abstraction Layer), and the calibration values it points to live in the ACDB — the Audio Calibration Database. Each audio path gets an ACDB ID, and that ID is how the system finds the right calibration data for that route.

Get an ACDB ID wrong, or leave a route out of the configuration entirely, and the system does not error out. It confidently loads whatever it was pointed at and records nothing. No crash, no obvious log entry — just silence.

What was actually wrong

The LineageOS build had bugs in its audio configuration. Parts of the audio path definitions were simply missing — the routing the microphone needed was not fully described in the ROM's config.

On MSM8953 devices the relevant file is audio_platform_info_intcodec.xml, usually under /vendor/etc/. The intcodec suffix matters: it refers to the internal codec configuration, as opposed to the external codec variants some devices use. This file maps device names to ACDB IDs — entries for the handset mic, the headset mic, the back mic, and the various processing modes.

This is a normal thing to go wrong on unofficial ports for older devices. Those builds are usually assembled against generic Qualcomm reference firmware for the chipset rather than the OEM's own vendor blobs, because the OEM firmware is often not available in a form you can build against. For display, storage, Wi-Fi and audio playback, the reference configuration is close enough. For audio capture it is not — Lenovo's firmware carries values calibrated for the microphones actually soldered into this tablet, while generic MSM8953 values were calibrated for a Qualcomm development board.

The fix: take the audio config from stock firmware

The solution was to stop trying to make the ROM's configuration work and instead take the correct one from the source that definitely had it — Lenovo's own stock firmware, where the mic demonstrably worked.

I extracted the audio path files from the stock firmware image and installed them onto the LineageOS system. The microphone worked immediately.

The broad shape of it, if you want to attempt the same thing:

1. Get the stock firmware package for your exact model. Wrong variant, wrong calibration values — you would just be swapping one mismatch for another.
2. Unpack it to reach the system or vendor image. Depending on how the package is built this is a matter of extracting the archive and then unpacking the image inside it. Qualcomm packages, payload-based packages and raw images all need slightly different handling.
3. Find the audio configuration. On MSM8953 the file you want is audio_platform_info_intcodec.xml, usually under /vendor/etc/. It is worth pulling mixer_paths.xml from the same place while you are there.
4. Copy it onto the running system and set permissions so the audio HAL can read it. Files it cannot read behave exactly like files that are missing.
5. Reboot and test each mic path — a voice memo, a camera video, a call.

If this does not fix it for you

Things worth checking if the same approach leaves you with silence:

1. Check mixer_paths.xml too. The ACDB mapping is only half the picture — mixer paths define which codec routes are actually enabled for capture. A correct ACDB ID on a disabled route still gives you silence.
2. Read the HAL logs during a recording attempt. Filter logcat for the audio HAL while starting a recorder. It usually names the device and ACDB ID it selected, which tells you immediately whether the wrong path is being chosen.
3. Test each mic path separately. A voice memo, a camera video and a voice call take different routes. If one works and the others do not, only some mappings are wrong — which narrows the search enormously.
4. Confirm your stock firmware matches your variant. Pulling audio config from firmware for a different device gives you a different set of wrong values.
5. Check file permissions after copying. Files under /vendor/etc/ that the audio HAL cannot read behave exactly like files that are missing.

Frequently asked questions

Will reflashing the ROM fix a dead microphone?

No, if the cause is a configuration file inside the ROM. Reflashing installs the same file again. This is exactly the loop I got stuck in.

Is my microphone hardware broken?

Test on stock firmware before concluding that. If the mic records on stock and not on the custom ROM, the hardware is fine and the problem is configuration.

Can I copy audio files from stock into a custom ROM?

Yes — that is what fixed it here. It is not guaranteed on every device, because the stock and custom audio HALs may expect different formats or Android versions, so back up first and treat it as an experiment.

Does this affect every custom ROM on older Qualcomm devices?

Not every one, but it is a common pattern on unofficial builds for devices whose OEM vendor blobs were never properly available.

Where do I get stock firmware to extract from?

You need the firmware package for your exact model. If you cannot find one for the TB-8703 series, get in touch and I will point you toward where to look.