Denon announced 3 port 8k HDMI 2.1 switcher

[Beershaun]

Denon just announced a new outboard 3 port HDMI 2.1 switching box you can plug into your x700 series avrs and the 8500

https://www.avforums.com/news/denon-and-marantz-introduce-8k-hdmi-switchers.19068

 

[oupee]

A bunch of amateurs. This should have been in the SR8015 from the beginning.

 

[amirm]

My reaction as well. Never seen a company resort to an external switcher this way. The whole point of an AVR is to have one box with everything, not two boxes.

 

[Beershaun]

My speculation is they wanted to be first to market but depended on a 3rd party to deliver it and then realized it was too expensive for their BOM so they made a game time call to just have 1 port at launch. Also does this solve a problem for people who have the bug that plagued the initial release? If so it's a good cheap alternative to buying a whole new AVR.

So while I agree it's clearly a band aid, if my speculation is true to reality, they benefitted from being first to market, and so likely made the right business decision.

 

[spamilton]

I guess this is their bandaid since their next lineup is pretty far off, and the competition is putting out products with all 2.1 ports. It is a pretty clunky solution, but I'd probably still use it when I end up needing more than one 2.1 port.

 

[Beershaun]

I guess this is their bandaid since their next lineup is pretty far off, and the competition is putting out products with all 2.1 ports. It is a pretty clunky solution, but I'd probably still use it when I end up needing more than one 2.1 port.

Right. It keeps their customers from leaving for their competitors.

 

[nerdoldnerdith]

HDMI 2.1 is a dumpster fire

 

[Mansinthe86]

My reaction as well. Never seen a company resort to an external switcher this way. The whole point of an AVR is to have one box with everything, not two boxes.

Didn't Samsung have a bunch of external boxes for their TVs?

 

[wseroyer]

My reaction as well. Never seen a company resort to an external switcher this way. The whole point of an AVR is to have one box with everything, not two boxes.

Phil Jones recently talked about this on a Audioholics webinar and said when they picked out the chipset for their new AVR's they had a choice between 3, 24 Gbit/s or 1, 40 Gbit/s port, I'm not trying to defend their choice, i'm just repeating what sound united had to say about it. I'm glad that they are doing this little box because at the very least it gives us something, I just wish it was free for current owners like myself.

 

[wseroyer]

Didn't Samsung have a bunch of external boxes for their TVs?

Yes, I have a frame TV with the one connect box, it's a external box that goes in your tv cabinet that has all of the power, cable and HDMI ports on it, so that you don't have to run a bunch of wires to the actual TV, totally different, it's not a band aid, its a feature that makes having a clean set up easy.

 

[maverickronin]

HDMI 2.1 is a dumpster fire

FTFY

 

[JWAmerica]

FTFY

It's true. I thought HDMI would be the easy answer to my problems and it was not.

As Amir stated, I bought an AVR for the all in one solution, but HDMI is so poorly implemented on PCs that I continue to have issues with the audio handshake with my AMD Vega 56 card. The commonly recommended solution is to use a splitter. Nvidia has the same problem with current gen cards. I have an open source application to keep the handshake intact, but now it's only outputting LPCM, and not Bitstreaming DD5.1 or DTS. Hopefully that means it's being decoded on the PC by the software player and just sending uncompressed 5.1. I never anticipated these complications.

 

[Beershaun]

Yep. Sending 40gbps raw data over a cable with real time processing is a really hard problem to solve. Now that processing and streaming System on a Chip solutions are super cheap and powerful I'd rather see them all take a step back to sending the data via TCP/IP in packets and then open it locally on the displays and audio renderers. Figure out how to package and send a separate optional audio file for people who want to have audio and video sent to separate devices and then have a controller service control syncing both audio and video renderers. That seems much better than trying to send the raw data across long lengths of poorly implemented cables.

 

[Vincentponcet]

Separating the video switching from the audio processing is the dream.
No more need to put the AVR in the trash when a new HDMI standard will come.
Sadly, their AVRs have no AES outputs, we are still stuck with their not great quality analog outputs.

 

