Ropieee HAT audiophonics I-Sabre 90*8Q2M Dac not locking AES/EBU when no signal is played

hello,

I am facing a problem with my new streamer (Ustars Audio C19) which is provided with ropieeexl (latest version)

I am connecting it to a sonic frontiers SFD2 in AES/EBU using the Audiophonics HAT as recommended by the vendor.

It plays fine the only problem is that the DAC is locking after 1s of track play for every song.
if I am not playing or I am pausing the DAC is not locked anymore.

I checked with an oscilloscope which confirms that when nothing is played I have 0V (around 10uV of signal) and when playing I have 2.8vp-p

Is there a way in ropieee xl to force the signal so that the DAC will be always locked and that I won’t lose the 1st second of every track ?

Is there another better HAT to use for legacy DAC ?

Thanks in advance for helping

PS: I also have the same behavior with a Soekris DAC (1021)

Not sure it help diagnose, but…

I have Allo Digi, Digi Signature and Pi2Design AES digital HATS. I briefly owned an early Hi Fi Berry Digi. They all run Ropieee in a mix of Pi3 and Pi4.

I’ve use them with RME (ADI2 Pro, ADI 2/4 Pro, UFX+) , Musical Fidelity (M6, V90) and Chord (Mojo, Mojo2, Hugo2) DACs - and have never seen a significant delay locking onto the signal.

So this certainly isn’t common.

Might be worth trying another HAT. Sadly Allo are no longer active (although can be found used).

The issue most likely lies within the DAC, and may be the effect of big buffers or slow lock times for the PLL.
I have a brand new DAC on loan right now which sounds very good in all aspects but like yours, it drops a fraction of the first second on every change of sample rate.
I don’t do much playlists, so for me it’s a non issue, but given your preferences here, i’d say you chose the wrong DAC.

@GregD I tried different HATs and the only one working is the I-Sabre 90*8Q2M, unfortunately.

@Mikael_Ollars what is surprising is that my DCS verdi but also my previous streamer based on an engineered EredDock are locking without any problem with no signal( (checked also on an oscilloscope) on both of my DACs sonic frontier SFD2 and the Soekris DAM 1021.

What I see on the scope during the boot time is that a quick signal is sent approximatively 40 seconds after the boot started for 80ms then nothing for 5ms then again a signal for 20ms and then nothing. the form of the signal is also different than what I observe when the a file/track is played (so not sure is it an AES signal to be honest). In order to lock it would require that at least ropieee sends a proper signal and I doubt it sends it until a file is played.

What I am observing with the DCS and the eredDock is that an aes signal is constantly sent (with or without a file being played) hence the reason the signal is locked by the dacs

I will receive another DAC tomorrow (topping D70 octo) I will see how it behaves.

1 Like

May i suggest you get an IAN Canada MonitorPi for your transport, it is an excellent tool for showing what kind of signal is delivered over I2S.

But i have some difficulties in interpreting what you are trying to accomplish also, you refer to the Pi as a transport but the Sabre HAT mentioned in the head line is a DAC, not a SPDIF transport?

There is a roon device setting Resync Delay you could try setting this to see if you can give the DAC time to lock.

You could also upsample to a maximum rate - I have one (non critical) zone using a HAT that pops when changing sample rate - upsampling to 192 avoids the problem. I’d probably feel less happy doing this with a critical zone - although expect I’d hear no difference.

Just to be sure: your Alsa DAPM setting (on the audio tab) is on ‘off’, right?

Yes DAPM is off

I am using the following streamer. it does’nt have an internal dac but the vendor mentioned that Isabre HAT should be used

the streamer is excellent despite this annoying thing.

1 Like

So, not blaming ‘Da HAT’ here, but this HAT is badly supported upstream.
And with the new kernel I’m afraid this problem will get bigger.

too bad to hear that :frowning:

ideally I will have to write my own driver :grin: , but I am quite rusted despite my software engineering degree when it comes to programming (30 years since I did some c/c++ stuff :frowning: )

if you have any good resource to share regarding building proper drivers for the raspberry pi, I would be more than happy