And there are many of us that have no audio issues with any Roku player. When problems are not consistent across devices, troubleshooting can be difficult to impossible. I have Roku players that hook to AVRs and some that are straight into a TV. All stream media from my DLNA server without any problems. This includes audio in AAC, AC3 and DTS format, although of course only the players connected to an AVR can play DTS audio. My server is not altering the audio for supported codecs, so only the lossless audio codecs (Dolby TrueHD and DTS Master Audio) are transcoded. And those are all transcoded to AC3.
...and the observation that the issue is not consistent across playback devices should give the support team a clue that the problem lies not with the source or any transcoding, but how Roku is reading and acting on what is reported through HDMI as the capability of the playback device. That would also be consistent with the observations reported in the forum that the issue appears across many sources, not just RMP.
What you describe is not my issue. Since the OS 10 update only files with ACC & AC3 exhibit the crackling and only when played with RMP. These files used to play with RMP, then didn't without crackle but did and still do play fine with all other players. The issue for my Rokus, 3 out of 4 (one's a TCL Roku TV) was the new OS suddenly ignored the ACC stream in the file and played the AC3 even with Settings > Audio set to (Auto) the default. The workaround for me and many others in this thread was to change the setting from Auto to Dolby.
Ideally RMP would (Auto) choose the ACC stream first when available avoiding the issue as I suspect was the behavior pre-OS 10 update but as I never had any issue before I can't say for sure, I never actually had to check, it just worked. The Roku TV doesn't have this issue because there's no need for one device (Roku) to communicate to another (TV) what the protocol is, it's one device.
This is the symptoms (crackle) I'm referring to:
Media with multiple audio tracks have one that is flagged as default. That is what RMP, and any other media player, will play automatically. While it might be possible to detect an AAC audio track and play it by default, regardless of the flagged track, it might simply not be possible in the programming language Roku uses. That's merely conjecture on my part, as I really have no idea. While I have some programming experience, I've never messed with media playback, so there are likely many things I simply am not aware of.
Whether or not that's true is irrelevant when you consider this fact:
Same files played with no problem prior to the OS 10 update for years, hundreds of them. Same files, not new files encoded the same way, same exact files by all 3 Roku's RMP.
OS 10 update > then they don't. The issue is in how the Audio > (Auto) setting is changed post update from Dolby or the OS changes the behavior or which stream RMP selects.
That's a repeatable, verifiable fact. Something one that does both hardware & software troubleshooting would beg for as a clue.
You might have listed it in a previous post, but what is the model number of your Roku that has the AC-3 problem? Just trying to identify if there's a specific model that it's happening with.
I understand that one is flagged as default. I ran a limited test on that a while back, and noted that, under OS 10 when the file has both an AAC and AC3 track, RMP plays the AC3 track, regardless of which is flagged as default - and regardless of which is stream 0 and which is stream 1. RMP has (or had at one time) an option to select the audio track, but that option is grayed. I'll see if I can't test what it did under OS 9.4. I suspect it's no different as the RMP build hasn't changed.
I have 2 Roku devices (both 3810x Streaming Stick+) and 3 playback devices. One Roku device is up to date on OS 10-4198. The other is still on OS 9.4 as I've blocked its access to the internet. Both have access to my DLNA server. Playback device 1: Recent Samsung TV (HDMI 2.1) with audio out thru ARC to a receiver capable of DD/DTS. It has no problem with AC3 files under OS 10 in auto mode on both Audio and HDMI. Playback device 2: 2013-era Samsung "dumb" TV (HDMI 1.4) with internal stereo speakers and capable of decoding DD/DTS. It only works under OS 10 with HDMI set to DD/DTS and pops/clicks with AC3 streams and HDMI set to auto. Playback device 3: 2005-era Sharp TV (HDMI 1.4) with internal stereo speakers and requiring PCM-Stereo input. It pops/clicks on all AC3 streams regardless of Roku HDMI setting. All 3 worked fine with AC3 under OS 9.4.
It looks to me like the issue is one of what Roku is now doing with the capability of the playback device and how it's reading what it needs to transcode to. I don't know what it's sending under HDMI=Auto, but it seems to be sending DD and/or DTS correctly when HDMI is explicitly set to DD and/or DD/DTS. It does not seem to be sending PCM when explicitly set to PCM.
@mj34hig44 , tried to look at your video, but did not have access rights. Could you check to see if you're set to "anyone with the link"?
@gk802 great info, thanks. I don't have the same player as you, so I can't try to replicate it here. You do seem to have pinpointed something in OS 10 that isn't playing correctly. This thread was started with problems with the 3920, which is a player I have and it works fine for me.
No idea if the DLNA server might be making a difference. For your player, the server should not be transcoding if the container is correct (either MKV, MP4, MOV or TS/M2TS), the video is H.264/MP4/MPEG-2, and the audio is AC3/AAC/LPCM. All I can say is that they all stream fine on the players/devices I have with Serviio as my DLNA server. But then I wrote the transcoding profiles Serviio uses for Roku devices, so I've had some control over making them work correctly. 😄