Jump to content
IGNORED

HQPlayer's Network Audio Adapter


Recommended Posts

I tried the RME with a HummingBoard instead of the Cubox. The problem remained the same. So I am pretty sure the problem lies somewhere in the connection with the RME DAC.

 

A sidenote: the Cubox is driven from a 5V, 7A linear power supply, the HummingBoard from an ordinary 5V, 4A SMS, and there is a quite a bit of a difference between the two. The SMS driven path is a bit muffled, less open than the LPS path.

 

As I can connect the iFi iDSD micro to the RCA input of my active speakers, the RME is connected to the XLR input of the same speaker so very easy to compare the two DAC, cabling roughly the same Wireworld. The RME has more dynamics, more life and a but more engaging.

 

I like all the versions, with the iFi and with the RME ADI 2 Pro. The difference is not too big, the general character is similar, but on a longer term the RME should be a bit more entertaining. I think.

Link to comment

@Miska, I just tried NAA with a Cubox-i 4x4, and ran into trouble. HQPlayer initially sees the NAA, but as soon as I select a track to play, I get a short burst of loud white noise from my KEF X300A speakers, then HQPlayer quickly loses the connection to the Cubox, until I power cycle it. Net result is that I can't get the Cubox to play to my X300A speakers at all.

 

By comparison, my Raspberry Pi 3 running the 3.4.2 NAA image works flawlessly with the same X300A speakers.

 

Among Cubox-i 4x4, Beaglebone Black and Raspberry Pi 3, the latter is the only one that plays nice with the X300A. Any idea why?

Link to comment
@Miska, I just tried NAA with a Cubox-i 4x4, and ran into trouble. HQPlayer initially sees the NAA, but as soon as I select a track to play, I get a short burst of loud white noise from my KEF X300A speakers, then HQPlayer quickly loses the connection to the Cubox, until I power cycle it. Net result is that I can't get the Cubox to play to my X300A speakers at all.

 

By comparison, my Raspberry Pi 3 running the 3.4.2 NAA image works flawlessly with the same X300A speakers.

 

Among Cubox-i 4x4, Beaglebone Black and Raspberry Pi 3, the latter is the only one that plays nice with the X300A. Any idea why?

 

That sounds like a USB compatibility issue between USB host adapter and the USB device.

 

Sometimes this can also happen due to USB current drawn by the device, if it exceeds the current source limits of the host, it may cause disconnect (port power down) or voltage drop at the device side causing device side to get messed up and disconnect.

 

So you could check the PSUs used for CuBox-i and BBB first...

Signalyst - Developer of HQPlayer

Pulse & Fidelity - Software Defined Amplifiers

Link to comment
That sounds like a USB compatibility issue between USB host adapter and the USB device.

 

Sometimes this can also happen due to USB current drawn by the device, if it exceeds the current source limits of the host, it may cause disconnect (port power down) or voltage drop at the device side causing device side to get messed up and disconnect.

 

So you could check the PSUs used for CuBox-i and BBB first...

I think you are onto something here. Today I got the Cubox-i 4x4 to work flawlessly with my Auralic Vega DAC and another PCM1794 DAC. It looks like the trouble I'm having is specifically with the KEF X300A speakers with its integrated DAC.

 

Do you know if the same Linux driver for X300A is carried in the Linux distros for the various NAA images? Can the difference be down to the Linux driver for my X300A? BTW, even though the Cubox fails to play to the X300A, it still responds to pings over the network, so the OS has not crashed, but networkaudiod probably did.

 

The BBB issue as reported previously is a bit different. It can play initially, but after stopping a track and restarting or picking another track, HQPlayer will stop seeing the NAA and choke up. To ensure this is not a power supply related issue, I'll use the 5V 3A SMPS supplied with the Cubox on the BBB, and report the results.

Link to comment
Do you know if the same Linux driver for X300A is carried in the Linux distros for the various NAA images?

 

I would assume it is the same USB Audio Class driver on all. There are some minor changes in different Linux kernel versions, but from practical point of view it is the same driver as long as kernel versions are somewhat close to each other.

 

