Hqplayer to chord 2go wirelessly?

@jussi_laako So is there a way to get HQPLAYER to play to the Hugo 2 with 2GO wirelessly via ROON?

My ROON ROCK NUC recognizes HQPLAYER running on my MACBOOK pro BUT it seem you can only play out to a wired endpoint???

How can I get HQPLAYER output to stream wirelessly to the Hugo2GO???

thanks!!!

It would need to get HQPlayer NAA endpoint capability added to it’s software. Without that it won’t work.

The 2Go does not include the HQPlayer NAA endpoint software. You could raise this as a feature request with Chord. But as it stands right now, you cannot stream HQPlayer directly to the 2Go over the network.

Edit: Seems Jussi hit submit just before I did… :slight_smile:

Ok… so if it had endpoint… I could stream your upsampled tidal direct to the Hugo 2go?

This would be like a portable mscaler! Am I correct?

That would be awesome.

Yes, the MScaler type functionality is in HQPlayer. And NAA endpoint functionality is very light weight and can run on small devices, could probably run on 2Go as well.

Realistically, only if you use the 2Go via Ethernet. The Wi-Fi chipset in the 2Go is garbage. It is 2.4GHz only and only advertises a single 65Mb/s stream, making it an old/crappy chip even by 802.11n standards. Keep in mind, that 65Mb/s is theoretical max, and real world will be closer to half /two-thirds that. 768k PCM is ~50Mb/s, which has no chance of working reliably on the 2Go’s Wi-Fi. This is a big part of why the folks over on head-fi are reporting problems with the 2Go streaming even at 192k, and 384k being absolutely broken over Wi-Fi when targeting it via Roon.

this is F’d up!!!

they have crippled what could have been an EPIC device.

So I saw this got reposted over on head-fi (where I do not have an account), so I figured I’d give a bit more background here. Sorry for the wall of text…

Wi-Fi transmission rates have three main factors that determine their maximum theoretical bandwidth: channel width, symbol encoding scheme, and stream count.

On 2.4Ghz, channel width is fixed at 20Mhz. (Use of 40Mhz on 2.4Ghz is considered very bad neighborship – the only practical real-world usage is for point-to-point wireless links using highly directional antennas such as a Yagi.) On 5Ghz, wider channels are supported. 802.11n supports 40Mhz channels. 802.11ac and 802.11ax support up to 160Mhz channels, but that’s not really practical in the real world, except for the afore-mentioned point-to-point links. Realistic maximum is 80Mhz channels, which can work OK in the home where you typically have low density deployments. (But keep in mind density is not affected by just your kit, but all your surrounding neighbor’s kit as well.) For enterprise, channel width is usually restricted to 40Mhz, and even restricting everything to 20Mhz is quite common for mid to very dense deployments (e.g., stadiums).

The symbol encoding scheme is a variable sliding scale, referred to as the “MCS index”. The client and the AP each exchange frames indicating their max supported index. (The index actually encodes both the symbol encoding scheme and the stream count, but don’t worry about that.) They then attempt to run the connection at the maximum rate both support. For 802.11n, that would be 64-QAM encoding with 400ns guard interval, which gives a max possible rate of 72Mb/s per 20Mhz channel stream. The 2Go advertisement of 65Mb/s indicates it does not support the top MCS index, instead one down. Now, I keep mentioning “theoretical maximum”, because in the real world, you will almost never communicate at maximum signal rate. The client and AP are constantly re-evaluating the symbol encoding selection to maximize bandwidth as RF conditions change. And change they do – constantly. There is so much interference from other devices, wall penetration reducing single strength, multipath reflections, etc., that your average real-world rates are often only half the theoretical max, and can frequently be MUCH WORSE. It’s not uncommon to see single-stream 2.4Ghz top out at around 20-25Mbit/s. And that’s BEFORE you factor in Wi-Fi is a shared, half-duplex medium and other devices on your network will steal time slots, reducing those rates further. Hence why 384k PCM, which is ~25Mb/s continuous, is going to be extremely unreliable on a single-stream 2.4Ghz channel. And the ~50Mb/s of a 768k PCM (or DSD512) is a complete and utter fantasy. (While not directly relevant here, since the 2Go is an 802.11n device, 802.11ac and 802.11ax introduce more modern encoding schemes capable of even higher symbol rates within the same channel width.)

