HQ Player

[bogi]

25 minutes ago, woshifeng3627 said:

Hello, @Miska, have you heard about the newly launched Singxer SDA-6 PRO2 DAC? Their DAC provides the NOS switch for DSD, but it doesn't seem to have the DSD filter option. They also said that in NOS mode, it can support DSD512 passthrough and 48KDSD passthrough mode. I said A26 also uses the same chip components. Why can A26 only bypass DSD under DSD128-256, while yours can support DSD512 passthrough mode, They said it's because the SDA-6 PRO2 DAC has been developed more completely, so in NOS mode, it supports DSD64-512 through the DSD bypass channel. If it's an IIS input, it also supports DSD1024. Then I thought of what you once said, AKM4191+4499EX chip components can only bypass DSD under DSD128-256. So I'm a bit confused now. Is it really due to the chip that it can't support DSD512 to go through the DSD bypass channel?

 

AK4191EQ supports DSDD bit = "1" (direct DSD) at DSD512, but Gustard products don't have it implemented.

 

[bogi]

23 minutes ago, dericchan1 said:

Thats not true in our scenario as we are trying to go from the input NAA of the RPI to your hqplayer desktop pc - that requires usb connection 

I didn't mean it that way. My scenario is:

 

[iOS or Android phone running UPnP Control Point app] ---WiFi LAN---> [RPi NAA] <---LAN---> [HQPlayer computer]

 

On RPi, UPnP Renderer standard (master) USB output should be connected to NAA device type (slave) USB input.

RPi NAA can then act both as input NAA for UPnP Rendeder as well as output NAA for DAC.

 

That's exactly what was discussed
here: https://audiophilestyle.com/forums/topic/19715-hq-player/?do=findComment&comment=1273212
and here: https://audiophilestyle.com/forums/topic/19715-hq-player/?do=findComment&comment=1272939

 

[dericchan1]

1 minute ago, bogi said:

I didn't mean it that way. My scenario is:

 

[iOS or Android phone running UPnP Control Point app] ---WiFi LAN---> [RPi NAA] <---LAN---> [HQPlayer computer]

 

On RPi, UPnP Renderer standard (master) USB output should be connected to NAA device type (slave) USB input.

RPi NAA can then act both as input NAA for UPnP Rendeder as well as output NAA for DAC.

@Miska Perhaps Miska can confirm this but it seems like its missing a step where the NAA needs to go USB out to HQplayer computer as a "Input device" 

[bogi]

20 minutes ago, dericchan1 said:

Perhaps Miska can confirm this but it seems like its missing a step where the NAA needs to go USB out to HQplayer computer as a "Input device"

No ... I updated my previous post with 2 links to previous posts, one of them is confirmed by Miska. My scenario is expected to work but yours cannot - not possible on usual computer and with HQPlayer Desktop.

HQPlayer Desktop does not have slave type USB input capability because usual computers don't contain slave type USB ports. The required hardware is simply missing on our computers. Rpi, upBoard and some Intel NUC are known to contain such a hardware, since these mini PCs are often used as headless for automation purposes, implementing a specific kind of device. Hardware requirement is one part but without software support (something like USB device firmware) it wouldn't work either. Miska implemented that software part only to NAA and HQPlayer Embedded, so it is Linux only.

 

As soon as input data from UPnP Rendered enters input NAA, standard LAN connection is the right choice to transfer that data to HQPlayer Desktop.

[woshifeng3627]

30 minutes ago, bogi said:

 

AK4191EQ 在 DSD512 上支持 DSDD 位 = “1”（直接 DSD），但 Gustard 产品没有实现它。

 

 

 

It seems that if there is a chance, I also need to consider whether to switch to SDA-6 PRO2 DAC, haha! We also look forward to you or anyone who can obtain the DAC and test the data to see if it is better.

[dericchan1]

21 minutes ago, bogi said:

No ... I updated my previous post with 2 links to previous posts, one of them is confirmed by Miska. My scenario is expected to work but yours cannot - not possible on usual computer and with HQPlayer Desktop.

HQPlayer Desktop does not have slave type USB input capability because usual computers don't contain slave type USB ports. The required hardware is simply missing on our computers. Rpi, upBoard and some Intel NUC are known to contain such a hardware, since these mini PCs are often used as headless for automation purposes, implementing a specific kind of device. Hardware requirement is one part but without software support (something like USB device firmware) it wouldn't work either. Miska implemented that software part only to NAA and HQPlayer Embedded, so it is Linux only.

 

