LiveTV Buffering Pauses due to 'audiounderrun' - HDHR Prime Source

Channels Apple TV
#49

Does Settings > Playback > Advanced > Audio Driver: Legacy make any difference

#50

That was going to be my next test. I am going to try that and will keep and eye on the logs. Getting closer to nailing this down. Thanks for all the help!

1 Like
#51

This! Everything runs much better when I use legacy. Default audio causes stuttering audio and requires pausing playback or changing channels to stop it.

#52

I wanted to confirm that even with "Use Legacy Audio Driver" turned ON, a full Apple TV reboot, and stereo output selected (with Surround OFF), Channels is still using the default audiounit driver, not the legacy one.

From the logs:

[ao] v: Trying audio driver 'avplayer'
[ao] v: Trying audio driver 'audiounit'
...
[cplayer] info: AO: [audiounit] 48000Hz stereo 2ch floatp

This shows that while avplayer is attempted, the system ends up selecting audiounit. I’ve confirmed this behavior across multiple ATV setups. Just looking for guidance on why the legacy driver isn’t sticking or being used even with the setting enabled and everything rebooted clean.

Thanks!

#53

@eric

Noticed a discrepancy I wanted to highlight: the log shows [ao/audiounit] being used with passthrough enabled, which I believe is the newer audio backend. However, the “Show Stats” overlay in the app still reports “Legacy” under Audio Driver. Not sure if that’s just a labeling issue in the UI or if the client is falling back to legacy but not logging it clearly — figured it was worth flagging in case it helps track down the underruns.

Also, I am trying to get up to speed on all of this as quickly as I can, so I apologize if I am misunderstanding what the logs are actually saying here.

All that said, it does seem that the issue persists with legacy mode enabled.

2025-03-21 09:33:15.082 [u=204.7MB f=1893.3MB] [7.75s] [cplayer] warn: Audio device underrun detected.
2025-03-21 09:33:15.082 [u=205.0MB f=1893.0MB] [7.75s] [cplayer] v: restarting audio after underrun

UPDATE: Here is another more severe one with Legacy enabled

2025-03-21 11:23:21.169 [u=521.0MB f=1577.0MB] [6613.84s] [cplayer] warn: Audio device underrun detected.
2025-03-21 11:23:21.169 [u=521.0MB f=1577.0MB] [6613.84s] [cplayer] v: Enter buffering (buffer went from 100% -> 0%) [0.000000s].
2025-03-21 11:23:21.169 [u=521.0MB f=1577.0MB] [6613.84s] [vo/avfoundation] v: Frame duration changed: 33365 -> 50044
2025-03-21 11:23:21.179 [u=521.0MB f=1577.0MB] [6613.85s] [cplayer] v: Still buffering (buffer went from 63% -> 0%) [0.000000s].
2025-03-21 11:23:21.249 [u=521.3MB f=1576.6MB] [6613.92s] [cplayer] v: Still buffering (buffer went from 0% -> 63%) [0.160000s].
2025-03-21 11:23:21.251 [u=520.1MB f=1577.9MB] [6613.92s] [cplayer] v: End buffering (waited 2.715194 secs) [0.256000s].
2025-03-21 11:23:21.251 [u=520.2MB f=1577.8MB] [6613.92s] [cplayer] v: restarting audio after underrun

No packet loss, symbol errors, or low bitrate. Network appears stable.

FURTHER TESTING:

Apple TV vs Fire TV - Audio Cache & Format Comparison (Channels DVR)

Devices Tested:

  • Apple TV 4K (2017, Model A1842)
  • Apple TV 4K (2021, Model A2169)
  • Fire TV 4K Max (latest gen)

Apple TV (Wired): (Tested on wi-fi as well. Only differece is lower buffer cache numbers with audio often pinned at 0.0s)

  • Audio Format: ac3 (ATSC A/52A (AC-3))
  • Total Cache (Show Stats):
    • Video: ~0.5–0.7 seconds
    • Audio: ~0.1–0.2 seconds (frequently drops to 0.0)
  • Behavior:
    • Frequent audio device underrun errors in logs
    • Playback buffers randomly, often after 10+ minutes
    • Happens on both wired and Wi-Fi

Fire TV 4K Max (Wired):

  • Audio Format: raw ac3 (raw audio passthrough decoder)
  • Total Cache (Show Stats):
    • Video: ~1.7–1.9 seconds
    • Audio: ~0.6–0.8 seconds
  • Behavior:
    • Smooth playback
    • No underrun errors

I have also tested by pausing liveTV for 5-10 seconds and seeing what happens. The under runs still occur but there is no buffering pause.

#54

@tmm1 @eric

Thanks again for the continued support and responses so far.

I’ve now run Xcode console logging alongside live playback and found no corresponding audio-related system messages when underruns occur. Specifically, I monitored the logs for the following:

underrun
audiounit
AVAudioSession
deactivateAudioSession
corespeechd
CSAudioProvider
interruption
StreamPrepared

At this point, I feel like I’ve exhausted every angle I can test on my end — including hardware variations, network analysis, driver settings, and logging — and I can’t move forward without more guidance from the team. I know the issue is minor but I would love to see it through this point.

