HOLO Audio MAY DAC

[barrows]

2 hours ago, GoldenOne said:

I've now got a may on order and it should be here mid-june (went for the wildism L2).
Planning to connect it directly to the AHB2 and use Roon/HQPlayer volume control rather than a preamp given as I'll only need a few dB of volume control.

Only thing I'm considering now is what the ideal input is. I know the original spring had some issues with its USB, but supposedly the later revisions of spring 2 and now the may are much better.
Not to mention the May buffers and reclocks all digital inputs, so I'm not entirely sure if using I2S etc is going to provide a benefit over USB anyway.

Has anyone here tried multiple inputs and could comment? I'm torn between:

- Keeping my pi3b endpoint and calling it a day
- Getting an Sotm SMS200 Ultra and connecting the dac via USB
- Getting a pi2AES and using the i2s output.

I'm not sure if the may would actually benefit from the sms200 ultra given its FIFO buffering/reclocking anyway. Would someone more knowledgeable be able to shed some light on this area?

I don't know if i'll be using HQPlayer with it or not. I use HQPlayer with my current ADI-2 DAC as I dislike its internal filters, but will have to play around with the may once it arrives.

I know some people like I2S, but it is somewhat flawed in a technical sense vs. USB.  The USB input on the May has been shown through jitter measurements to be very, very good.  I would expect best performance using the USB input via a very, very good Renderer.  Using a Renderer allows your (powerful one needed for HQP of course) computer to be located far from the audio system where things like electrical and RF interference and even fan noise will be of no concern.  I work with Sonore, so of course you know my preference for Renderers!  Regardless, you will want to use a Renderer which has the HQP NAA protocol available.

[barrows]

7 hours ago, digitaldufferme said:

@barrows Putting aside your Sonore connection, what is the argument that a renderer with NAA needs to be "powerful" for HQP? What is the issue with a RPi4b running @Miska dedicated NAA software? Thanks for sharing your viewpoint and hoping this doesn't trigger a Pi fans' war. I'm genuinely curious as I have a Pi4B and my Holo Audio May L2 should arrive today. Cheers

 

Sorry friend, for any confusion caused by my post:  I was saying that a powerful computer is needed for running HQPlayer (especially with the fantastic sounding EC modulators), not that the Renderer needs to be powerful. 

 

Now, certainly there are better performing Renderers than OTS commercial computer gear like a RPi, but that is another topic and it would not be appropriate to talk about that further in this thread.

[barrows]

3 hours ago, mushi said:

Yup, turning off PLL works perfectly.

Apparently this problem happen when a source spdif signal is out of standard clock tolerance(+-50ppm)

 

I'm curious what the miniDSP clocking looks like, and i wonder if it can be improved somehow?..

 

 

This confirms that the mini DSP has too much jitter.  When you turn off the PLL of the May, then all the jitter from the mini DSP goes right on through to the output of the DAC, and you are not getting the sound quality that you paid for.  Time to ditch the mini DSP if you want to achieve the sound quality which the May DAC is capable of. 

[barrows]

One big difference between these two DACs is that the Terminator DACs do not have any additional output stage to drive the output, and hence they have a rather high output impedance.  It does appear that Holo Audio pays a lot of attention to the design of their output stages as well, with a hybrid design and an IC based I/V section and a discrete transistor drive section.  Additionally, one cannot achieve the very excellent measurements of the May without the output stage being very, very well engineered. 

[barrows]

30 minutes ago, mushi said:

UPDATE

 

I think we have found first scratch on HoloAudio marvelous reputation.

 

 

I just bought a digital tuner and connected it to May through SPDIF Coax, and guess what? It's LOCKING!!!

It looks like there is malfunction PLL and NOS mode with SPDIF signal (OS/OS PCM/OS DSD mode works fine).

 

 

Through this time I contacted with miniDSP support team, and guys took this problem seriously:

