HQ Player

[Ozzie]

5 minutes ago, Ozzie said:

great! That worked. It also reloads when I reselect it in the client. The switching is so fast that I will never the Roon EQ again because it is wayyyy to slow in comparison. I have also now created a txt file for all of my headphones and added new profiles for each that are just Preamp of 0db for when I get around to it so I never have to touch the pipeline setup again. This is great! 

One suggestion for the profile view on the client would be to alphabetically sort it so that I can put some numbering in front of it. It seems to be based on entry date right now and the latest one is last.  

[Miska]

45 minutes ago, Ozzie said:

One suggestion for the profile view on the client would be to alphabetically sort it so that I can put some numbering in front of it. It seems to be based on entry date right now and the latest one is last.  

 

I can look into that...

 

[Jud]

1 hour ago, Kalpesh said:

So, could there be a rationale in that mastering is (usually/often) rather done at PCM 384 than at DSD 512 ?

It’s done in PCM because most mastering operations cannot be done in DSD as a technical matter.

[Miska]

1 hour ago, Kalpesh said:

So, could there be a rational in that mastering is (usually/often) rather done at PCM 384 than at DSD 512 ?

 

I don't think anybody works at 384k PCM. But some do at 352.8k PCM. Most tools exist for PCM and the market for DSD tools is so small that companies don't have much interest in investing a lot of extra effort in making tools for doing DSD work. It pretty much means doing double work for everything (like in HQPlayer).

 

Some studios/labels/companies use HQPlayer4Pro for mastering DSD productions. But it is not very convenient workflow for many scenarios requiring extra effort not everybody is ready to take.

 

IOW, DSD recording/mastering is still too niche for convenient work flows when you compare to regular PCM. Partially same applies to PCM rates above 192k, most tools won't handle anything above 192k PCM either.

 

Of course, given modern ADC's and DAC's, working in PCM means that you go through unnecessary SDM -> PCM -> SDM conversions. But most of the music market just doesn't care. They are happy with ProTools and AutoTune plugin at 48k PCM, as long as they can find dynamic range compressor that makes their music sound LOUDEST.

 

[Miska]

27 minutes ago, Jud said:

It’s done in PCM because most mastering operations cannot be done in DSD as a technical matter.

 

You can do all the same in SDM you can do in PCM. It is not an issue. Reasons are not technical.

 

[StreamFidelity]

54 minutes ago, Miska said:

You can do all the same in SDM you can do in PCM. It is not an issue. Reasons are not technical.

That's very interesting. How do you solve the 1-bit problem? This has always been cited as a reason why mastering with SDM (DSD) is not possible.

[Jud]

1 hour ago, Miska said:

 

You can do all the same in SDM you can do in PCM. It is not an issue. Reasons are not technical.

 

Would SDM need to be more than 1 bit to accomplish certain operations?

[Superdad]

58 minutes ago, StreamFidelity said:

That's very interesting. How do you solve the 1-bit problem? This has always been cited as a reason why mastering with SDM (DSD) is not possible.

 

All dogs are mammals but not all mammals are dogs.

Likewise all DSD is 1-bit and S-D modulated, not all S-D modulated data is 1-bit. 

[firedog]

You can do what Roon can do with DSP for DSD and use DSD Wide - usually 8 bit, perform operations, and then back to one bit.

There's an argument over whether this is all done in the DSD domain or not; Roon argues that it is - as there is no PCM decimation. 

[bogi]

1 hour ago, Jud said:

Would SDM need to be more than 1 bit to accomplish certain operations?

 

SDM may stay 1bit but you need to perform an operation on series of bits. Since DSD is a bitstream, you can process n bits at once at the DSD rate, one bit in and one bit out every 1/fs (FIFO principle), so each DSD bit can participate n times on computation as it moves through n bit buffer from one end to the other.

[AudioDoctor]

So far, HQP Embedded 5.3.1 has been a seamless upgrade for me on Linux 22.04

[dericchan1]

@Miska

can you please explain briefly what are the new features included in gbr NAA image and the Hqplayer desktop 5.3.2?

 

Thanks

Deric

[bogi]

From fb page: Improved support for NAA input features.

I am interested too.

[Miska]

9 hours ago, StreamFidelity said:

That's very interesting. How do you solve the 1-bit problem? This has always been cited as a reason why mastering with SDM (DSD) is not possible.

 

There's no "1-bit problem" any more than there is "24-bit problem".

 

Cited "reasons" go to FUD category.

 

[Miska]