Can the difference be down to the Linux driver for my X300A? BTW, even though the Cubox fails to play to the X300A, it still responds to pings over the network, so the OS has not crashed, but networkaudiod probably did.

 

If you are willing to play a bit more with Linux, you could install Debian Stretch and then the networkaudiod package on that one and see if there are any hints in any of the logs.

 

See here:

http://ftp.nl.debian.org/debian/dists/testing/main/installer-armhf/current/images/hd-media/SD-card-images/

 

To ensure this is not a power supply related issue, I'll use the 5V 3A SMPS supplied with the Cubox on the BBB, and report the results.

 

That's probably the same or similar one I've been using for most of the testing. I have other PSUs too (my own linear ones), but to keep things consistent and easily reproducible I use the standard PSU for basic testing.

 

I just know from past experience that there are differences between PSUs that manifest when USB devices become active that in worst case cause device reboots if the PSU voltage drops in response to sudden current draw peak.

Signalyst - Developer of HQPlayer

Pulse & Fidelity - Software Defined Amplifiers

Link to comment

Here are some test results with the BBB. I switched power supply to an HP E3631A DC power supply set to 5.00V. The Vega DAC I'm using does not need power over USB. It is the only DAC I have that can work with USB +5V VBUS power disconnected by an SBooster VBus2 isolator.

 

With playback at 44.1K, the failure symptoms pretty much don't repro. I can stop playback and select another track without issue. I then tried upsampling to 352.8K. This is when the failures repro quite easily. Playback continues indefinitely as long as I don't click stop, but when I do, the next track selected will fail to play, and HQPlayer locks up and has to be manually terminated. Upon relaunching HQPlayer it no longer sees the NAA. The BBB is still responsive to network pings though.

 

Since I'm quite Linux illiterate I'm not sure I can install Debian & networkaudiod quickly.

 

Since the Raspberry Pi 3 as NAA seems to work well with my X300A, I'll just stick to this combo for now, and use the Cubox with my Vega or other DACs.

Link to comment

For people who definitely want to use HQPlayer on a multi-homed computer and have trouble getting HQPlayer discover the NAA (due to multicast routing issues), Linux route(8) man page has following documentation regarding multicast routing, you can use to enforce IPv4 multicast routing on certain interface (by default I believe it goes to the one with default route). The same can be varied for IPv6 too.

 

      route add -net 224.0.0.0 netmask 240.0.0.0 dev eth0
             This is an obscure one documented so people know how to  do  it.
             This  sets  all  of  the class D (multicast) IP routes to go via
             "eth0". This is the correct normal  configuration  line  with  a
             multicasting kernel.

Signalyst - Developer of HQPlayer

Pulse & Fidelity - Software Defined Amplifiers

Link to comment
For people who definitely want to use HQPlayer on a multi-homed computer and have trouble getting HQPlayer discover the NAA (due to multicast routing issues), Linux route(8) man page has following documentation regarding multicast routing, you can use to enforce IPv4 multicast routing on certain interface (by default I believe it goes to the one with default route). The same can be varied for IPv6 too.

 

      route add -net 224.0.0.0 netmask 240.0.0.0 dev eth0
             This is an obscure one documented so people know how to  do  it.
             This  sets  all  of  the class D (multicast) IP routes to go via
             "eth0". This is the correct normal  configuration  line  with  a
             multicasting kernel.

 

People in the other thread http://www.computeraudiophile.com/f10-music-servers/novel-way-massively-improve-sq-sms-200-and-microrendu-31110/ are using bridging connections (NICs) otherwise they were not able to use Linux based NAA.

 

What's better in your opinion? To enable multicast routing via route command or to set up the bridge?

i7 11850H + RTX A2000 Win11 HQPlayer ► Topping HS02 ► 2x iFi iSilencer ► SMSL D300 ► DIY headamp DHA1 ► HiFiMan HE-500
Link to comment
People in the other thread http://www.computeraudiophile.com/f10-music-servers/novel-way-massively-improve-sq-sms-200-and-microrendu-31110/ are using bridging connections (NICs) otherwise they were not able to use Linux based NAA.

 

What's better in your opinion? To enable multicast routing via route command or to set up the bridge?

 