The third factor is concurrent spatial streams. Wi-Fi is based on spread spectrum technology, whereby the signal is sent on different frequencies within the channel using a mapping pattern such that the energy is “spread” across the spectrum. Using multiple radios (each with their own antenna), with their transmissions offset in the spreading pattern from each other, you can effectively transmit multiple “streams” at the same time within a single channel. There are practical limits to this, however, both in physical terms (e.g., you need separate radios, antennas and sufficient power for each stream) and electromagnetic terms (e.g., they will interfere with each other if there is not enough spacing between them, making the signal unrecoverable at the receiver). 802.11n supports a maximum of four streams. In practice, only access points support the full four streams. Most client solutions were 1x1 (single receive, single transmit – typically used for IoT devices and other low bandwidth/cheap/etc devices), 2x1 (2 receive, 1 transmit – typically used by cheap to mid tier laptops where download is more important than upload), 2x2 (high end laptops) or 3x(2|3) (extremely rare, very high end laptops – plus some PCI Wi-Fi cards for fixed-in-place desktops).


As you can see, reported by my Meraki (==enterprise oriented kit), the 2Go only supports a single stream. This means real-world it will get max data rate of around 20-25Mb/s, assuming “normal” interference levels and NO OTHER DEVICES on the 2.4Ghz channel consuming anything more than trivial amounts of bandwidth (e.g., your kid firing up a 2.4Ghz-only phone or laptop and streaming Disney+ at the same time will absolutely kill you). 192k PCM (~12.5Mb/s) could work, but is likely to have hiccups. 384k PCM (~25Mb/s) MIGHT work when the stars are aligned, but is more or less doomed. And as said before, 768k (~50Mb/s) will never work.

Had Chord used a dual stream solution, the’d have bought the 2Go a bit of headroom such that 384k would probably work most of the time, and 768k could work when the stars are aligned, but would largely be unreliable. Better yet to have used a dual-band, dual stream solution, as then you end up with four times the real-world bandwidth of the solution they implemented. Even 768k could work then, though it would probably still suffer hiccups. Big advantage to 5Ghz is way more channels, too, so much less interference from your neighbors/etc, making for a far more reliable signal (=higher real-world symbol rates on average).

thanks for the detail man! cross posted on Headfi… really a shame CHord went with this crap 2.4ghz chip in 2020… a real head scratcher! Seems like they hired a terrible external developer.

For some comparison, on my home/office WiFi network based on two HPE 802.11ac AP’s I can do 8 channels of DSD256 from my Lenovo ThinkPad laptop connected to WiFi, to HQPlayer NAA (on Ethernet side).

That is about 86 Mbps constant.

@Kynprime

I see over on head-fi they have latched on to Meraki miss-identifying the 2Go as a Raspberry Pi. Please let them know that Meraki device identification is fundamentally flawed at best, and should be ignored. Currawong is correct; they are trying to identify the device based on network traffic patterns and other signatures, and it’s more often wrong than correct. Looking through all my client devices, Meraki has miss-identified about 65% of them. I have two actual RPi4s. Meraki has identified one of them as “Generic Linux” and the other as “iPod” (yes, really). Ignore the the Meraki auto-fingerprinting.

The “MAXSPEED” indicates the OUI registration for the Wi-Fi MAC address prefix, but even that doesn’t mean much; smaller companies often order their chips from other larger vendors since they don’t have enough volume to get a custom run with their own OUI. (When I says “enough volume”, I am talking a hundred thousand (or more) chips in a single batch. Chord is a small, boutique company and that kind of bulk purchase doesn’t make sense for them.)