Live TS silent on AirPlay speakers output (tvOS), VOD and HDMI fine

[Simpendaal]

What happened?

A user of our tvOS app reports that live MPEG-TS channels played through AetherEngine are completely silent when the Apple TV audio output is set to AirPlay speakers. Video plays normally, the audio tracks are listed and selectable, but no sound comes out on any of them, stereo included. On the same AirPlay speakers, VOD content through AetherEngine does have audio, and the same live channels through our FFmpeg based fallback engine (KSPlayer) also have audio, so the AirPlay route itself works. Over the built in HDMI output live audio through AetherEngine is fine. We expected the live session to follow the current audio route like the VOD session does. On our side the AVAudioSession setup is identical for both engines and for live and VOD, and we do not touch the audio path otherwise, so we suspect the live playback path does not follow the AirPlay audio route. We have not been able to reproduce it ourselves yet, so treat this as a user report with the facts we could verify.

Steps to reproduce

On Apple TV, set the audio output to AirPlay speakers (Settings > Video and Audio > Audio Output).
Load a live MPEG-TS URL with our usual live LoadOptions (liveJoinProfile .fastZap, liveBlockingReload false, suppressDisplayCriteria true).
Observe: video plays, audio tracks are listed, no sound on any track. Switching tracks does not help.
Set the audio output back to HDMI: sound is fine. Load a VOD item over the same AirPlay speakers: sound is fine.

AetherEngine version or commit SHA

6.29.0 (d146f05)

Host app

Custom / my own integration

Platform

tvOS

OS version

26.6

Device / chip

Apple TV 4K

Playback path

Not sure / not a playback bug

Source media (for playback bugs)

Live MPEG-TS over HTTP (Xtream), H.264 video (stream type 0x1b), three audio streams in this order: PID 257 MPEG-1 Layer II stereo, language dut; PID 258 AC-3 5.1 (stream type 0x81, AC-3 registration descriptor), language dut; PID 259 MPEG-1 Layer II stereo, language dut, spoken subtitles. All three silent over AirPlay. Stream URL can be shared privately.

Error codes / log lines

Anything else

No response

[superuser404notfound]

Thanks, the PMT breakdown is what made this measurable without the stream.

What the engine actually hands AVPlayer for that PMT

I rebuilt the shape locally (MPEG-TS, H.264 + MPEG-1 Layer II stereo 48 kHz + AC-3 5.1 carrying an AC-3 registration descriptor + a second MPEG-1 Layer II stereo), ran it through the live path (aetherctl live --fast-zap --realtime) and read the served init.mp4 back with ffprobe:

source track	what reaches AVPlayer
MPEG-1 Layer II stereo (PID 257 / 259)	ec-3, E-AC-3 stereo at 256 kbps (AudioBridge, surroundCompat)
AC-3 5.1 (PID 258)	ac-3, 6 channels, stream-copied

MP2 is not fMP4-legal, so it always goes through the bridge, and the default audioBridgeMode is .surroundCompat, whose encoder is E-AC-3. On that PMT av_find_best_stream picks the AC-3 5.1, so an untouched session sits on ac-3 6ch. Same result on the VOD path, so this is not live-specific: it is what the muxer does with those two codecs.

So all three selectable tracks reach AVPlayer as a Dolby bitstream. "No sound on any of them, stereo included" therefore does not rule out a codec-versus-route axis, because by the time the player sees it, the stereo track is not stereo PCM or AAC.

What that does not settle

The obvious next step ("an AirPlay route cannot render Dolby, hence silence") is not safe here. #34 measured the analogous case on tvOS: E-AC-3 + JOC over Bluetooth A2DP, a route with no passthrough either, and AVPlayer downmixed it natively. That measurement is exactly why the route-dependent bridge was removed. So the codec axis needs evidence, not inference.