Fixing the multicast routing of course, I've said it many times. But people need to understand if they want to get involved in advanced networking like using multi-homed computers, then they need to deal with extra effort involved in understanding advanced network configurations.

 

When you configure computer as a bridge you turn it into a poor switch, instead of that it is better to use a good separate switch rather than trying to emulate such with computer software... Switches have hardware specifically designed for doing this... In worst case the bridge in computer is forwarding all traffic between interfaces, even the traffic not destined to the other side, meaning instead of a switch you'd have a hub, and nobody in today's world use hubs anymore... ;)

Signalyst - Developer of HQPlayer

Pulse & Fidelity - Software Defined Amplifiers

Link to comment

@Miska, I already had that on Win10, this is my routing table:

 

IPv4 Route Table
===========================================================================
Active Routes:
Network Destination        Netmask          Gateway       Interface  Metric
         0.0.0.0          0.0.0.0      192.168.8.1    192.168.8.100     35
       127.0.0.0        255.0.0.0         On-link         127.0.0.1    331
       127.0.0.1  255.255.255.255         On-link         127.0.0.1    331
 127.255.255.255  255.255.255.255         On-link         127.0.0.1    331
     192.168.1.0    255.255.255.0         On-link       192.168.1.2    281
     192.168.1.2  255.255.255.255         On-link       192.168.1.2    281
   192.168.1.255  255.255.255.255         On-link       192.168.1.2    281
     192.168.8.0    255.255.255.0         On-link     192.168.8.100    291
   192.168.8.100  255.255.255.255         On-link     192.168.8.100    291
   192.168.8.255  255.255.255.255         On-link     192.168.8.100    291
       224.0.0.0        240.0.0.0         On-link         127.0.0.1    331
       224.0.0.0        240.0.0.0         On-link       192.168.1.2    281
       224.0.0.0        240.0.0.0         On-link     192.168.8.100    291
 255.255.255.255  255.255.255.255         On-link         127.0.0.1    331
 255.255.255.255  255.255.255.255         On-link       192.168.1.2    281
 255.255.255.255  255.255.255.255         On-link     192.168.8.100    291

 

192.168.1.2 is fixed address of HQPlayer computer interface to NAA (which has fixed address 192.168.1.1 in my case)

192.168.8.100 is address of my 4G USB dongle interface.

 

If I understood you well I have nothing to do because it is already configured ... Or do I have to do something also on the NAA side?

i7 11850H + RTX A2000 Win11 HQPlayer ► Topping HS02 ► 2x iFi iSilencer ► SMSL D300 ► DIY headamp DHA1 ► HiFiMan HE-500
Link to comment

But I had that routing configuration already yesterday ... and HQPlayer Desktop still cannot see the NAA computer.

 

I succeeded to get sound from my NAA computer this way:

I configured my NAA IPv4 for DHCP. On my HQPlayer notebook I selected my USB dongle (internet) interface | Properties | Sharing and here I selected my Ethernet interface. This way I shared internet connection for my NAA. According to Wikipedia "It makes use of DHCP and network address translation (NAT)".

 

In this mode my NAA was found by HQPlayer Desktop - both through IPv4 and IPv6. So I could play a test track through NAA.

 

Then, while playing music through Networkaudiod IPv6, I removed the internet connection sharing. With this IPv4 NAT was removed on HQPlayer computer Ethernet interface. Music still played through IPv6 NAA.

 

Now I stopped playback and restarted HQPlayer Desktop. I started play. Music still played. So the IPv6 of NAA was remembered in HQPlayer.That functioned till I restarted the NAA computer.

i7 11850H + RTX A2000 Win11 HQPlayer ► Topping HS02 ► 2x iFi iSilencer ► SMSL D300 ► DIY headamp DHA1 ► HiFiMan HE-500
Link to comment

Now about sound comparison Linux vs. Win10. I preferred the sound of Win10 NAA. With more clarity and a bit more dynamic impact it is for me more involving. The Win10 NAA brings me more feeling of 'I am with musicians in the same room'.

 