As soon as input data from UPnP Rendered enters input NAA, standard LAN connection is the right choice to transfer that data to HQPlayer Desktop.

Sorry I will have to disagree with this because this is exactly what I am doing at the moment and it works - using a RPI4 as a input NAA, USB out to my Hqplayer desktop PC and recognize the RPI4 as a USB input device under the "inputs" settings in the input menu as a "USB RPI4. As a matter of fact I don't think it is even possible to do as you suggested, going from RPI4 to Hqplayer PC through LAN. 

 

I could be wrong but I don't think that will work. (it would actually be better if I can use LAN connection from RPI4 input NAA to Hqplayer )PC

[bogi]

@dericchan1

 

What's on your picture is possible but it's not the main intended case presented when this functionality was new. What Miska presented was a streaming solution with auto rate switching support:
a) [iPad running Apple Music] ---USB---> [Pi4 as input NAA] ---LAN---> [HQPlayer]

b) [iPad running Apple Music] ---USB---> [HQP Embedded on Pi4 with specific input URI]
In both these base usage scenarios data flows from master device (iPad) to NAA or HQP Embedded in slave USB mode.

On your picture data flows from input NAA to HQPlayer Desktop computer. Nobody discussed such a case since the feature was introduced and therefore it is surprising.

NAA has device side connected through audio interface and HQPlayer side connected through LAN. Both sides of NAA connection have to be set up to create a reasonable use case.

 

You showed that HQPlayer sees your input NAA, but you are unable to use it in any way. Because you occupy the device side of NAA with your HQPlayer computer. Your HQPlayer side of NAA is missing:

[bogi]

  

@dericchan1 You agreed with me and Miska, since you wrote:

Quote

- Use a USB-C cable and connect the RPI5 USB-C port to the same RPI5 USB-A port as a loopback

 

That's the point where the USB input magic with auto rate switching already happens! :) If that's in use, one input NAA is already in use!

[dericchan1]

21 minutes ago, bogi said:

@dericchan1

 

What's on your picture is possible but it's not the main intended case presented when this functionality was new. What Miska presented was:
a) [iPad running Apple Music] ---USB---> [Pi4 as input NAA] ---LAN---> [HQPlayer]

b) [iPad running Apple Music] ---USB---> [HQP Embedded]
In both these base usage scenarios data flows from master device (iPad) to NAA or HQP Embedded in slave USB mode.

On your picture data flows from input NAA to HQPlayer Desktop computer. Nobody discussed such a case since the feature was introduced and therefore it is surprising.

NAA has device side connected through audio interface and HQPlayer side connected through LAN. Both sides of NAA connection have to be set up to create a reasonable use case.

 

You showed that HQPlayer sees your input NAA, but you are unable to use it in any way. Because you occupy the device side of NAA with your HQPlayer computer. Your HQPlayer side of NAA is missing:

I believe Miska presented was 

a) ipad running apple music --- USB ---> (Pi4 as input NAA through USB-C) ---USB ---> HQplayer. 

The Pi4 input NAA is where the USB switching to slave and automatic sampling rate happens but it needs USB connection to HQplayer not LAN because otherwise your Windows Desktop PC running HQplayer will not be able recognize the input device.

 

b) ipad running apple music will still need to go through a Pi4 as input NAA --- USB ---> HQP Embedded 

 

So essentially a and b goes through the same flow because consistently you still need a Pi4 as input NAA to switch to USB slave mode and input sampling

[dericchan1]

8 minutes ago, bogi said:

  

@dericchan1 You agreed with me and Miska, since you wrote:

 

That's the point where the USB input magic with auto rate switching already happens! :) If that's in use, one input NAA is already in use!

@bogi can you give your proposed configuration a try and report back? 

I could be confused but it does not sound like its going to work. Lets even ignore the upnp control point and renderer for now.

 

Just take an ipad or any source device, usb out to a pi4 NAA input, then you can try output from LAN to your HQP Desktop laptop/PC and see if HQP Desktop recognize the input NAA?

[bogi]

@dericchan1 You may believe but you cannot make it working since such a thing like NAA connected by USB from both sides was not implemented. Look at this post: https://audiophilestyle.com/forums/topic/19715-hq-player/?do=findComment&comment=1264581

Miska mentions source device as phone/tablet running for example Apple Music. The specific NAA USB input mode is used for this connection and NOT for HQPlayer computer. HQPlayer computer was not mentioned because that side of NAA was not affected by the new functionality. NAA still needs network connected HQPlayer and will not function without it.