[Beershaun]

Separating the video switching from the audio processing is the dream.
No more need to put the AVR in the trash when a new HDMI standard will come.
Sadly, their AVRs have no AES outputs, we are still stuck with their not great quality analog outputs.

Totally. I have 3 AVRs in my house that all work fine as integrated amplifiers for my various music listening areas but I have to buy a new one for Atmos support and hdcp2.2 for my home theater project. It feels wasteful and what I really want to buy is an audiophile grade hifi amplifier like the benchmark or Purifi for 2 channel music listening. Between my avrs I have enough amplifier boards of sufficient power and quality that I could cobble together a 12 channel Atmos system if I had the new video components and a box to put it all in and hook up. Just like building and upgrading a PC for example.

 

[nerdoldnerdith]

Yep. Sending 40gbps raw data over a cable with real time processing is a really hard problem to solve. Now that processing and streaming System on a Chip solutions are super cheap and powerful I'd rather see them all take a step back to sending the data via TCP/IP in packets and then open it locally on the displays and audio renderers. Figure out how to package and send a separate optional audio file for people who want to have audio and video sent to separate devices and then have a controller service control syncing both audio and video renderers. That seems much better than trying to send the raw data across long lengths of poorly implemented cables.

Couldn't a larger connector/cable with more channels just be used? I don't fully understand the problem of cramming all of that bandwidth into a cable, but I know it can be done at larger sizes. I think the problem is that they are trying to do too much with the dinky little HDMI connector.

 

[Beershaun]

Couldn't a larger connector/cable with more channels just be used? I don't fully understand the problem of cramming all of that bandwidth into a cable, but I know it can be done at larger sizes. I think the problem is that they are trying to do too much with the dinky little HDMI connector.

Its not my area of expertise either. But trying to maintain the integrity of that much data at that speed over cable length distances synchronously (as opposed to inside a box like a disk player or AVR) means you can't do things like error correct, resend lost data etc. Also the signal degrades quickly over distances beyond say 1-3 meters. So then you need to add a powered signal amplifier which can introduce noise etc.

 

[JWAmerica]

Couldn't a larger connector/cable with more channels just be used? I don't fully understand the problem of cramming all of that bandwidth into a cable, but I know it can be done at larger sizes. I think the problem is that they are trying to do too much with the dinky little HDMI connector.

HDMI 2.0 does 18Gbps and 2.1 does 48Gbps. The cable is not the issue. USB 3.2 can push 100W and 10Gbps. Bandwidth is not an issue until you reach insane resolutions like 8k.

 

[amirm]

Yep. Sending 40gbps raw data over a cable with real time processing is a really hard problem to solve. Now that processing and streaming System on a Chip solutions are super cheap and powerful I'd rather see them all take a step back to sending the data via TCP/IP in packets and then open it locally on the displays and audio renderers.

Consumer video is such a screwed up thing. They take a compressed stream (on disc or streamed) that is at most 100 mbit/sec, decompress it into gigabits/sec and then try to switch and send it around using HDMI. What is ironic is that the TV has full decoding capability of said streams so there is no reason for the source to decompress these bits. There is no reason at all for any upstream device to decode it.

They do it this way because hardware people comfortable with bits this way but not with software and protocols for sending compressed bits around.

If they had stayed in compressed domain as you say, then we could easily switch and route it using traditional networking gear.

In the old days broadcast TV was uncompressed so they routed it that way. But they have been sleep for years now not realizing the game has changed and keep pushing this broken idea of a high-speed serial streams over HDMI cables. And of course insanity keeps getting worse as the resolutions jump higher and higher, constantly breaking HDMI protocol and such with it.

 

[nerdoldnerdith]

HDMI 2.0 does 18Gbps and 2.1 does 48Gbps. The cable is not the issue. USB 3.2 can push 100W and 10Gbps. Bandwidth is not an issue until you reach insane resolutions like 8k.

I have an 8K TV doing 60Hz and a 4K TV doing 120Hz. Bandwidth is definitely an issue for me. Finding longer cables that worked for these was a pain.