- miniDSP engineers put the SHD Studio on the APX555x to check the locking and metadata and everything seems fine. The metadata for SPDIF/AES-EBU is indeed correct.

- FYI, their device always outputs the clock actually. No matter if muted/paused, it's always outputting the clocking+metadata.

 

And now best thing:

- when miniDSP engineers are asking for more details on the metadata which HoloAudio expect, and are asking about more details of HoloAudio clocking circuit (the one that shows an unlock), MagnaHiFi doesn't know the answer or copy/paste marketing blurp about PLL circuit from KitsuneHiFi homepage, but Tom from KitsuneHiFi gave me better answer: turn off PLL. Thats all.

 

HoloAudio claim (from KitsuneHiFi homepage) that:

"A common technique to improve the clock signal from SPDIF is PLL."

and

"Now the May is implemented with femto clocks, and also new discrete ultra high performance voltage regulators. It has an advanced PLL (phase lock loop) circuit that is completely custom built for ultra high performance anti jitter performance. Even the highest levels of jitter are near eliminated which delivers world class performance."

 

Why should I turn off the PLL? In order to degrade the sound quality?

What is the PLL installed there for? Just for looks?  Such a marketing trick to make more audiophiles buy this device?

 

And my problem is that I am not able to convince myself of it's spectacular performance because it does not work..

 

 

What do you think guys?

 

 

 

A PLL has a kind if window function, and the opening of that window can be wide, or it can be narrow.  A very wide window will be able to lock to high jitter streams coming in, and a very narrow window will require a lower jitter signal to begin with.  For example, the ESS 9038 DAC chip has an onboard PLL, with an adjustable input "window", when you adjust the window to its lowest opening, the DAC will not lock to some (higher jitter) sources, and the solution is to either open the window a bit, or reduce the jitter of the source.  Opening the window a little wider is a compromise, because it will let more of the source jitter through.  The best solution is to reduce the source jitter.

Sounds like the Holo Audio May has a fairly narrow window in its PLL circuit, so one may need to deactivate the PLL for some high jitter sources-If this is what is happening, then one cannot blame Holo Audio because their source has too much jitter, the source is the problem, and Holo audio can accommodate that source by turning off the PLL.

 

Alternatively, it is possible your specific May has a problem with its PLL circuit, but I have not heard any evidence which suggests strongly that is the case here, still could be though...

[barrows]

3 minutes ago, mushi said:

I hear you.

But how do you explain that miniDSP and PLL works together on OS mode but on NOS mode doesn't?

And I'm not the first one, @Diavolo has the same problem with SPDIF.

 

Without knowing more about the exact circuitry of the DAC i could not say, this is a question I would suggest you address to Holo Audio.

[barrows]

1.  I have asked Stereophile when reviewing DACs with separate PCM and DSD conversions (like Holo, Bricasti, Denafrips, T+A, etc) to please make separate measurements and listening tests for both sections, as by not doing so they are only reviewing a portion of what the DAC is actually capable of.  Wanting them to also test with HQPlayer oversampling is unlikely to happen anytime soon!  Although we here at AudiophileStyle are well aware of the potential benefits of oversampling in software vs. in the DAC, this approach is truly a niche thing, and is not even understood by the average audiophile.  Given how many possible different approaches there are with oversampling in  software, it woudl be very hard for a reviewer to test all of the options!  Although maybe asking them to test one recommended approach (from, say, Jussi) might be able to happen someday.

2. @GoldenOne: if you oversample PCM in HQPlayer to a different bit depth, you are going through a SDM re-modulation.  So really the only good way to hear what no SDM processing sounds like with a NOS R2R DAC is to feed it native PCM content. 

[barrows]

2 hours ago, Savolax said:

I would recommend to try out if possible rather than denying the chance. 

Indeed one should try such out.

 

From a technical perspective, a well implemented USB interface is superior, and all reports appear to indicate that the latest USB interface from Holo Audio is very good (both subjectively and technically).