[bogi]

1 hour ago, dericchan1 said:

@bogi can you give your proposed configuration a try and report back? 

 

https://audiophilestyle.com/forums/topic/19715-hq-player/?do=findComment&comment=1273242

That's with the USB loopback I proposed. That loopback works like when two computers would be connected through the USB cable. But Rpi is used at both ends - audio source (UPnP Renderer app) and USB input device (networkaudiod). The loopback trick is used to preserve auto rate switching and to present the UPnP Renderer as input NAA to HQPlayer computer.

More usual use cases are a) and b) I mentioned in one of my above posts.

An example of a usual case, where you also see what's LAN:
https://community.roonlabs.com/t/using-any-audio-source-with-hqplayer-spotify-amazon-apple-music-youtube-music-deezer-soundcloud-2023/244358/434

[dericchan1]

24 minutes ago, bogi said:

 

https://audiophilestyle.com/forums/topic/19715-hq-player/?do=findComment&comment=1273242

That's with the USB loopback I proposed. That loopback works like when two computers would be connected through the USB cable. But Rpi is used at both ends - audio source (UPnP Renderer app) and USB input device (networkaudiod). The loopback trick is used to preserve auto rate switching and to present the UPnP Renderer as input NAA to HQPlayer computer.

More usual use cases are a) and b) I mentioned in one of my above posts.

An example of a usual case, where you also see what's LAN:
https://community.roonlabs.com/t/using-any-audio-source-with-hqplayer-spotify-amazon-apple-music-youtube-music-deezer-soundcloud-2023/244358/434

Thanks, you are correct that NAA input connect to HQP desktop PC through LAN, I unplugged the USB cable between Input NAA to HQP desktop and it still works.

 

 

[bogi]

@dericchan1  IIRC it is BIOS where the USB port role is to be set to slave (peripheral device). Do you remember how did you switch your USB port to peripheral device (slave) role?

[dericchan1]

23 minutes ago, bogi said:

@dericchan1  IIRC it is BIOS where the USB port role is to be set to slave (peripheral device). Do you remember how did you switch your USB port to peripheral device (slave) role?

I don't need to do anything to switch USB port to slave role. 

But maybe for the loopback configuration will need to set the USB A port to slave on the RPI

[bogi]

16 minutes ago, dericchan1 said:

I don't need to do anything to switch USB port to slave role.

 

In December before Christmas you connected your Lenovo touchscreen laptop to a rpi4 NAA, I suppose it was USB connection. Was there really no need to switch the Pi4 USB port to act as device type port??

[dericchan1]

3 minutes ago, bogi said:

I found on Dec 22 you connected your Lenovo touchscreen laptop to a rpi4 NAA, I suppose it was USB connection. Was there really no need to switch the Pi4 USB port to act as device type port??

Nope, that was my first attempt. Lenovo laptop usb to usb-c of RPI4 input NAA. I was playing with windows amazon HD and Qobuz app to Hqplayer 

 

The only thing you need to do is in the NAA image config file to set USB to peripheral.

 

 

[bogi]

13 minutes ago, dericchan1 said:

The only thing you need to do is in the NAA image config file to set USB to peripheral.

Then maybe Pi4 and UPboard differ in this regard ...
Look at the last paragraph: https://community.roonlabs.com/t/using-any-audio-source-with-hqplayer-spotify-amazon-apple-music-youtube-music-deezer-soundcloud-2023/244358/504

 

EDIT: I found it ... Raspberry Pi uses a configuration file config.txt instead of BIOS

[dericchan1]

12 minutes ago, bogi said:

Then maybe Pi4 and UPboard differ in this regard ...
Look at the last paragraph: https://community.roonlabs.com/t/using-any-audio-source-with-hqplayer-spotify-amazon-apple-music-youtube-music-deezer-soundcloud-2023/244358/504

 

EDIT: I found it ... Raspberry Pi uses a configuration file config.txt instead of BIOS

Yup, that's what I had to do. Now the question is I thought in the config.txt you choose either host VS peripheral. I wonder if you can set it to enable both.

[bogi]

14 minutes ago, dericchan1 said:

Now the question is I thought in the config.txt you choose either host VS peripheral. I wonder if you can set it to enable both.

I think you set only one of the ports this way, since it requires specific hardware.
It looks it is the USB C port: "The legacy USB 2 controller is still available on the USB-C power connector for use as a device (otg_mode=0, the default)." Then all other USB ports act as usual computer ports.

 