I like on Win10 NAA also the possibility to configure it through XMOS ASIO Control Panel, where I can set the Streaming Mode in 6 levels from Low Latency on top to Extra Safe on bottom. The upper settings (Low Latency, Standard) bring more detailed sound, but may be more prone to buffer underruns and with some recordings they may sound fatiguing. The the direction to bottom settings sound is more and more relaxed, rounded, but some detail is lost.

 

If all goes without any issue, Linux NAA can be set up very quickly. Especially when prepared NAA image is available - in such a case there is no need for OS + application installation. Windows OS cannot be distributed in such a form, so OS installation is always required. I stripped down Windows OS to run only necessary processes and services, but that is nonstandard unofficial thing and requires some Windows OS related knowledge. This forum contains nice thread dedicated to this topic: Windows 10 optimization script - A community effort?

 

The Linux version advances also in lower hardware requirements. 2GB flash memory is enough for stripped down Debian. Windows 10 OS requires about 10 GB + some free space is recommended.

i7 11850H + RTX A2000 Win11 HQPlayer ► Topping HS02 ► 2x iFi iSilencer ► SMSL D300 ► DIY headamp DHA1 ► HiFiMan HE-500
Link to comment
I like on Win10 NAA also the possibility to configure it through XMOS ASIO Control Panel, where I can set the Streaming Mode in 6 levels from Low Latency on top to Extra Safe on bottom. The upper settings (Low Latency, Standard) bring more detailed sound, but may be more prone to buffer underruns and with some recordings they may sound fatiguing. The the direction to bottom settings sound is more and more relaxed, rounded, but some detail is lost.

 

Those just change the driver parameters, IOW how much RAM buffer the driver has, but it doesn't change how data goes over USB. With Linux based NAA you can adjust the corresponding buffer size from HQPlayer (the "Buffer time" setting). Same also with WASAPI backend, plus some ASIO drivers (varies case by case). But it really shouldn't affect sound, apart from drop-out sensitivity perspective.

 

Default for NAA is 100 ms and I recommend keeping it that way because it means the buffer rate is 10 Hz, keeping it below audible frequencies and CPU operating at relaxed pace. Low latency settings make the buffer rate higher and for example 1 ms buffer would mean 1 kHz buffer frequency moving it right into most sensitive hearing frequencies and waking up CPU 100 times more frequently.

 

USB Audio Class has fixed packet interval of 125 µs landing the packet noise at 8 kHz. So the buffer settings don't affect this part.

Signalyst - Developer of HQPlayer

Pulse & Fidelity - Software Defined Amplifiers

Link to comment
Those just change the driver parameters, IOW how much RAM buffer the driver has, but it doesn't change how data goes over USB. With Linux based NAA you can adjust the corresponding buffer size from HQPlayer (the "Buffer time" setting). Same also with WASAPI backend, plus some ASIO drivers (varies case by case). But it really shouldn't affect sound, apart from drop-out sensitivity perspective.

 

Windows XMOS ASIO Control Panel enables separately to set 2 things:

- Streaming Mode in 6 levels

- Buffer size

 

The Streaming Mode setting has clear affect on sound as I described. Linux can maybe adjust the buffer size, but probably not the streaming mode.

 

I didn't wrote that other bits are coming to DAC! I wrote that the setting affects sound quality. What should affect sq and what not and why some differences can be heard is another story. In ideal case all bitperfect digital outputs should sound the same. We know that generally noise/jitter affects sound. We know that bitferect outputs through different players or digital converters may sound differently. I will not tell you why, I am only telling that the Streaming Mode in Windows XMOS ASIO Control Panel clearly affects sound quality and that I don't have that setting available on Linux.

i7 11850H + RTX A2000 Win11 HQPlayer ► Topping HS02 ► 2x iFi iSilencer ► SMSL D300 ► DIY headamp DHA1 ► HiFiMan HE-500
Link to comment

- Streaming Mode in 6 levels

- Buffer size

 

The Streaming Mode setting has clear affect on sound as I described. Linux can maybe adjust the buffer size, but probably not the streaming mode.

 

That "Streaming Mode" only deals with Thesycon's driver's internal RAM buffering. There's no such thing as "Streaming Mode" with the USB Audio Class it implements towards USB.

 