One more thing to pin down first: VOD and live take the same path in this engine. VideoRoute.derive sends every .native session to .loopback unless nativeRemoteHLS is set, so a VOD MP4 is demuxed, remuxed to fMP4 by the same muxer and served by the same loopback server as the live channel. If the VOD titles that do have sound on those speakers are AAC, then "live versus VOD" is not the axis at all, mp4a.40.2 versus ec-3 / ac-3 is.

Three tests, cheapest first

1. No build. Play a VOD title whose audio track is AC-3 or E-AC-3 over the same AirPlay speakers. Silent as well → the live path is exonerated and the axis is the codec into that route. Has sound → the live path is implicated and the next two matter.
2. No build. On the silent live channel, seek back into the timeshift window, away from the live edge. The served live playlist declares EXT-X-SERVER-CONTROL:HOLD-BACK at 3 x TARGETDURATION (6 s on a fastZap session at TD=2 on my fixture), and an AirPlay route adds output latency that HDMI does not. If audio appears once playback sits behind the edge, the axis is the lead, not the codec.
3. One build. Set LoadOptions.audioBridgeMode = .lossless for the live load and select one of the MPEG-1 Layer II tracks. That track then arrives as FLAC, which AVPlayer decodes to LPCM instead of handing a Dolby bitstream on. Sound returns → the bitstream is the problem. This is a probe rather than a fix: it does nothing for the AC-3 track, which is stream-copied either way.

The log lines that decide it

Captured through EngineLog.handler, same channel twice, once over HDMI and once over AirPlay speakers, then diffed:

• [HLSVideoEngine] audio: ..., the routing decision and the bridge mode actually used.
• [NativeAVPlayerHost] #N audioRoute output=... preferred=... max=... ports=[...], emitted twice per session, at readyToPlay and again at settled.
• [NativeAVPlayerHost] #N item.audioTrack codec='...' enabled=... sr=... ch=... layoutTag=... at readyToPlay. This is the one that matters most: if the audio track is missing from item.tracks, or comes back enabled=false on the AirPlay run while the HDMI run has it enabled, then AVPlayer refused it at item level and the two runs part company inside AVFoundation, not in anything the engine can reach from the muxer side.
• any WARNING: line from NativeAVPlayerHost.

Three questions

• Which receiver holds the route: HomePod, a third party AirPlay 2 speaker, a soundbar, an AirPort Express? A receiver that only accepts 44.1 kHz stereo and one that accepts Dolby are different cases.
• Does the live LoadOptions keep the default audioBridgeMode, or does it already set .lossless? The table above assumes the default.
• Did live audio over those speakers ever work, and on which engine version? Worth asking even though the answer is likely "never": Live MPEG-TS E-AC-3 JOC: fMP4 probe rejects stream-copy (TS codec_tag), Atmos falls back to 5.1 bridge #382 changed Dolby-out-of-MPEG-TS stream-copy in 6.29.0, but it was measured at the time that AC-3 and ADTS-AAC from TS were not affected, and MP2 has always gone through the bridge. So for this exact PMT nothing moved in 6.29.0, and a "worked on 6.28.x" would be a finding in itself.

[superuser404notfound]

A fourth discriminator became available today, and it rides along with any build rather than costing one of its own.

6.31.0 instruments AudioBridge, which is the subsystem the MP2 track passes through on the way to becoming the ec-3 that reaches AVPlayer. Until now it had no observable at all: everything between a source packet and an encoded frame ended in a silent return, so the bridge was invisible between the demuxer and the player, and the only evidence either way was what AVPlayer had already built.

Two things that changes here, neither of which was checkable before:

• A bridge that emits nothing for the whole first segment now ends the session with a named error, so if a run reaches readyToPlay with the tracks listed, the bridge produced audio at least that far. That was previously an inference; it is now a fact the log states.
• A bridge that emits for the first segment and then stops is the one shape that looks exactly like this report: the moov is written, the ec-3 track exists and is selectable, and every later fragment is video-only, so playback continues in silence with no error anywhere. That shape had no line of its own. It now does, one loud [AudioBridge] ERROR: AE#396 ... and per-arm counters.

