HQ Player

[Miska]

54 minutes ago, bibo01 said:

I haven't seen/used it yet. Do you implement a GUI in order to use Aneman?

 

ANEMAN is a GUI by Merging and can be used to manage the connections.

 

RAVENNA driver comes with a simple web interface for managing some of the settings.

 

[ted_b]

5 hours ago, SwissBear said:

And I have to say that my listening experience matches this understanding.

+1  My Su-1 has always had slightly better sq than going direct USB to the Holo, but since updating the ASIO drivers (both) the gap is narrowed quite a bit.  Weird stuff.  :)

[Miska]

3 hours ago, Ipoci said:

Direct connection could be useful when source HQPD has two separate Ethernet interfaces one for "normal" network access (cable or wifi with DHCP server somewhere) and the other as a straight cable to NAA (catX or fiber optical). In my case I use a MacBookPro that reads audio files locally on SSD or from NAS by accessing home network via WiFi, then I use a straight Fiber Optical cable to send audio stream to NAA, Mac and NAA use very tiny 100-X media converters (3M Volition) that have the beauty to be powered by 5V provided by any USB port ... 
 

 

It is not recommended or supported to use two separate ethernet connections. Everything is supposed to be connected to the regular home network that has a central switch. Optical link should be between the switch and NAA. Many switches have SFP ports for optical modules.

 

[Miska]

5 hours ago, SwissBear said:

It is the interface which does the translation of the 10 MHz clock signal and the clock signal to be used by the DAC. Singxer has a good expertise in this field.

 

That translation is the problem. Benefit of some high quality clock is lost at that point, unless the crystal oscillator inside the DAC is really really poor...

 

5 hours ago, SwissBear said:

where the DAC would follow the clock signal received together with the music flow

 

You see that is the problem. The clock should be going the other way, from DAC to the source.

 

5 hours ago, SwissBear said:

the PLL can be disconnected as well

 

PLL could partially fix the pollution from external clock.

 

5 hours ago, SwissBear said:

My understanding is that i2s has brought a lower level of interface to the DACs which allows better use of external clocks.

 

I would be curious to see J-test measurements of DAC output with internal/external clocks.

 

[Account Closed]

1 hour ago, ted_b said:

+1  My Su-1 has always had slightly better sq than going direct USB to the Holo, but since updating the ASIO drivers (both) the gap is narrowed quite a bit.  Weird stuff.  :)

Ted, Have you updated the USB card in your Spring DAC (if I remember you had the older one)? Also, make sure that if you replace the card that you update the drivers for the new card. You can order the new card from Tim at Kitsune. I used to use the SU-1 and I2S as well but with the updated drivers on my Spring 2 KTE (which came with the latest USB card), I found the USB was now better than I2S so I put my fancy silver HDMI cable in my video system and retired the SU-1 to my bedroom system to feed my old ML390s up there. Worth the small price to try.  Bob

[giordy60]

2 hours ago, Miska said:

 

It is not recommended or supported to use two separate ethernet connections. Everything is supposed to be connected to the regular home network that has a central switch. 

 

 

can you explain this step better?

I use a server with 2 network ports .... one on naa and one on switch for roon / tidal ...
am I wrong something maybe?

[Miska]

10 minutes ago, giordy60 said:

can you explain this step better?

I use a server with 2 network ports .... one on naa and one on switch for roon / tidal ...
am I wrong something maybe?

 

If it works, you can keep doing it, but it is not recommended, for one reason because it makes multicast routing a nightmare.

 

I have number of servers with two ethernet ports on the motherboard too. Where I just disable the second one since it is not needed.

 

Everything is connected to one of my switches, which are organized in typical star-like topology. There are three central switches at the main patch bay in the machine room. Then each room has one or two CAT6 wall sockets from this machine room, and a switch connected to the wall socket(s) (one can trunk two cables for double bandwidth). And all equipment in the room is connected to the room specific switch. WiFi access points are PoE powered running from cables from the machine room PoE switch which provides power to those. So only one cable needed for both power and data for the WiFi AP's.

 