With I2S and the May, one would want to use the PLL in the May for sure as it will remove the inherent jitter in the I2S connection scheme, as it is a synchronous interface and subject to increased jitter.  In fact, the much promoted PLL design of the May, perhaps, is enough to eliminate the technical limitations of the I2S connection.

USB has an advantage, in that it is an asynchronous interface, and relies on the DAC clocks for its clock, so there is no need to negotiate a relationship between two different clock sources, which are not in sync.  But the May PLL, which is the circuit which negotiates between the clocks, is purported to be very good, and measurements appear to support this.  

[barrows]

2 minutes ago, Miska said:

 

Problem with all those I2S interfaces is that clocking is wrong way. From the I2S source, while it should be the opposite direction, from DAC towards the source...

 

Agreed!

[barrows]

15 minutes ago, GoldenOne said:

Does the urendu actually support 1.536mhz?

Theoretically, it "should" support this rate, but we actually do not know as no one at Sonore has ever had access to a DAC which supports this rate for testing.  There are very, very few DACs which support this rate.  As mentioned, there are also a lot of different firmwares for the Holo Audio USB input, so that is the first thing to investigate with Tim.  Note that Jussi has recommended testing first with MoBo USB outputs to confirm it works before trying other USB sources (like ultraRendu, or "high end" USB cards, etc).

I could test this rate here if Tim at Kitsune would be willing to send me a demo DAC for testing purposes.  I have access to HQPlayer oversampling to this rate.

[barrows]

10 minutes ago, Flextreme said:

Is there a objective way to find out (other than subjective listening) which USB port gives best results?

Only with very expensive test gear.  A very high speed 'scope for eye pattern testing, and a really good spectrum analyzer for testing the noise on the power and ground lines.

[barrows]

i9-10900T appears to have a very low clock base frequency?  Jussi has mentioned that a high clock base frequency is desirable for oversampling to DSD and using the EC modulators, and it would appear that the "T" version  would not be the best choice for this?

[barrows]

I understand, as you are primarily concerned with OS to PCM, which is less demanding.  My needs are for OS everything to DSD 256 with the EC modulators.  I chose a i9-9900K for this, with its higher base clock rate, and because with the advent of the 10 series the prices came down on the 9900K.  I am not concerned about having a silent machine, so no need for passive cooling for me, I have a fan based cooling system on my new machine build as the server is another part of the home and I use a Sonore Signature Rendu SEoptical as NAA.

My Bricasti M3 loves DSD 256 input.

[barrows]

5 minutes ago, Diavolo said:

I agree with you. I guess when the signal goes to the AKM upsampling chip, it's entirely reclocked, as a friend suggested, but maybe PLL is not actually on when OS is on?  I know it's so much easier to turn on or off OS using the remote then fussing with the PLL feature. 

For sure the AKM OS chip is an asynchronous re-clocker.  Personally I woudl never choose to use that in the May DAC.  I woudl always choose much better OS in software.  Jussi has shown measurements showing that the AKM OS chip is not very good at all.

[barrows]

7 minutes ago, MichaelHiFi said:

Looking to feed the May properly I'm looking at many options. 

 

My current setup is the Lindemann Musicbook DSD25 fed by a uRendu which is fed by a etheregen all custom built Cat7 that sources a Small Green computer linux based system using an enormous 12 volt power supply. I'm a Roon (ruined) guy. 

 

I have 2 systems. My main system is stuck in a bad room. I don't expect the May DAC to fix my room. We will move to a home with a basement that will be suitable for a "this is it I'm done" system which I'm putting together (of course we're never really done are we). So the May may float between 2 rooms (2 systems).

 

I'm feeling Diavolo's system and his approach. We may land the same speakers, the Tektons as well. My wife had a love affair with the line arrays and the Texton might satiate her audio desire. 

 

Given the love shown here for HQP, my low powered linux box wouldn't have the horsepower for the capabilities of the May. We were looking at the Zen or Zenith servers and the Aurender too, but decided there's a better lower cost solution. I can build a server or buy a preconfigured one.

 