This confirms it: https://raspberrypi.stackexchange.com/questions/100583/where-is-the-usb2-otg-port-on-the-rpi-4-model-b-located

[dericchan1]

2 minutes ago, bogi said:

I think you set only one of the ports this way, since it requires specific hardware.
It looks it is the USB C port: "The legacy USB 2 controller is still available on the USB-C power connector for use as a device (otg_mode=0, the default)." Then all other USB ports act as usual computer ports.
 

Agreed. The USB c port is the only OTG port on the RPI4/RPI5 that can be switched between device and host

[Miska]

10 hours ago, merterxx said:

Hi @Miska i will upgrade my cpu to 13700k for dsd1024. Will i need to contact with you for licence fingerprint? 

 

If you have HQPlayer Embedded and change the CPU, then yes.

 

[Miska]

8 hours ago, dericchan1 said:

@Miska Is this something that we can already do right now or it require some further work/changes on your end maybe in future releases?

 

It should work already.

 

8 hours ago, dericchan1 said:

I think essentially what me and @bogi were thinking would be to:

- UPNP control app (bubbleupnp, jplay iOS, mconnect to

- RPI5 with bookworm running a UPNP server/renderer app (i.e. jriver, upmpdcli, maybe plex or even kodi?)

 

This is kind of pointless, since HQPlayer Embedded supports UPnP already directly.

 

8 hours ago, dericchan1 said:

- Use a USB-C cable and connect the RPI5 USB-C port to the same RPI5 USB-A port as a loopback

 

You will need a USB-C dock with USB PD support since RPi5 is powered by the USB-C port. Or alternative power feed to the RPi5, such as through it's hat connector, such as PoE hat.

 

You would likely want to use RPi4 instead, since that is more well tested and has less troubles.

 

8 hours ago, dericchan1 said:

- Same RPI5 also running networkaudiod and change config to allow the RPI5 as BOTH NAA input AND output (Is there a .xml config file for networkaudiod?)

 

NAA v5 supports any number of simultaneous inputs and outputs. So yes, you can do both input and output at the same time with a single NAA.

 

8 hours ago, dericchan1 said:

- Same RPI5 USB A out to a HQPlayer desktop PC (Or can the same RPI5 also run HQplayer desktop as well?)

 

You can run HQPlayer Desktop on the RPi5 as well, but I would rather use HQPlayer Embedded there. Then you don't need to do complex extra hassle to support UPnP.

 

[dericchan1]

1 minute ago, Miska said:

 

It should work already.

 

 

This is kind of pointless, since HQPlayer Embedded supports UPnP already directly.

 

 

You will need a USB-C dock with USB PD support since RPi5 is powered by the USB-C port. Or alternative power feed to the RPi5, such as through it's hat connector, such as PoE hat.

 

You would likely want to use RPi4 instead, since that is more well tested and has less troubles.

 

 

NAA v5 supports any number of simultaneous inputs and outputs. So yes, you can do both input and output at the same time with a single NAA.

 

 

You can run HQPlayer Desktop on the RPi5 as well, but I would rather use HQPlayer Embedded there. Then you don't need to do complex extra hassle to support UPnP.

 

Thanks Miska, you have given me some new hopes to experiment further on this!!! Cheers

[Miska]

8 hours ago, woshifeng3627 said:

Hello, @Miska, have you heard about the newly launched Singxer SDA-6 PRO2 DAC? Their DAC provides the NOS switch for DSD, but it doesn't seem to have the DSD filter option. They also said that in NOS mode, it can support DSD512 passthrough and 48KDSD passthrough mode.

 

If they implemented it according to the AKM documentation, it is not going to work as advertised. This is because the AKM chip set and documentation is buggy and incorrect.

 

So someone needs to verify such functionality by measurements first before trusting the functionality actually works as advertised.

 

8 hours ago, woshifeng3627 said:

Why can A26 only bypass DSD under DSD128-256

 

Because the AK4499EX chip can operate only at 5.6 or 11.3 MHz. DSD512 is not going to be direct.

 

8 hours ago, woshifeng3627 said:

They said it's because the SDA-6 PRO2 DAC has been developed more completely, so in NOS mode, it supports DSD64-512 through the DSD bypass channel.

 

I believe it when I measure it. For example SMSL couldn't fix their implementation.

 

8 hours ago, woshifeng3627 said:

Is it really due to the chip that it can't support DSD512 to go through the DSD bypass channel?

 

Yes...