ATSC 3.0: Raleigh/Durham - Jan 2021

[csdesigns]

In case some people are curious, here are some samples of the .11 channels I captured tonight.
WRAL - 1080p60@5Mbps Stereo
WRAZ - 720p30@7Mbps 5.1
WARZ - 960x540p60@2Mbps Stereo
(the audio rates/channels may be program-dependent)

In only brief review, WRAL looks better than ATSC 1.0 counterpart. WRAZ technically looks better as well, but the reduced motion rate is sort of unfair. Given that I consistently saw only 30Hz all evening on this channel, I am going to assume that this is intentional, if not ultimately accidental and incorrect.

[csdesigns]

Appears to be slightly better, but far from perfect. These new fw versions can lock to a multi-PLP signal much better, but there is still a consistent issue with 105.11. For instance, I can tune to 150.11 and 134.11, but I can't tune to 105.11 with the Android TV or Windows apps at all (also can't lock onto the signal with TSReader Pro on this network). When I try to tune to 105.11, I can see the tuner tries its best to repeatedly lock on, but it never reaches a stable lock. With the HDHR GUI App and piping the tuned channel to VLC, I can view 105.11 however. If a PCAP would be of assistance, I can upload that later tonight.

As mentioned above, I am able to get audio to decode on one of my Shield's. I have three 2015 Shield's, and have tested with two of them. The one I was testing with earlier today cannot tune 105.11. It also does not decode audio on any ATSC 3.0 channel.

However, on my second Shield, I can tune to 105.11 (somewhat reliably; I spoke about on IRC some of the channel change issues on iOS I am seeing wrt 105.11 and how it can sometimes force me to have to kill the app in order to restore decoding – it is the same here as well), and I also have audio decode on this box.

I just verified the system version of the two Shields as well as the HDHR app versions+settings. Both boxes are identically setup, so I am really perplexed as to the differences I am seeing. Only difference would be in the receiver the Shield is sending audio to, but I would think that PCM is PCM, and that wouldn't matter much (especially since the receiver in the chain for the Shield that isn't decoding audio is the much more higher end model).

[rljnc]

I think I saw this posted somewhere, on my 2019 shield that I can get audio on, it is only outputting to left speaker, are others having this issue. Also I am still getting no data on 105.11 and 150.11 with the firmware update 20210105.

[nickk]

I think I saw this posted somewhere, on my 2019 shield that I can get audio on, it is only outputting to left speaker, are others having this issue.

That suggests you are running an older version of the app - be sure to upgrade to the 20210104 release.

Nick

[rljnc]

I am on the latest update. Version 20210104(app) / 20201230e (ui) beta
Device id 1080FCA8
Firmware 20210105

[csdesigns]

I think I saw this posted somewhere, on my 2019 shield that I can get audio on, it is only outputting to left speaker, are others having this issue.

I am on the latest update. Version 20210104(app) / 20201230e (ui) beta
Device id 1080FCA8
Firmware 20210105

I have a similar setup on my 2015 Shield. Audio for the channels on the 527MHz frequency (the .11s) downmixes to stereo ok. But on the 473MHz frequency, the audio only decodes to mono (left channel). Same behavior in my setup with the Windows/Xbox apps as well.

[csdesigns]

Also I am still getting no data on 105.11 and 150.11 with the firmware update 20210105.

I believe the no data issue is due to the fw not pulling guide data from the correct multi-PLP combination that is required for the channels on this frequency. I suspect/hope this will be addressed in the next official fw release.

[CBme]

I think I saw this posted somewhere, on my 2019 shield that I can get audio on, it is only outputting to left speaker, are others having this issue.

I am on the latest update. Version 20210104(app) / 20201230e (ui) beta
Device id 1080FCA8
Firmware 20210105

I have a similar setup on my 2015 Shield. Audio for the channels on the 527MHz frequency (the .11s) downmixes to stereo ok. But on the 473MHz frequency, the audio only decodes to mono (left channel). Same behavior in my setup with the Windows/Xbox apps as well.

As it is happening in multiple markets, I assume it is something that isn't a technically faulty broadcast. So it we will just have to wait for the HDHR team to get it sorted. For the separate Seattle and Portland markets our NBC and FOX grouping is ok now but our ABC and CBS has the 'mushed into front left' issue.

[csdesigns]

As it is happening in multiple markets, I assume it is something that isn't a technically faulty broadcast. So it we will just have to wait for the HDHR team to get it sorted. For the separate Seattle and Portland markets our NBC and FOX grouping is ok now but our ABC and CBS has the 'mushed into front left' issue.

Precisely, this is a sw issue. The official HDHomeRun apps are not decoding and downmixing correctly on some channels (and analyzing multiple streams where the downmix is fine vs those where it is not, does not immediately scream out any major discrepancies in the audio streams themselves). Due to the infancy of AC-4 decode support from within the app, I am not too terribly surprised by this. I seriously doubt this has anything to do with the tuning hw or the hw of the player itself. It is somewhat noteworthy however that this issue seems to be directly tied to the frequency being tuned. For instance, in my market, there are two ATSC 3.0 frequencies. All of the channels on one frequency downmix fine ('fine' being relative of course – IMHO the downmix could be a lot better, as it appears the app is not adhering to the complete dialogue enhancement setting within the AC-4 metadata for stereo downmixing), while all of the channels on the other frequency do not.

[tmm1]

Can anyone share samples from the stations which are not channel mapping correctly?

[csdesigns]

Can anyone share samples from the stations which are not channel mapping correctly?

Do you mean audio channel mapping? I've already uploaded links to stations where the audio is downmixed somewhat accurately. Here is a link to one that does not.

[CBme]

Can anyone share samples from the stations which are not channel mapping correctly?

Lots of samples have been shared with the team from different markets.
It may be the second issue specified here:

Audio content issues:
There are two different issues with similar symptoms where it sounds like the channels are being mapped incorrectly. The first we were investigating if it was a broadcast issue or Silicondust issue when the broadcast changed and solved the problem. The second is understood and will take some more work to address. It isn't a channel mapping issue.

The abc/cbs channel examples for Seattle can be found here
https://onedrive.live.com/?authkey=%21A ... 31209CB69D

[tmm1]

Thanks.

Looks like some of the samples use 5_X_codec_mode=ASPX while others use 5_X_codec_mode=ASPX_ACPL_3

[CBme]

Thanks.

Looks like some of the samples use 5_X_codec_mode=ASPX while others use 5_X_codec_mode=ASPX_ACPL_3

I don't currently have the knowledge to assign meaning to that other than "they are different". If you looked at the NBC & FOX (CH31 - plays correctly now), yes they should be different than ABC and CBS (CH24 - channels with issue). But ABC and CBS have the same symptom so if you are saying they are different, that would be extra strange. Only info I have about the technical bits is from the KIRO manager:
"As far as the audio goes, we are mapping LtRt to group 1 pair 1 for all our programs. We have a plan to put a more robust 5.1 surround in place, but that will be a few months. There is no reason you should get only one side as total and one side as surround."

[tmm1]

I sent the technical details of the differences between the audio feeds to SD and the latest release now plays both types of samples correctly.