I do not expect it to be the answer. The bridge is route-blind (route-dependent bridging was removed after #34 measured E-AC-3 over A2DP), so it cannot be silent on AirPlay and healthy on HDMI in the same build. But that is an argument, and the counters are a measurement: a HDMI run and an AirPlay run of the same channel on 6.31.0 either show identical bridge output, which retires the bridge entirely and moves the split inside AVFoundation, or they do not, which would be a much more interesting result than the one I am expecting.

The three from the previous comment are still the cheaper ones, especially the first, since a VOD title with AC-3 or E-AC-3 over the same speakers needs no build at all.

[Simpendaal]

Thanks, that reframes it usefully. Answers to your three questions: our live LoadOptions keep the default audioBridgeMode, we never set .lossless; the receiver type and the "did it ever work" question are out with the user, I will report back. We do not capture EngineLog yet, I will add a handler so we can give you the HDMI versus AirPlay diff. We will start with your first test (VOD title with AC-3 or E-AC-3 over the same speakers) since it needs no build.

[Simpendaal]

Update from the user, and it points at your codec axis. The receiver is a Belkin Soundform Connect (AirPlay 2 to optical/3.5 mm adapter), not a HomePod. Today the same channels had sound through AetherEngine on those speakers, and the difference is which track the session started on: on the silent runs our overlay showed the engine on the stereo track (MPEG-1 Layer II, so E-AC-3 out of the bridge in your table), on today's working run it showed 5.1 (the AC-3 track, stream-copied). So on this receiver the bridged E-AC-3 stereo appears silent while the stream-copied AC-3 5.1 plays. He also reported the second MP2 track (spoken subtitles) as silent, which fits. He was not seeking into the timeshift window in either case. Which track av_find_best_stream lands on seems to vary between sessions on this PMT, which is why it looked intermittent to him. We have EngineLog wired into our diagnostics report now, so a HDMI versus AirPlay diff on 6.31.0 is possible once we ship a build; tell me if you still want it given the above, or if a .lossless probe run is more useful.

[superuser404notfound]

That A/B is the discriminator, thanks. It splits exactly where the rebuilt fixture said the delivered codecs split, and it was enough to change something in the engine.

What it settles

The axis is ac-3 versus ec-3 into that receiver. Both of the tracks your user heard nothing on are the MP2 tracks, which are the two that leave the bridge as E-AC-3; the one he did hear is the AC-3 5.1, which is stream-copied and never touches the bridge. Live versus VOD is out (they share the muxer and the loopback server), and "the stereo track was silent too" is out as an argument, because that track is not stereo PCM by the time AVPlayer sees it.

What I changed

.surroundCompat was picking its encoder from the mode alone. A mode is not an encoder: that mode exists to carry SURROUND across a route that cannot take multichannel LPCM, and a source of two channels or fewer has no surround to carry. Its E-AC-3 output therefore bought nothing on such a source and cost twice: 256 kbps lossy where the FLAC encoder in the same build is lossless, and a Dolby bitstream handed to every output route, including the ones that can only pass one through rather than decode it.

On fix/ae395-stereo-bridge-encoder (924fda4d) the bridge resolves its encoder from the mode AND the source's channel count: E-AC-3 above two channels, FLAC at or below. Measured against the same fixture:

source track	before	after
MP2 stereo	ec-3, 2 ch, 256 kbps	fLaC, 2 ch, VBR
AC-3 5.1	ac-3, stream-copy	unchanged
5.1 PCM (control)	ec-3, 6 ch, 768 kbps	unchanged

The tapped loopback PCM is identical in level before and after (mean -21.1 dB either way), so this changes the carriage and not the content. .lossless is untouched. It is route-blind by construction: the input is the source's channel count, never the current output route, because #34 measured the route-dependent version wrong (AVPlayer downmixes E-AC-3+JOC natively over A2DP) and it was removed then.

That retires your third test as a build of its own. .lossless on the MP2 track is what this change now does by default, so either set audioBridgeMode = .lossless for that load today if you want the answer early, or take the default when it ships.

What it does not settle, and the one run I would still like

"HDMI was fine" may itself have been an AC-3 session. You have just told me the track a session lands on varies, and nothing in the earlier rounds pinned the track for the HDMI arm. So the report is still consistent with two different causes:

1. the route cannot render the bridged E-AC-3 stereo, which is what the change above addresses, or
2. the bridge stops emitting after the first segment, which is silent on every route, and the HDMI runs that worked were AC-3 runs.

One pair separates them and it rides along with the build you were going to ship anyway: same channel, stereo track explicitly selected, once over HDMI and once over the AirPlay speakers, on 6.31.0. Sound on HDMI and none on AirPlay puts the split at the route and makes the change the right fix. Silent on HDMI too puts it in the bridge instead, and 6.31.0's per-arm counters will name which step stopped. The second outcome is one my change would not fix, which is why I would rather measure it than assume it away.

The lines to diff: [AudioBridge] ..., [HLSVideoEngine] audio: ..., [NativeAVPlayerHost] #N item.audioTrack codec='...' enabled=... and [NativeAVPlayerHost] #N audioRoute output=... ports=[...].

The track that varies between sessions

A separate finding, and probably the whole of the intermittency your user described. Two mechanisms can produce it and they need different fixes:

1. av_find_best_stream skips any stream whose codecpar the probe left empty. On a live MPEG-TS a probe that bails early can end before the AC-3 PID is identified, and the MP2 tracks, which are identified, then win the pick. I could not reproduce the variation here: over a loopback origin the AC-3 5.1 won 4 of 4 runs. Loopback is the one origin that cannot starve a probe, so that is a null result and not a counter-argument.
2. A host-side track preference arriving as audioSourceStreamIndexOverride. If that is in play the engine says so: [HLSVideoEngine] audio: override accepted, sourceStreamIndex=N (auto would have picked M).

Your EngineLog capture separates those on the same run as the diff above. If it is the first one I will track it separately, because a default audio track that depends on probe timing is worth fixing whatever comes of this issue.

Thanks for pinning down the receiver and running the A/B. That is what made the codec axis measurable rather than arguable.

[Simpendaal]

We do not use audioSourceStreamIndexOverride and never select a track before the session starts; the host only calls selectAudioTrack afterwards, on a language preference or when the engine landed on the spoken-subtitles track, and on this channel both dut tracks tie so no switch happens. One host-side detail that may explain the varying default track: our guide preview sessions load with a smaller probe (probesize 2 MB, maxAnalyzeDuration 1.5 s) than fullscreen sessions (8 MB, 3 s), and a preview session can be promoted to fullscreen. That is exactly the shape where a probe can bail before the AC-3 PID is identified and the MP2 tracks win. Hypothesis, not measured yet; the EngineLog capture should show it. We are already on 6.31.0 and have EngineLog wired into our diagnostics report, so the next build goes to the user with the request you asked for: same channel, stereo track selected explicitly, once over HDMI and once over the Belkin, and I will post the diff of the AudioBridge, HLSVideoEngine audio, item.audioTrack and audioRoute lines here. We keep the default audioBridgeMode for now so the measurement stays clean, and will move to the release with the FLAC change once it ships.

[superuser404notfound]

Shipped as 6.32.0, so a .lossless probe build is no longer needed to see what the FLAC carriage does on that receiver: a bridged source of two channels or fewer now takes it by default under .surroundCompat. Both MP2 tracks on that PMT are in that class.

The issue stays open, because the release does not settle which of the two causes it is. The measurement that does is still the one above: same channel, stereo track explicitly selected, once over HDMI and once over the AirPlay speakers. If you take 6.32.0 straight to the user, the equivalent read is simply whether the MP2 tracks now have sound on those speakers; if they do, the route was the axis, and if they do not, the bridge is and the 6.31.0 counters in the same log will name the stage.