7 hours ago, dericchan1 said:

@Miska

can you please explain briefly what are the new features included in gbr NAA image and the Hqplayer desktop 5.3.2?

 

It focuses on the updated USB Audio Class 2 input support. Both directly into HQPlayer Embedded and also when doing the same through suitable NAA either to Desktop or Embedded. IOW, it makes HQPlayer appear as a USB DAC and thus allows one to use various sources for HQPlayer, with automatic rate switching. Earlier this has been case through S/PDIF and AES/EBU inputs, also with automatic rate switching when using one of supported input devices.

 

This feature is particularly useful for some streaming services such as Apple Music, Amazon Music or Spotify. Or if you prefer to use the official Tidal or Qobuz apps. Although already earlier Spotify has been easy through S/PDIF or loopback drivers since it always uses 44.1k rate.

 

Desktop 5.3.1 release had some focus on making automatic rate switching work on macOS when using combination of LosslessSwitcher application and BlackHole loopback driver. Now there's additional more universal hardware path.

 

I just copy here what I just wrote on Roon forum thread about the topic:

 

For example if one boots up latest HQPlayer OS on UP Gateway with the USB OTG set to Device mode, in HQPlayer Desktop select “hqplayer:USB Audio (DWC3)” as input device. Connect your source device with USB → microB cable to the UP Gateway USB 3 OTG port.

 

If you use RPi4 with HQPlayer OS, before booting up with new image, edit the config.txt first and on the last lines swap the ‘#’ prefix so that the dwc2 host mode line has ‘#’ (commented out) and the dwc2 peripheral mode line has ‘#’ removed. In HQPlayer instead select “hqplayer:USB Audio (RPi4)” as input device. Connect your source device with USB → type-C cable to the RPi4 Type-C port. Since the RPi4 can draw quite a bit of power, you may have best results if you can use type-C → type-C cable for connecting. You will need to use at least USB3 → type-C cable on USB3 port to supply enough current.

 

In HQPlayer Desktop, for source URI line (above playback queue display) enter “audio:default/0/2” and hit enter. Now it should appear on the playback queue. Then just start playback. Now the NAA should appear as a USB DAC on the source device. When you start playing something, HQPlayer time should start proceeding and you should hear what ever you play on the source device. I’ve tested mostly with my old iPad Pro through the Apple’s Lightning to USB3 adapter dongle which also allows simultaneous charging of iPad.

 

[1laraz]

28 minutes ago, Miska said:

This feature is particularly useful for some streaming services such as Apple Music, Amazon Music or Spotify. Or if you prefer to use the official Tidal or Qobuz apps

Wow. Does it also work as described with Windows OS?

[dericchan1]

56 minutes ago, Miska said:

 

It focuses on the updated USB Audio Class 2 input support. Both directly into HQPlayer Embedded and also when doing the same through suitable NAA either to Desktop or Embedded. IOW, it makes HQPlayer appear as a USB DAC and thus allows one to use various sources for HQPlayer, with automatic rate switching. Earlier this has been case through S/PDIF and AES/EBU inputs, also with automatic rate switching when using one of supported input devices.

 

This feature is particularly useful for some streaming services such as Apple Music, Amazon Music or Spotify. Or if you prefer to use the official Tidal or Qobuz apps. Although already earlier Spotify has been easy through S/PDIF or loopback drivers since it always uses 44.1k rate.

 

Desktop 5.3.1 release had some focus on making automatic rate switching work on macOS when using combination of LosslessSwitcher application and BlackHole loopback driver. Now there's additional more universal hardware path.

 

I just copy here what I just wrote on Roon forum thread about the topic:

 

For example if one boots up latest HQPlayer OS on UP Gateway with the USB OTG set to Device mode, in HQPlayer Desktop select “hqplayer:USB Audio (DWC3)” as input device. Connect your source device with USB → microB cable to the UP Gateway USB 3 OTG port.

 

If you use RPi4 with HQPlayer OS, before booting up with new image, edit the config.txt first and on the last lines swap the ‘#’ prefix so that the dwc2 host mode line has ‘#’ (commented out) and the dwc2 peripheral mode line has ‘#’ removed. In HQPlayer instead select “hqplayer:USB Audio (RPi4)” as input device. Connect your source device with USB → type-C cable to the RPi4 Type-C port. Since the RPi4 can draw quite a bit of power, you may have best results if you can use type-C → type-C cable for connecting. You will need to use at least USB3 → type-C cable on USB3 port to supply enough current.

 