QoS takes care that more urgent traffic has higher priority in the computer network stack and switch packet queues.

 

Central switches are for example Cisco SG350 series, and room specific switches are for example HPE/Aruba 1920S series. WiFi access points are also from HPE/Aruba.

 

[giordy60]

Jussi, thanks for the explanation.

 

[SwissBear]

2 hours ago, Miska said:

I would be curious to see J-test measurements of DAC output with internal/external clocks.

 

What kind of equipment would I need to make such measurements ? APx555B at 30'000+ US or is there a cheaper strategy to make such measurements ?

[Miska]

54 minutes ago, SwissBear said:

What kind of equipment would I need to make such measurements ? APx555B at 30'000+ US or is there a cheaper strategy to make such measurements ?

 

That or Prism (now called Spectral Measurement) dScope will do.

 

[LoryWiv]

11 hours ago, SwissBear said:

Thank you for your explanations.

 

It is the interface which does the translation of the 10 MHz clock signal and the clock signal to be used by the DAC. Singxer has a good expertise in this field.

 

The x-Sabre has a mode, called synchronous, which can be selected through the interface, where the DAC would follow the clock signal received together with the music flow;  the PLL can be disconnected as well. 

In the case of the D90, the technical support of Topping mentioned that the DAC would have the same behaviour if fed through the i2s interface.

 

My understanding is that i2s has brought a lower level of interface to the DACs which allows better use of external clocks. And I have to say that my listening experience matches this understanding.

Yes, @Swiissbear experience parallels my own with PC USB to Singxer SU-1 then I2S to X-Sabre DAC (using synchronous mode on the X-Sabre) producing the most musically satisfying results..

[ted_b]

4 hours ago, bobflood said:

Ted, Have you updated the USB card in your Spring DAC (if I remember you had the older one)? Also, make sure that if you replace the card that you update the drivers for the new card. You can order the new card from Tim at Kitsune. I used to use the SU-1 and I2S as well but with the updated drivers on my Spring 2 KTE (which came with the latest USB card), I found the USB was now better than I2S so I put my fancy silver HDMI cable in my video system and retired the SU-1 to my bedroom system to feed my old ML390s up there. Worth the small price to try.  Bob

Bob,

Thanks!  It was on my to-do list at some point, then it vanished.  But your prompting helped me order the newer USB module from Tim just hours ago.   👍  I realize my Spring 1 is a dinosaur but it's very musical and will remain in my RAAL stack (worst case) if I end up with a May or some other 32fs R2R/one-bit hybrid dac for the main room. 

[Gavin1977]

Is it a bug with HQPlayer embedded that every time you change the DAC/settings on the configuration page that a reboot is required?  I find that unless I physically reboot the server that HQPlayer as a upnp renderer disappears until after the reboot has completed.

[elan120]

When I change settings on configuration page, I only need to click the "apply" icon and it will go to another screen prompting you to wait 10 seconds before it will switch back to configuration page, and it is ready to play.  Never have to reboot in order to work.

[Gavin1977]

31 minutes ago, elan120 said:

When I change settings on configuration page, I only need to click the "apply" icon and it will go to another screen prompting you to wait 10 seconds before it will switch back to configuration page, and it is ready to play.  Never have to reboot in order to work.

Yeah, I’ve always had to reboot.

[Miska]

If you use mConnect Player for example, after applying the settings, tap the refresh button couple of times in the "Play to" view so that it gets refreshed and then re-select the renderer. The old renderer instance becomes invalid every time you change configuration because the player internally restarts.

 

But in normal use, I don't need to change configuration even monthly. I cannot think of reason why it would need regular attention. (except when I'm developing and restarting the daemon every few minutes to test some change)

[SwissBear]

9 hours ago, Miska said:

I would be curious to see J-test measurements of DAC output with internal/external clocks.

 

Hi Jussi,

 

I notice that it is not easy to communicate in an efficient way on this subject of high precision clocks.

 

