GeezerVison

Adds speaker-only talkback for Tapo cameras, the first step proposed in #1763.

camera = dev.modules[Module.Camera]
await camera.play_audio(audio_stream)  # AsyncIterable[bytes]

audio_stream must already be encoded as G.711 A-law (PCMA), 8 kHz, mono, raw bytes (8000 bytes = 1 s).
python-kasa does no decoding, resampling or transcoding; the caller (e.g. Home Assistant with FFmpeg)
produces the camera-compatible audio. There are no new dependencies.

The call returns when the input is exhausted and its playback time has elapsed. Cancelling the task stops
playback and closes the session. Only one playback per camera can be active; a second call raises
KasaException. The camera never acknowledges playback, so returning does not guarantee the audio was heard.

Implementation

The camera media server is a second connection, separate from the management API, so it is not a
BaseTransport:

• kasa/smartcam/media.py: _TalkSession
  • opens TCP 8800 and sends POST /stream
  • HTTP Digest auth: user admin, password = SHA-256 or MD5 (uppercase hex) of the cloud password, chosen
    from the challenge's encrypt_type
  • opens a talk session (mode: aec)
  • sends multipart audio/mp2t parts with X-If-Encrypt: 0 and X-Session-Id
• kasa/smartcam/_mpegts.py: the minimal MPEG-TS writer needed here (PAT, PMT, PES with PTS; stream type
  0x90, PID 0x100)
• Camera.play_audio: lives next to stream_rtsp_url and onvif_url and reuses the module's credential
  handling. It rejects hub children, devices without the audio component, and missing credentials
  (AuthenticationError).

Notes on the sending side:

• Pacing is mandatory: audio sent faster than real time is not played. Audio goes out in 20 ms frames on an
  absolute monotonic schedule, independent of the caller's chunk sizes. The schedule restarts instead of
  bursting if the producer stalls.
• Writes are awaited with drain() and there is no internal queue, so the producer is consumed at playback
  rate.
• On cancellation or error the connection is aborted; after a normal end it is closed gracefully.

The protocol follows go2rtc's pkg/tapo and was
checked against a C200. Microphone/preview, codec negotiation and other codecs are out of scope.

Tests

Tests are deterministic, with no sockets and a fake clock. They cover:

• the MPEG-TS writer: byte layout, CRC, continuity counters, adaptation-field stuffing
• Digest auth: MD5 and SHA-256, unsupported challenges, auth failure
• talk-session setup and error responses
• the exact multipart wire format
• pacing for chunk sizes from 1 to 16384 B, producer stalls, backpressure
• cancellation during pacing and during writes, producer errors, connection reset, timeouts
• the Camera guards and concurrency

The generated stream was also checked with ffprobe.

Hardware validation

Tested on a Tapo C200 (HW 1.0, FW 1.3.17 Build 260112) over Wi-Fi (RSSI -55 dBm), client wired.
Audio was raw PCMA 8 kHz mono, generated tones and a macOS TTS sample converted with
ffmpeg -ar 8000 -ac 1 -f alaw.

Observations:

• Closing the connection frees the talk session. Opening a new session takes ~0.4 s, or ~0.85 s right after a
  previous one ended.
• Sender timing is exact: parts leave every 19–21 ms, writes never block, nothing is queued.
• Known limitation: light, occasional choppiness, much worse while live view is active. It correlates with
  camera-side TCP latency spikes (median RTT ~10 ms, peaks ~330–380 ms, no retransmissions; ~4 spikes per
  10 s idle, ~9 with live view).
• Sending ahead of real time did not help. In a blind A/B with a 600 ms lead it sounded worse (the initial
  burst caused retransmissions), so strict real-time pacing is kept.

@rytilahti I haven't tested on a TC65 yet. If you can try it with yours, that would help; a small test script
is available on request.

Part of #1763.

Development of this PR was driven by Claude AI. I reviewed the changes and validated them on the hardware above.