In HQPlayer Desktop, for source URI line (above playback queue display) enter “audio:default/0/2” and hit enter. Now it should appear on the playback queue. Then just start playback. Now the NAA should appear as a USB DAC on the source device. When you start playing something, HQPlayer time should start proceeding and you should hear what ever you play on the source device. I’ve tested mostly with my old iPad Pro through the Apple’s Lightning to USB3 adapter dongle which also allows simultaneous charging of iPad.

 

Wow, that's a breakthrough!! Just so I am clear, does it mean my set up would be as follows?

 

ipad or iphone 15 running Amazon mobile app or Qobuz app or Apple Music app, connect through USB C -> RPI4 running the new NAA OS image (as an input device) then USB into PC HQplayer desktop, set audio:default/0/2 then out to NAA to DAC?

 

Which NAA/Linux/ image should I download to test with RPI4? jammy? bookworm?

 

Does it mean I can use my previous setup with a wiim pro connect through toslink to usb adapter to hqplayer pc and now auto rate switching will just work?

 

Thanks

 

Deric

[bogi]

2 hours ago, Miska said:

It focuses on the updated USB Audio Class 2 input support.

I understand it this way: The new auto rate support is UAC2 specific and requires quite rare device (slave) side USB hardware (available on Up Gateway and Pi4), therefore:

- It will not work for example with PCI sound cards which provide SPDIF input (no USB involved in this case). Such devices (like Sound Blaster Z SE with optical SPDIF input) are rarely mentioned here.

- It requires device (slave) side USB hardware on computer running NAA. It will not work for example with USB to optical SPDIF adapters like Hifime S2 Digi connected to usual master type computer USB port.

- As digital sound source it requires an USB host (master) type USB device (typically computer or tablet or phone) connected to the special device (slave) type USB port. So you can play from a computer/tablet/phone to Up Gateway or RPi4 NAA as to an USB DAC despite of they are mini computers and not DACs.

 

Miska, I am curious what would happen if SPDIF sound source (for example a traditional CD player) would be connected through USB to SPDIF adapter to device (slave) type of USB port on UP Gateway or Pi4. Would auto rate switching work in such a case? USB protocol requires both master and slave. I'm curious where the master appears in such a case. I guess these USB to SPDIF adapters like Hifime provide only USB slave functionality at their side of USB connection.

 

The new functionality allows to use a different auto rate switching solution than the former one based on specific ADI products. Up Gateway and Pi4 owners don't need to buy these specific products to get auto rate switching but sound source is restricted to USB connected phone/tablet/computer.

[Miska]

2 hours ago, 1laraz said:

Wow. Does it also work as described with Windows OS?

 

If you have a suitable Linux-based NAA then yes, when running HQPlayer Desktop on Windows.

 

But you need suitable hardware and Linux. Windows (and macOS) just totally lack the needed functionality.

 

[Miska]

2 hours ago, dericchan1 said:

ipad or iphone 15 running Amazon mobile app or Qobuz app or Apple Music app, connect through USB C -> RPI4 running the new NAA OS image (as an input device) then USB into PC HQplayer desktop, set audio:default/0/2 then out to NAA to DAC?

 

Yes, although you likely need (or you at least would want) a powered USB type-C hub between your phone and the RPi4. Since RPi4 is powered through the same type-C connection. I doubt iPhone has enough power output from it's type-C connector to properly power RPi4.

 

For iPhone/iPad, UP Gateway is simpler, as it has separate power input and USB ports.

 

On input side you would be running HQPlayer OS (but as a NAA with HQPlayer possibly disabled), since the NAA OS is not up to date with this yet.

 

2 hours ago, dericchan1 said:

Which NAA/Linux/ image should I download to test with RPI4? jammy? bookworm?

 

HQPlayer OS image.

 

2 hours ago, dericchan1 said:

Does it mean I can use my previous setup with a wiim pro connect through toslink to usb adapter to hqplayer pc and now auto rate switching will just work?

 

No, it won't help with those cheap S/PDIF adapters since those lack the needed support. And those are USB devices connected to host ports, so totally different thing anyway. So for S/PDIF or AES/EBU inputs, for the automatic rate switching to work, the same hardware is needed as before.

 

[Miska]

1 hour ago, bogi said:

Miska, I am curious what would happen if SPDIF sound source (for example a traditional CD player) would be connected through USB to SPDIF adapter to device (slave) type of USB port on UP Gateway or Pi4. Would auto rate switching work in such a case? USB protocol requires both master and slave. I'm curious where the master appears in such a case. I guess these USB to SPDIF adapters like Hifime provide only USB slave functionality at their side of USB connection.

 