On the "objective" side, you have your knowledge and I have mine. You are referring to the J-test, which is the standard in the industry, whereas I have strong doubts that the distribution of the said J-test, which is "centered" at 12 kHz, could in any way render the difference of performance of clocks, which performance are quite even at this frequency. The improvements of high precision clocks are to be found in the low range of the audible spectrum, and will probably be very partially rendered by the J-test. To illustrate this, I am enclosing a graph, showing the performance of the test I received with my Mutec REF10 SE120, and the oscillators available on today's DACs.

 

 

On the subjective side of things, I believe that one has to experience this kind of listening to make sure that one has the 'sensitivity" to micro-details, to the realistic rendering of strings and voice vibrations, to the assertiveness of bass and especially of transients, to make sure that this addition to a system is valuable. We all have our "utility function" when music reproduction is concerned, and this function varies drastically with every individual.

 

Thanks anyway for your efforts of persuasion and your time :-)

 

[Miska]

40 minutes ago, SwissBear said:

 

Hi Jussi,

 

I notice that it is not easy to communicate in an efficient way on this subject of high precision clocks.

 

On the "objective" side, you have your knowledge and I have mine. You are referring to the J-test, which is the standard in the industry, whereas I have strong doubts that the distribution of the said J-test, which is "centered" at 12 kHz, could in any way render the difference of performance of clocks, which performance are quite even at this frequency. The improvements of high precision clocks are to be found in the low range of the audible spectrum, and will probably be very partially rendered by the J-test. To illustrate this, I am enclosing a graph, showing the performance of the test I received with my Mutec REF10 SE120, and the oscillators available on today's DACs.

 

 

On the subjective side of things, I believe that one has to experience this kind of listening to make sure that one has the 'sensitivity" to micro-details, to the realistic rendering of strings and voice vibrations, to the assertiveness of bass and especially of transients, to make sure that this addition to a system is valuable. We all have our "utility function" when music reproduction is concerned, and this function varies drastically with every individual.

 

Thanks anyway for your efforts of conviction and your time :-)

 

 

Problem with these plots are that they are made by the oscillator manufacturer and are very far from something the D/A conversion section sees. Especially when there is something like PLL regenerating for example 24.576 MHz clocks from a 10 MHz reference clock - in worst case connected with another cable. When the clock sees PLL the phase noise will change. The path from the oscillator in such case to the D/A section pins is very long. Compared to an oscillator soldered right next to the conversion section feeding it directly.

 

For example I use Crystek CCHD-957 for modern DAC chips soldered next to the converter chip:

This doesn't need any transformations, cables, or extra circuitry. Can sit right inside the DAC.

 

But in order to discover real performance you really need to measure J-test from the DAC analog output. That analog output is what you are listening. I have measured enough devices to know that having a fancy clock somewhere doesn't mean the performance looks fancy. It only takes a little bit of interference pickup along the way and it is spoiled.

 

And by the way, the normal J-test is centered at 11.025 kHz.

 

 

Here are some examples of very good performance, without high price....

 

EVGA NU Audio card sitting inside my server, powered by Seasonic PSU (I pretty much always use Seasonic):

 

Holo Audio Spring 2 L2 DAC, using the built-in USB interface:

[CheapSplurge]

Any way to have EQ while also have hq player upsampling, I don't see it in the *settings tab* where you choose what filter and dither you want. 

I'm also running rune. 

Just want to see if I can have some tone EQ at the same time upsampling? 

[Mahler and Bach on Computer]

Hi, @Miska

 

I have a different question regarding HQP.  I have quite some Flac files derived from DVD-Audio.  Those are the ones with  Bit Rate around 1200.  Somehow I found Sinc-M cannot be used for this kind of files.  I have some other regular FLAC files, which works fine with Sinc-M filter.  It should be noted that DVD-Audio derived FLAC files work with any of those of -xtr- filters. 
 

Thank you very much.

 

[Miska]

8 hours ago, CheapSplurge said:

Any way to have EQ while also have hq player upsampling, I don't see it in the *settings tab* where you choose what filter and dither you want. 

I'm also running rune. 

Just want to see if I can have some tone EQ at the same time upsampling? 

 

Yes, it is available through pipeline matrix.

 