I was also thinking about possible solutions after confirming the underruns don't cause buffering when I delay the live feed by just a few seconds:

  • User-defined playback delay (A global setting to force a 3–10s buffer before live playback starts)
  • Adaptive underrun handling (Functionality that will auto-float playback back a few seconds if an underrun is detected so that the stream won't buffer every time there is an underrun)

I'm happy to do whatever to try and find the cause and/or solution for this issue and am just trying to find a reliable path forward at this point.

Thanks!

Audio choppy OTA HDHR
#55

I know this sounds odd, but by any chance do you have IPv6 turned on? Whenever I use IPv6 on my network I have random issues with Channels. For that and other reasons, I no longer use IPv6. I still get the random OTA picture pause/menu bar pop-up. I think it's because there is almost no buffer for OTA. On TVE I see about 15 seconds of buffer.

#56

Thanks for the reply! Unfortunately, I already have IPv6 disabled in my UDM Pro settings and have for a while. I agree that the issue seems to be the lack of any real buffer when watching Live TV through the HDHR Prime. In most cases, the underruns recover really quickly—usually within half a second—but the buffering pause is what makes it noticeable. The simplest workaround I’ve found is to pause Live TV for 3 seconds to give the buffer a little room, which got me thinking about whether a setting or feature could help handle that kind of thing automatically.

#59

I am having very similar issues as OP. Even wired I get the network issue. This started happening probably two weeks ago or so. I recently put in a ticket and was told to Go to Settings -> Playback -> Streaming Quality and set Original Quality Delivery to Stream. But this did not resolve anything.

#60

I have pretty much hit bedrock in terms of troubleshooting this after putting in more hours than I would care to admit.

Are you also watching on AppleTV? I'd be curious to see if you also are getting these audio underrun issues that seem to be causing the problem. Next time you're watching TV if you open a browser you can navigate to http://IP_OF_DEVICE:57000/log

That will give you expanded logs. If you get a buffering pause, you can check the log and see what caused the error. Would be really helpful if someone else could confirm the same issue.

#61

@eric @tmm1
Hey guys – just wanted to ping you one more time in case you had any thoughts on this issue. I’ve been digging pretty deep and have done a ton of testing, documenting, and ruling things out. Still seeing the audio underrun problem persist and would really appreciate any insights or direction you might have. Thanks for all the work you do on Channels – I know this stuff can be hard to track down.

#62

@tmm1

So here is what I am seeing after some experimentation. Over the past few weeks the number of menu bar pauses has increased dramatically. Maybe a change in the channels software, or something Apple did in the latest TVOS update.

BUT, I did discover that all I have to do to stop the menu bar pop up/pause is to press pause for a couple of seconds after I change OTA channels and let the ATV buffer build up. Once I do that, no more unexpected pauses.

Tuner sharing is off on my system, but it made no difference if it was on or off, it's the local buffer in the ATV that is the key.

So, it appears that a simple solution would be for the Channels ATV app to have the option to create a small buffer on channel change. My YTTV app has the option to select a normal or reduced buffer, so something like that maybe. TVE streams always have a buffer on Channels so they don't have the issue.

1 Like
#63

Not for nothing, but a few HDHR issues seem to have popped up since their newest firmwares came out. Timing seems suspicious.

The UPnP one in particular.

**HDHomeRun Firmware** (20250117beta1):
* ATSC3: Fix problem handling 4K test broadcast from Canada.
* ATSC3: Fix problem where incorrect parental rating could be applied.
* TECH5/DEV: Fix problem with ATSC3 "forward" output format where power-save mode could activate stopping operation.
* TECH5: Auto-restart demodulation when needed on older ATSC1-only models.
* HDD models: Improve handling of a failing hard drive.
* UPnP: Only announce services using the primary IPv4 and primary IPv6 address.
* MDNS: Improvements to MDNS handling.

**HDHomeRun Firmware** 20250130beta1
* Add signal strength/quality to the channel scan results
Why didn't this recording go down the channel list? (OTA signal failed)
#64

If you have concerns that this has affected you post in the HDHR Forum or file trouble ticket ... I have 2 Primes and 3 4 tuner devices and do not have this problem. Silicondust if you report it will look at your units remotely.

#65

Thanks, I’ll definitely reach out to them as well. The reason I’m focusing here is because the issue only occurs when watching through the Channels app on my Apple TVs. If I use Plex or the HDHomeRun app on the same Apple TVs, the issue doesn’t happen. It also doesn’t occur when using the Channels app on my Fire Stick.

Just to clarify—are you using your HDHR Primes specifically with Channels on Apple TV?

#66

Thanks for the reply, and that is good to know. I am still on stable release 20230713 but might be worth giving the beta release a try and seeing if I get any differing behaviors.

#67

I am on the beta, have been since it came out. No difference in the issue

#68

This is exactly what I’ve been doing as well. At this point, a setting that introduces a preset delay whenever a new channel starts playing seems like it would be a great solution. The real annoyance for me right now is that if I want to rewind and rewatch a play, I then have to go back to live, pause again, and then hit play. Not the end of the world, but a delay setting would be a really nice quality-of-life improvement.

I also started looking into other, more involved ideas. Since this always seems to happen when the audio buffer hits 0 during an underrun, I wondered if it might be possible to adaptively slow down the stream slightly when an underrun is detected—then speed it back up gradually once the buffer recovers. Kind of like an on-the-fly delay that only kicks in when needed.

Not sure how practical that is, and honestly, the static delay option seems like the most straightforward and sensible approach.

#69

Does not even need to be much of a buffer. I am hitting pause play for less than a second and that gives just enough audio buffer to keep it going. A zero audio buffer just does not work well. Even my Dante audio gear has a few milliseconds of buffer.

#70

That’s good to know. I’ve been more conservative—usually pausing for about 3 full seconds, which gives me around 10 seconds of audio buffer.