In USB terminology these are "host" and "device". You cannot connect two "device" things to each other, and you cannot connect two "host" this to each other either. So you cannot connect type-B -> type-B or type-A -> type-A. So with earlier USB connector types this was clear. Now with type-C being used on both sides it is not clear from the connectors, but the regarding the hardware behind the connector it is still the same.

 

Mobile phones like iPhone have long had capability to switch their hardware between host and device modes. Many embedded SoC's (processors) have this capability. Thus you can find it from RPi4 and also from UP Gateway (which uses Atom model designed for mobile market). There are many other pieces of ARM-based hardware that have this capability, but it also depends whether also the board designer implemented support for this feature, as it needs to be taken into account when designing the PCB.

 

With type-C connector they also introduced  "alternate modes" which means the same connector can act as USB connector, DisplayPort connector, HDMI connector or Thunderbolt connector for example. This means handshake where the mode is chosen, and from that point on, the signalling on the cable totally changes depending on the mode. In addition type-C also brought high power charging modes through PD (Power Delivery) and similar standards that are now used by many laptops etc.

 

1 hour ago, bogi said:

The new functionality allows to use a different auto rate switching solution than the former one based on specific ADI products. Up Gateway and Pi4 owners don't need to buy these specific products to get auto rate switching but sound source is restricted to USB connected phone/tablet/computer.

 

Yes, these two ways complement each other depending on type of connectivity one prefers.

 

For straight S/PDIF or AES/EBU to Windows computer running HQPlayer Desktop, RME HDSPe AIO is still the simplest approach.

 

[Miska]

1 hour ago, bogi said:

Miska, I am curious what would happen if SPDIF sound source (for example a traditional CD player) would be connected through USB to SPDIF adapter to device (slave) type of USB port on UP Gateway or Pi4. Would auto rate switching work in such a case? USB protocol requires both master and slave. I'm curious where the master appears in such a case. I guess these USB to SPDIF adapters like Hifime provide only USB slave functionality at their side of USB connection.

 

In USB terminology these are "host" and "device". You cannot connect two "device" things to each other, and you cannot connect two "host" things to each other either. So you cannot connect type-B -> type-B or type-A -> type-A. So with earlier USB connector types this was clear. Now with type-C being used on both sides it is not clear from the connectors, but the regarding the hardware behind the connector it is still the same.

 

Mobile phones like iPhone have long had capability to switch their hardware between host and device modes. Many embedded SoC's (processors) have this capability. Thus you can find it from RPi4 and also from UP Gateway (which uses Atom model designed for mobile market). There are many other pieces of ARM-based hardware that have this capability, but it also depends whether also the board designer implemented support for this feature, as it needs to be taken into account when designing the PCB.

 

With type-C connector they also introduced  "alternate modes" which means the same connector can act as USB connector, DisplayPort connector, HDMI connector or Thunderbolt connector for example. This means handshake where the mode is chosen, and from that point on, the signalling on the cable totally changes depending on the mode. In addition type-C also brought high power charging modes through PD (Power Delivery) and similar standards that are now used by many laptops etc.

 

1 hour ago, bogi said:

The new functionality allows to use a different auto rate switching solution than the former one based on specific ADI products. Up Gateway and Pi4 owners don't need to buy these specific products to get auto rate switching but sound source is restricted to USB connected phone/tablet/computer.

 

Yes, these two ways complement each other depending on type of connectivity one prefers.

 

For straight S/PDIF or AES/EBU to Windows computer running HQPlayer Desktop, RME HDSPe AIO is still the simplest approach.

 

[Kalpesh]

does it make the Holo Red rather more or less (because my iPhone would do the input) desirable (if it's ever available anew) with the perspective to use it as Input for internet radios and Qobuz and Simultaneously as NAA output ?

[Miska]

2 hours ago, Kalpesh said:

does it make the Holo Red rather more or less (because my iPhone would do the input) desirable (if it's ever available anew) with the perspective to use it as Input for internet radios and Qobuz and Simultaneously as NAA output ?

 

At the moment you cannot use same NAA for both input and output. So if both ends are on a NAA, you need two NAA's.

 

[dericchan1]

@Miska

 

just to confirm for the new feature if I am running Hqplayer desktop windows version, it will not be able to detect the rpi4 running the hqplayer os.

 

i need to be running the Ubuntu desktop version?

 

thanks

 

Deric