Tim from Kitzuni uses a computer and the Itona 3.0 along with the associated USB cable. This is what he recommends, that is, the Itona and USB cable they sell. 

 

Along with the May, I've got a Kinki M1+ on the way for pre/power amp duties. My other 3 amps are a Nord class D, a AS12200 based ice module and a BMC S1 AB that is in need of repair. Anyone fix amps? Anyone know anyone? Been busted for years.

 

Congrats to all of you on your newly acquired Mays!

If you are planning to use HQPlayer to oversample to high rates for use with the May (which I would recommend)-I would also recommend isolating your HQP server via Ethernet, or even better, optical Ethernet.  A server running HQP and oversampling to high rates makes a lot of noise, and no matter how "good" of a server you build, this noise needs to be isolated from your audio system and DAC.  This is why Jussi developed the NAA set up in the first place, so thta one does not have to worry (too much) about the server running HQP and its noise.  Ethernet distribution allows you to keep the noisy server running HQP with a high power processor away form he audio system.  So use the best Renderer with NAA capability which you can get your hands on to feed the DAC a nice clean, very high rate, USB signal with a really good USB cable. 

[barrows]

3 minutes ago, MichaelHiFi said:

I don't need a fanless computer if I use optical (or even ethernet of course) if it's in another room which was in a former setup. Optical cables don't care to much about distance. Cat7 maybe so.

 

I'm sorry, what is a "NAA"?

Indeed.  My server for HQP has a fan based cooling system for the i9-9900K processor.  The server resides in my workroom on the second floor of my home, where all the other commercial computer stuff is, router, switch, etc.  Then I run an optical Ethernet link to my audio system and I do not have to care much (if at all) about the server "noise".  BTW, CAT 7 usually has a ground connection through the shields which can be problematic, I would suggest using CAT 6 instead to avoid that ground connection and the potential for ground loops.

NAA is Jussi's (miska here) proprietary Ethernet protocol to use with HQPlayer (as opposed to UPNP, or Roon's RAAT), it works very well, but does require that the Renderer includes it as an option.  Your microRendu can do NAA, for example.

My point is that it is pretty clear that the May has a very good USB input, such that I have very strong doubts that there would be any advantage to using a different input.  But as you mention, I would recommend a really good USB cable. 

[barrows]

1 hour ago, MichaelHiFi said:

Question is this, why would it matter what power supply I use on the computer end if one ultimately uses fiber to send data to whatever device is downstream? Would a potentially noisy PS at the computer end pollute the data stream? I ask this because the power supply(s) is one of the costliest parts of our stream(s).

Unfortunately, one will find opinions on both sides of the spectrum regarding this question.  There are some actual facts though: The data stays intact in the case of an ethernet stream, no matter the noise level in the serving computer-this is an indisputable fact.  Now whether (or not) any noise from the serving computer gets to the DAC over an Ethernet distributed system, and whether (or not) that noise can affect the DAC's performance is not known to any degree beyond opinion.

Additionally, there is a very good argument to be made that by distributing audio data from a server, over an optical Ethernet distribution that there can be no noise transmitted to the Renderer.  There are many who dispute this point of view, but none of them have been able to offer any theory of how such might be possible, and much less any proof of such.  In a subjective sense, many users have had the experience of optical Ethernet distribution improving, often significantly, audio performance.

In the sense of being open minded, I will not state absolutes here, but I will say that if one uses an optical Ethernet distribution system to bring files from a server to the audio system, one should take care of things like power supply quality, cabling quality, and all the other small details which may (or not) affect audio performance on the Renderer/DAC side of the optical isolation well before worrying about what happens on the upstream server side (other than being sure to have a server and Network which functions properly).  Only when the downstream side is fully optimized does it make any sense to work on tweaking the upstream side with expensive cabling, fancy power supplies, or any of the other myriad of tweaks which might be applied there.  This POV assumes a system where the upstream side of the optical connection is in another room of the home, and plugged into a different AC circuit (hopefully on the opposite phase when possible) of the homes' AC supply.