I will not tell you why, I am only telling that the Streaming Mode in Windows XMOS ASIO Control Panel clearly affects sound quality and that I don't have that setting available on Linux.

 

You don't have that setting anywhere else except Thesycon driver implementation, because it's their own concept and only relates to how the driver does it's on RAM buffering. Not how things go over USB...

 

Only difference I've seen it make it limits the range of available buffer sizes. I think that's all it does. For iFi DACs running in DSD it needs to be set to safest mode to allow largest possible buffer size which is still a bit too small for 705.6/768k PCM and DSD512, because obviously the available buffer sizes were originally designed only up to 192k PCM.

 

Another annoying PITA with the Thesycon driver is that it doesn't expose 48k-base native DSD rates. Which luckily work great on Linux. So on Linux I can run my iDSD Micro's at 24.576 MHz DSD rate without problems. Not on other platforms.

Signalyst - Developer of HQPlayer

Pulse & Fidelity - Software Defined Amplifiers

Link to comment
You don't have that setting anywhere else except Thesycon driver implementation, because it's their own concept and only relates to how the driver does it's on RAM buffering.

Then that RAM buffering affects sound. :) I like that setting because it affects sound in 6 steps from "smallest grain, very detailed" to "bigger grain, very relaxed, some low level detail lost".

 

Another annoying PITA with the Thesycon driver is that it doesn't expose 48k-base native DSD rates.

 

Yes I know, we discussed that already. My DAC is only DoP capable and therefore I didn't know about that Thesycon limitation before. 48k DSD rates function well with DoP. With HQP 3.15.1 I am often using the xtr filters going to 6.1MHz. For DSD upsampling I can use the non 2s versions and for PCM upsampling I am using the 2s versions.

i7 11850H + RTX A2000 Win11 HQPlayer ► Topping HS02 ► 2x iFi iSilencer ► SMSL D300 ► DIY headamp DHA1 ► HiFiMan HE-500
Link to comment
Only difference I've seen it make it limits the range of available buffer sizes. I think that's all it does.

 

I don't think so ... Then Streaming Mode wouldn't cause such change in sound. Buffer sizes affect sound very very little, it is much harder to observe. Therefore I mean that the word mode has some meaning and doesn't mean size.

i7 11850H + RTX A2000 Win11 HQPlayer ► Topping HS02 ► 2x iFi iSilencer ► SMSL D300 ► DIY headamp DHA1 ► HiFiMan HE-500
Link to comment
Then that RAM buffering affects sound. :) I like that setting because it affects sound in 6 steps from "smallest grain, very detailed" to "bigger grain, very relaxed, some low level detail lost".

 

Some fixing needed on the DAC side USB interface then... ;) You see why I have such dislike for USB? Would be interesting to check the DAC output with audio analyzer. Anyway my recommendation is to use buffer size that keeps the buffer rate below 20 Hz.

 

I don't hear any difference with buffer size settings on iFi DACs except of course if there are drop-outs. Rarely when I use iFi on Windows, I use the biggest buffer size available because otherwise heavy computer load will cause drop-outs. So the "mode" is set to "safest". But the 8 kHz packet rate is detectable from the DAC output.

 

There's quite a bunch of ASIO drivers that use fixed non-adjustable buffer size like Amanero for example. For those Linux is better because it gives some flexibility.

Signalyst - Developer of HQPlayer

Pulse & Fidelity - Software Defined Amplifiers

Link to comment
Some fixing needed on the DAC side USB interface then... ;) Would be interesting to check the DAC output with audio analyzer. Anyway my recommendation is to use buffer size that keeps the buffer rate below 20 Hz.

 

I tend to use the smallest buffer sizes possible. With some harsh recordings the shortest buffer sizes may sound a aggressive, because they may reveal that harshness more in detail, although apodizing filters to higher rate DSD may do good job on that.

 

When I set the Streaming Mode to Low Latency or Standard, then I have all or almost all buffer sizes available. Searching for sound differences between buffer sizes isn't easy task. Coming from sometimes noisy environment at work and attempting to find them means no chance for me. But on very late evenings, when I am already hours in quiet environment, I came to result that shorter buffer sizes bring a very small amount of increased clarity and detail. But ... take it rather as an impression, because I don't think I could hear such a difference anytime.

 