[Miska]

7 hours ago, Mahler and Bach on Computer said:

I have a different question regarding HQP.  I have quite some Flac files derived from DVD-Audio.  Those are the ones with  Bit Rate around 1200.  Somehow I found Sinc-M cannot be used for this kind of files.  I have some other regular FLAC files, which works fine with Sinc-M filter.  It should be noted that DVD-Audio derived FLAC files work with any of those of -xtr- filters. 

 

If you are doing upsampling to DSD, content sourced from DVD has 48, 96 or 192k sampling rate. sinc-M cannot convert such sampling rates to multiples of 44.1k, but most poly-sinc filters can. There's a column of possible conversion factors in the manual table.

 

[Miska]

On 1/21/2021 at 9:30 AM, SwissBear said:

Yes I tried through the USB interface of the DAC, it works flawlessly with DSD512.

 

By the way, have you compared output sampling rate between the two cases. Is it 48k x512 in the SU-2 case?

 

Sounds like similar symptom as what happens with Mytek Brooklyn DAC with 48k x256 inputs. Although the DAC chip is different in this case.

 

With DSD if you get noise plus music overlay, or echoy rattle on the music, it is typically a clocking problem. Data and clocks being out of sync. Highest multiple of 48k has most strict clocking requirements so it is most likely to appear in such case. Roon never generates DSD at multiples of 48k.

 

On 1/20/2021 at 11:10 PM, SwissBear said:

In the same situation, with a different DAC (x-Sabre), I have no problem playing DSD512 either with Roon alone or with Roon+HQP.

 

This likely runs like typical ESS Sabre DAC does, having 100 MHz master clock inside and Sabre's DPLL and ASRC active. Depending on the PLL parameters it can be quite tolerant to input clocks since it runs off it's own clock anyway.

 

The AKM chip doesn't have this functionality, but runs straight off the clocks it is provided with.

 

[SwissBear]

10 minutes ago, Miska said:

 

By the way, have you compared output sampling rate between the two cases. Is it 48k x512 in the SU-2 case?

It's 44.1kx512

10 minutes ago, Miska said:

 

Sounds like similar symptom as what happens with Mytek Brooklyn DAC with 48k x256 inputs. Although the DAC chip is different in this case.

 

With DSD if you get noise plus music overlay, or echoy rattle on the music, it is typically a clocking problem. Data and clocks being out of sync. Highest multiple of 48k has most strict clocking requirements so it is most likely to appear in such case. Roon never generates DSD at multiples of 48k.

Neither do I select this as you have mentioned several times that DAC seldomely support this format.

10 minutes ago, Miska said:

 

This likely runs like typical ESS Sabre DAC does, having 100 MHz master clock inside and Sabre's DPLL and ASRC active. Depending on the PLL parameters it can be quite tolerant to input clocks since it runs off it's own clock anyway.

 

The AKM chip doesn't have this functionality, but runs straight off the clocks it is provided with.

 

Not sure if this is not the opposite, as the clock and PLL are explicitly disabled in the x-Sabre from the user interface, which I cannot explicitly select on the D90.

I also tried the SU-2 without the 10 MHz clock input and this does not change anything.

So I'm limited to DSD256, which is not bad at the moment. 

Thanks for your help.

[Miska]

33 minutes ago, SwissBear said:

Not sure if this is not the opposite, as the clock and PLL are explicitly disabled in the x-Sabre from the user interface, which I cannot explicitly select on the D90.

 

I mean the ESS Sabre has PLL and ASRC built-in on-chip, and can run from asynchronous clocking like it is usually used, with 100 MHz master clock.

 

While the AKM converter chip doesn't, so it doesn't have PLL unless there's an external out-of-chip one.

 

49 minutes ago, SwissBear said:

I also tried the SU-2 without the 10 MHz clock input and this does not change anything.

 

It is likely more related to the I2S interface...

 

49 minutes ago, SwissBear said:

So I'm limited to DSD256, which is not bad at the moment. 

 

Given that ASDM7EC cannot be run at higher speed in real time, that should be sufficient...