[barrows]

16 minutes ago, bibo01 said:

In a server-switch-renderer configuration in your view how important percentage wise is to go optical Ethernet at switch-renderer level and how much at server-switch level?  

I do not have any way to accurately answer this question.  There are so many possible variables in a Networked set up, that is very difficult to offer a “best” solution.  I would suggest, that my preference would be to run optical fiber for the longest run as it is noise immune, and I also would prefer to have optical cable as the final link to the Renderer, considering that this will allow the least noise to get to the Renderer, and that this approach will allow for least influence on sound quality via the upstream commercial computer components.  I would at least advise starting here, and then possibly experimenting from here if one is looking for further improvements.

[barrows]

6 minutes ago, fds said:

Anyone here using the Holo Audio May with the HQPlayer volume control directly connected to power amps as the favored setting? Is that a setting that works well?

 

According to JAs Stereophile measurements it seems to have a max output on the balanced outputs of 5.8V at 1kHz when using NOS mode.

(https://www.stereophile.com/content/holoaudio-may-level-3-da-processor-measurements)

Does this apply when feeding native DSD to the Holo Audio May NOS mode as well? Also does the voltage value matter when thinking about using a DAC with HQPlayer volume control directly connected to power amps?

 

Somehow I remember that I had read a comment from @barrows on this somewhere even in relation to the Holo Audio May but I was not able to find it.

My understanding is that the V out of the Holo DACs when running them with DSD is half of the PCM level, so 2.9 V at 0 dB.  When you oversample to DSD, you usually need to apply at least a 3 dB reduction in level before the oversampling to avoid clipping, so you lose about .9 V there.  This would leave your maximum V out at 0 dB around 2 V.  Then considering what you need in voltage output to accommodate some albums which may be recorded at lower average levels (like Reference Recordings, for example) one may not have enough V out to drive the amplifier to achieve sufficiently high enough volume levels.  In a lot of systems this would OK, but I know in my system, this would be borderline, and I would like to see Holo Audio change this behavior to allow for 4 V out on the balanced outputs when running in DSD mode.  This is one of the reasons I have not considered getting May for my system, as my preference would be to run amp direct, using the HQPlayer volume control.  But, a lot of systems will have sufficient gain to make this a non-issue, and here, I could probably raise the gain of my amplifier a few dB to accommodate the may, but this will raise the noise floor a little.

[barrows]

37 minutes ago, Diavolo said:

I'm running source direct to my Pass Labs XA25 via single-ended using Roon's digital volume control which controls Hqplayer's volume control when I use HQplayer which is becoming less and less since I rather enjoy the pure unadulterated sound of NOS from running ROON stock using its ASIO driver and digital volume control.  I also enjoy Hqplayer in 20bit/1.536mhz mode, but honestly we're splitting hairs imho vs Roon running NOS via ASIO.  I don't prefer pcm->dsd upsampling, but again it's beautiful sounding, just a tad smoother imho. 

 

Eitherway you do it, it works great for me. I'm not lacking in volume control or ultimate loudness.  (The XA25 is a single-ended output only, produces 50wpc into 4ohm Class A, and my Encore tower speakers are 96db/4ohm)

People often make the mistake of thinking that if the amplifier sends too much power to the speakers, problems will ensue.  While this certainly can happen, the much more common way to damage speakers is by clipping the amplifier drastically, where it no longer controls the output and sends a blast of DC to the speakers, or an extremely distorted signal.  The thing to be most careful of is to avoid sending the amplifier a signal level higher than its rated sensitivity.  Most good speakers can handle power input well over their rated maximum without damage, as long as that input power is clean and controlled by the amp, the damage usually occurs when the amplifier is clipped and loses control off the output.  This can actually happen more easily with a 25 watt amp, than with an amp of much higher power, because the 25 watt amp clips at a much lower input level. 

[barrows]

25 minutes ago, Extreme_Boky said:

The question is: do you believe that the 5V rail sitting in parallel with + and - USB data can influence USB data transfer in any way, or it can not... I like to disable the 5V DC coming out of the laptop, once the handshake is done.... even though the USB interface inside the May DAC has its own low voltage regulator(s).

If there is no current being drawn by the DAC on the 5 VDC USB power, it should not have any possibility of "disrupting" the data lints anyway.  Also, if one uses a really good USB source, one should not have nay concerns RE a DAC which does use the USB power.  As long as thta power is clean (as it should be with a good USB source) then there are no worries.  In fact, when a DAC uses the USB power to power its USB receiver section, it improves the isolation possible between the critical DAC circuitry and the USB receiver.

[barrows]

8 minutes ago, MichaelHiFi said:

 

I guess that means I didn't and even perhaps shouldn't have had the USB cable being constructed for me to have USB power on it. It was a question I asked Tim but never received an answer. Maybe it really doesn't matter if USB is isolated in the DAC anyway. 

 

I wonder then when I build my music server, if adding the JCAT USB PCI card isn't a waste of money?

I have no comment on the JCat USB card as I prefer to isolate the server in another room of the home and send the data to the audio system over optical Ethernet using HQPe-NAA protocols.

[barrows]

11 minutes ago, mrkoven said:

Do you guys leave your May on 24/7? I'm finding that it sounds better once it's been on for many hours. So ideally I'd like to just leave it running 24/7, but not sure if that's detrimental to cap life or whatnot, maybe negligible? 

Electrolytic caps do have a a lifespan, and ultimately will need replacement if one is sure they are going to use the component for many years to come.  Film capacitors will last "forever" unless subject to misuse.  Most other parts in a solid state DAC like this will last "forever" (virtually) as long as the design is solid, and the DAC is not abused somehow.  Me, I would leave it on all the time for better sound, and be willing to replace electrolytic capacitors, perhaps, at some point in the future-as long as I liked the DAC enough to want use it for years to come.  Buy a few LED lights to offset the  electricity used, or pay attention to turning off lights in the home.  And then I unplug if going away for a few days or more, for the protection of gear and safety.

edit: Also note that cycling the power to the capacitors is often the most damaging/aging thing, as the inrush surge can be stressful to the part-so constant power cycling daily has its own downsides as well.

[barrows]

10 minutes ago, lpost said:

Does this mean the USB output clock is irrelevant? Could it be something other than 20Mhz and the signal still be received and clocked by the DAC?

 

I'm asking legitimately to learn as I don't know how asynchronous USB is intended to work.

No, any processor chip requires its own clock to operate.  So, for example, a USB hub chip (which is always present at each end of a USB communication run) requires a specific clock frequency of its own to operate.  This USB clock has nothing to do with the audio clock(s) which are used to clock the audio data stream out of the USB receiver and into the DAC's conversion stage.  The audio clocks are what is relevant to the "jitter" of audio data stream and any subsequent sound quality issues there.

But, the performance of the USB clock has been demonstrated to have an effect on sound quality as well, at this point, no one I am aware of has really figured out why the USB clock's performance on phase noise seems to matter for sound quality, but the anecdotal evidence of such has shown this influence to be clearly audible.  So, while the USB clock does not have a direct effect on audio jitter levels, it does appear to have some effect regarding sound quality.

[barrows]

1 hour ago, lpost said:

I'm curious from those that know how USB works, is it the system clock all USB interfaces use that is in common and thus at fault or does each interface have it's own inherent issues passing 1.5Mhz PCM?

I do not what specifically allows some USB interfaces to work at 1.5 MHz PCM, Jussi suggests that USB interfaces which use an Intel USB hub chip are more likely to work...  I very much doubt the USB clock has anything to do with it though.