The change between streaming modes is clearly bigger for me. I have no doubt that it really exists. The biggest chance to observe any sonic differences is with Low Latency streaming mode because it brings most detail and thus makes any comparison easier.

 

I know all what I wrote is subjective, it isn't a measurement. But I own my DAC already 3 years and I compared these settings many times. Sometimes I change settings to adapt to recording.

i7 11850H + RTX A2000 Win11 HQPlayer ► Topping HS02 ► 2x iFi iSilencer ► SMSL D300 ► DIY headamp DHA1 ► HiFiMan HE-500
Link to comment

I agree with bogi. On my micro iDSD, changing from Safe to Low Latency resulted in a very noticeable increase in clarity. I was just using the Qobuz desktop app streaming 16/44.1 FLAC. It worked well with classical chamber music.

Pareto Audio AMD 7700 Server --> Berkeley Alpha USB --> Jeff Rowland Aeris --> Jeff Rowland 625 S2 --> Focal Utopia 3 Diablos with 2 x Focal Electra SW 1000 BE subs

 

i7-6700K/Windows 10  --> EVGA Nu Audio Card --> Focal CMS50's 

Link to comment
I tend to use the smallest buffer sizes possible. With some harsh recordings the shortest buffer sizes may sound a aggressive, because they may reveal that harshness more in detail, although apodizing filters to higher rate DSD may do good job on that.

 

That harshness/sharpness is then probably leakage of the buffer rate, smaller buffer sizes bring the frequency up to audible range.

 

I'm really allergic to any harshness that many PCM systems put out due to image frequency leakage. A bit like my old Marantz CD-60 player did (SAA7220 4x digital filter and TDA1541A DAC). Clean signal sounds smooth and clean yet still extremely precise and detailed at the same time, with sharp attacks without "trash" or "fuzz" edge glare. Kind of stuff you get with good DAC and DS512.

Signalyst - Developer of HQPlayer

Pulse & Fidelity - Software Defined Amplifiers

Link to comment
That harshness/sharpness is then probably leakage of the buffer rate, smaller buffer sizes bring the frequency up to audible range.

Sorry I read again what I wrote and I found I wasn't enough clear so no wonder I confused you a bit with my preference of lower buffer sizes. I didn't mean any general harshness of my setup. I didn't observe that in relation to low buffer sizes (which are possible only with Low Latency and Standard streaming modes - that I forget to mention). Good recordings sound me very well this way. I meant the special case of wrong recordings. So the harshness I mentioned is related only to such recordings. Less detailed setup (for example the Safe streaming modes) can masks shortcomings of these recordings so they may be easier listenable. More detailed setup (Low Latency or Standard streaming mode) may cause these recordings to be harder listenable. That's what I wanted to say. Sorry I wasn't enough clear.

 

However, it is interesting that according to you lower buffer sizes mean higher frequency of their operation, which falls into audible range and thus under some circumstances could have audible effect.

i7 11850H + RTX A2000 Win11 HQPlayer ► Topping HS02 ► 2x iFi iSilencer ► SMSL D300 ► DIY headamp DHA1 ► HiFiMan HE-500
Link to comment
However, it is interesting that according to you lower buffer sizes mean higher frequency of their operation, which falls into audible range and thus under some circumstances could have audible effect.

 

If we for example calculate following...

 

1024 sample buffer, 384 kHz sampling rate. That is 1024 / 384000 = 2.7 ms, driver buffer switching interval. If we look at as buffer switch frequency 1 / (1024 / 384000) = 375 Hz. This also corresponds to 48k-base DSD128 over DoP (6.1 MHz, since that's the PCM container).

 

So for 128 sample buffer figures are 333 µs and 3 kHz. But Windows will have trouble keeping up with that kind of scheduling rate. Anything below 1 ms will cause lot of variation in terms of percentage of the interval.

Signalyst - Developer of HQPlayer

Pulse & Fidelity - Software Defined Amplifiers

Link to comment

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now



×
×
  • Create New...