Hey there,
this is my 1st post into this forum.
A week ago I got a brand new Holo Audio May Level 2 DAC. It sounds superb, but there is a downside.
At first I fed the May with a Audiophonics AK4118 Raspi HAT on a Raspi running Ropieee.
Each time I start a track, May takes 20 sec to get locked. i.e. the first 20 sec of music have passed silently…
The petty is, that this repeats each time I stop and start music.
Only if I let run roon I can enjoy the music without breaks. With one exception: change in the sample rate causes new 20s locking period as well.
Unfortunately my dealer in Europe couldn’t help.
So I decided to test different sources:
With my CD transport (Audionet ART V2) it works much better. Locking takes only 2 sec, the May keeps locking also when I pause the CD.
My oppo 203 works as a roon bridge as well. And it works really fine!
The 1st time I feed the oppo with music from roon, the May does locking for 20 sec. But this happens only once! I can stop and start how often I like. No locking takes place.
The reason is, both the oppo and the CD transport keeps the S/PDIF manchester coding signal running. The Raspi with ropieee doesn’t.
No I declared the oppo to be my preferred bridge 
and I enjoy listening to my new device.
Hopefully this helps other users of the May DAC.
I would like to here also form different sources compatible with the May.
Cheers Regina
Hi,
Ropieee has a switch to keep SPDIF on all the time or let it sleep I believe (if this is the cause of your issue?). Check how you have it set in Ropieee settings.
Advanced TAB:
Hi Tony, thanks for your advice.
May be it’s a real hidden feature 
I tested now “Dynamic Audio Power Mgt” and “USB auto suspend” though I guess these are not the parameter we are looking for.
And it doesn’t work.
@Digigina The may is best (from all the reviews) on usb - does this happen if you use it direct to the core machine or the rpi USB port?
The May joined my household only a few weeks ago. 
Playing around with the Interfaces is the next step. At first listening was more important
No I tested only I2S and S/PDIF via a raspi digi HAT
USB I will test soon and than I share my experience….
I own a Spring 3 KTE and have it directly connected to the Roon core through USB. I think its USB implementation is identical to the May and I can tell you, it is absolutely amazing! I have none of the issues you are describing above. I see no reason at all to try the other inputs, unless I would own a very good SACD transport that has a superb I2S output.
I’ve never had that problem with Ropieee on Pi 3+Pi2AES > AES > Spring 2 KTE. I’d start by trying an alternative to your Audiophonics AK4118.
Similar locking issue also mentioned here: HOLO Audio MAY DAC - Page 5 - DAC - Digital to Analog Conversion - Audiophile Style - look for posts by and to mushi
Seems as though it’s ok is OS mode, with PLL disabled (if it’s due to the source) and the cause may be a fault with the input signal or the May itself which you would need to narrow down to determine, however USB should be pretty reliable.
Good luck, I don’t know any more I just remembered reading that thread!
I don’t have a May yet (on order), but from my experience with Spring 1 and Spring 2 I’d suspect the source rather than the DAC. I’ve used those with well-designed S/PDIF and I2S sources at different price points and they never misbehaved.
It may be worth considering that a 50 Euro S/PDIF source might not be the best match for a 4K Euro DAC. S/PDIF is clocked by the source, so mediocre clocks/clock drift could easily overwhelm Holo’s PLL. OTOH, the $200 Pi2AES is totally competent at driving the Holo DACs I’ve owned using S/PDIF or I2S.
Thanks for all the replies!
I just tested it connecting the DAC directly to raspi’s USB port and it works really fine. No delays, no PLL issues.
@Sibbers I often found the advice to switch to OS or disable PLL to bypass this issue. But I bought the May because it’s NOS mode and because it’s excellent jitter rejection. And I want to get what I payed for
IN USB mode PLL doesn’t take effect because it’s a asynchronous transfer.
The reason why I used the AK4118 HAT is it’s I2S interface. I thought that would be better than the poor standard S/PDIF. Obviously that not true…
@Fernando_Pereira it’s not a magic to design a digital IF which is mostly jitter free. Our cell phones are clocked with GHz. So 192kHz shouldn’t be an issue. But your right, there is a lot of garbage out there…
That obvious by looking on my CD transport. May locks into 2sec when connected via S/PDIF to the CD. And otherwise same input with a RasPi HAT it takes 10 times more.
OK, I have a much better solution now than using the oppo, but I’m always curious to find out if there any differences between USB and S/PDIF as input. If Holo Audio did a really good job, it shouldn’t 
Yeah, that thread cites the source as the MiniDSP SHD which should be a very good source. Also the May PLL is meant to be a strong point, able to do a great job of cleaning up whatever it receives but I suppose there are always limits. Isn’t it the case that I2S takes the clock from the source? Maybe I’m wrong on that - I’m looking forward to a Holo Spring 3 KTE soon so I’m hoping mine works out alright, I too would want the PLL to lock quickly if it were not the source at fault.
Hope yo u figure it out and, when you do, please do report back and let us (me) know the details!
You’d think so, but there enough jitter measurements out there showing poor jitter from a variety of devices to indicate that not all such sources are well designed or implemented.
Now that I have a May KTE: same delayed locking behavior with a Pi2AES+Ropieee, both in HDMI I2S and AES. No such issue with Spring 2 KTE, Schiit Yggdrasil, or Sonnet Morpheus. Hum…
This caused by the May PLL feature. Turn off that feature if the locking behavior is a problem.