C121 slowed down audio in Media Sync recordings

[chumbazoid]

Description

I have two C121 (V1) cameras with the same issue. (Both cameras record to SD cards.)

Issue: Audio is no longer present in recently recorded media saved via HA / Tapo Cameras Control Media Sync.

Audio remains present as normal when streaming and viewing recordings via Tapo app, and when streaming via HA/TCC.

Issue onset seems coincident with update to firmware 1.3.2 Build 250620 Rel.39379n on Aug. 26. However, although both cameras were updated at the same time, the issue did not appear simultaneously in both devices:

• Camera 1: Media Sync recordings have audio through Aug. 26 @ 7:10PM, and no longer as of 7:30PM and going forward.
• Camera 2: Media Sync recordings have audio through Aug. 27 @ 1:15PM (final recording of the day), and no longer as of Aug. 28 @ 8:30AM (first recording of the day) and going forward.

"Record Sound" / "Record Audio" are enabled in the Tapo app and in TCC, respectively. Have tried toggling off then back on.

Have also tried both rebooting and unplugging the cameras, and rebooting the HA machine.

Reproduction Steps

In a Home Assistant system with Tapo Cameras Control Media Sync enabled, go to Media / Tapo: Recordings.

1. Play a recent recording. Video plays as normal but no audio is present, whereas earlier recordings have always had audio.
2. Download a recent recording to local computer and play the .mp4 file in VLC. VLC shows the file has no audio stream (Tools>Codec Information).

Expected behavior

Recordings have audio.

If applicable, add error logs.

No issues reported under standard logging.

Device Firmware

1.3.2 Build 250620 Rel.39379n

Integration Version

7.0.0

Using stream component

Yes

Does camera work via official integrations?

N/A

Camera has all attributes filled out in developer tools

Yes

HASS Environment

Home Assistant OS (bare metal)

Search for similar issues

Yes

Additional information

Thanks for the component and consideration.

[JurajNyiri]

Could you check if the alaw file is being created when recording is being downloaded?
Anything interesting in debug logs when download occurs?

[ycao56]

I have same problem with this firmware. The other C120 with 1.2.2 Build 240905 Rel.41780n firmware has no such issue.

[chumbazoid]

Confirm that downgrade to 1.3.1 Build 250523 Rel.67934n restores audio in Media Sync files. (Downgrading Process of TAPO Cams.)

Still have one camera on the newer firmware. Will seek to address JurajNyiri's questions above as able.

[chumbazoid]

Could you check if the alaw file is being created when recording is being downloaded? Anything interesting in debug logs when download occurs?

Attaching debug logs from each camera as they downloaded a recording. (I disabled one camera while the other was logging.)

"Tapo1"

• Has latest firmware for this camera and is experiencing issue reported above.
• In logs under 'microphone': 'encode_type': 'G711ulaw'
• [Tapo1 1.3.2 Build 250620 Rel.39379n] home-assistant_tapo_control_2025-08-31T02-06-21.989Z.log

"Tapo2"

• Has downgraded firmware and does not experience issue reported above.
• In logs under 'microphone': 'encode_type': 'G711alaw'
• [Tapo2 1.3.1 Build 250707 Rel.72539n] home-assistant_tapo_control_2025-08-31T01-18-58.115Z.log

[chumbazoid]

To add a note of clarification:

JurajNyiri asked "if the alaw file is being created when recording is being downloaded?"

I looked for alaw files being created in the TCC Media Sync directory, but did not see them for either new or old firmware. If they're downloaded to another location for muxing, please advise.

However, I did see in the Debug Logs that the 'encode_type' has changed from ALAW in old firmware to ULAW in new firmware. Perhaps this could be root cause of this issue?

[JurajNyiri]

That must be it, we might need to pass different arguments to muxer.

It's done here - https://github.com/JurajNyiri/pytapo/blob/main/pytapo/media_stream/convert.py

Could you see if you can run https://github.com/JurajNyiri/pytapo/blob/main/experiments/DownloadRecordings.py ? See if changing arguments here https://github.com/JurajNyiri/pytapo/blob/main/pytapo/media_stream/convert.py#L32 helps get the audio stream working again.

[ycao56]

That must be it, we might need to pass different arguments to muxer.

It's done here - https://github.com/JurajNyiri/pytapo/blob/main/pytapo/media_stream/convert.py

Could you see if you can run https://github.com/JurajNyiri/pytapo/blob/main/experiments/DownloadRecordings.py ? See if changing arguments here https://github.com/JurajNyiri/pytapo/blob/main/pytapo/media_stream/convert.py#L32 helps get the audio stream working again.

I gave it try but it didn't work. The issue is downloaded audio file is empty. It is already too late to do it in convert.py.

Unsure how the audio is downloaded from tapo. I think that's where the change should be made to download the audio file properly.

[basrieter]

I experience the same with my D235. No audio from the synced media. There is audio in the Tapo App though

[JurajNyiri]

Please test with https://github.com/JurajNyiri/HomeAssistant-Tapo-Control/releases/tag/7.0.6 and let me know if it works.

I do not own camera that would use mulaw for audio so could not test.

[chumbazoid]

Thank you. Audio is now present in Media Sync recordings, but is slowed down to half-speed.

My observations with two C121s, one on latest firmware and one on old firmware:

- "Camera 1": Firmware: 1.4.1 Build 250910 Rel.58576n (latest FW)

• In Media Sync recordings (HATC 7.07), audio is slowed down to half-speed. Audio sample rate is 8KHz.
• In recordings downloaded directly from Tapo app, audio plays fine. Audio sample rate is 32KHz.
• Issue with Media Sync recordings is resolved by manually adjusting audio sample rate to 16KHz in audio editing software (Sound Forge).

- "Camera 2": Firmware: 1.3.1 Build 250707 Rel.72539n

• In Media Sync recordings, audio plays fine. Audio sample rate is 8KHz.
• In recordings downloaded directly from Tapo app, audio plays fine. Audio sample rate is 16KHz.

Looks like the μ-law audio encoding in newer firmware has double the sample rate from previous encoding method, and HATC has not yet accounted for this change.

I'd reopen this issue but don't have permission to do so.

Appreciate the effort on this and on HATC overall.

[JurajNyiri]

... one could say we are half way there!

Apologies for corny joke. I will take a look at this soon.