MPD : add a delay to wait before starting the playback

[thomas2j]

are SMSL saying they have a physical relay and the click is mechanical ? Therefore normal and not in the signal path.
Muting the 'chip' may have downstream audible artifacts where there are grounding issues between items and power supplies.

What is the full setup you have, Pi..Pi pwr...SMSL ? cables ?   all on the same mains circuit/multi-box ?  any other non standard hardware tweaks ?
Powered speakers ?  etc

The click is not mechanical, i can ear it in my speakers.
Maybe the relay is mechanical and produces clicks in speakers.
I don't have any grounding issues, my 2 previous DAC was perfectly fine without clic, on the same setup

setup :
apple power plug -> raspberry 3B+ -> DAS SMSL -> Denon amp -> passive speaker
i test with an Intel NUC and it is the same even with optical output

Then, I see using Camilla to up-sample everything to 96kHz (or 192?) as the only solution left.

Yes thanks
I made that with Logitechmediaserver as i use Squeezelite renderer

But as i listen mostly to full albums i can bear a few clicks sometimes

[Tim Curtis]

So my solution is not viable; but then again, the problem may lie elsewhere...
As Tim said, you may want to contact SMSL.

Thanks
Do you have a mail of SMSL support please ?

Don't you have anything in the device's package...?

https://www.smsl-audio.com/portal/about/contact.html

scroll a bit down and you'll get to it.

I tried the contact from the site but it doesn't work,

ok so i have a response from SMSL :

"It no need to update with firmware.
And this clicks sound from relays when you changing sampling rate.
As we add MUTE IC chip in DL200 design.
It is normal."

Very disapointing !

If SMSL states the noise is from relays in the device and is "normal" it would be unacceptable to me and I'd ask for a refund or substantial credit towards a different SMSL device that does not have this issue.

IIRC there was another manufacturer a few years ago that made a device with clicking relays and purchasers suffered.

[thomas2j]

so i made some new tests with squeezelite :

i previously used this parameter :
-r 44100,48000,88200,96000,192000:100

witch add a silence of 100ms between tracks when you change the sampling rate
this doesn't stop the clicks

but if you increase to 1,4s it seems to stop the clicks :
-r 44100,48000,88200,96000,192000:1400

so Nutul, your idea was right...

maybe it should be implemented in MPD
i think many DAC with XMOS chip are concerned

[Nutul]

so i made some new tests with squeezelite :

i previously used this parameter :
-r 44100,48000,88200,96000,192000:100

witch add a silence of 100ms between tracks when you change the sampling rate
this doesn't stop the clicks

but if you increase to 1,4s it seems to stop the clicks :
-r 44100,48000,88200,96000,192000:1400

so Nutul, your idea was right...

maybe it should be implemented in MPD
i think many DAC with XMOS chip are concerned

My idea about adding silence was to eliminate the missing first second(s) of playback, that is, the DAC would have wasted time during the added silence, instead of during the song.
I was not expecting it to remove the clicks/pops... actually, it doesn't make any sense TBH.

[thomas2j]

so i made some new tests with squeezelite :

i previously used this parameter :
-r 44100,48000,88200,96000,192000:100

witch add a silence of 100ms between tracks when you change the sampling rate
this doesn't stop the clicks

but if you increase to 1,4s it seems to stop the clicks :
-r 44100,48000,88200,96000,192000:1400

so Nutul, your idea was right...

maybe it should be implemented in MPD
i think many DAC with XMOS chip are concerned

My idea about adding silence was to eliminate the missing first second(s) of playback, that is, the DAC would have wasted time during the added silence, instead of during the song.
I was not expecting it to remove the clicks/pops... actually, it doesn't make any sense TBH.

It eliminates the problem of the first missing 1/5s of playback too. The 2 problems are linked i think.
Anyway it is a bypass which works for me, so i am glad to have found a solution

[Nutul]

It eliminates the problem of the first missing 1/5s of playback too. The 2 problems are linked i think.
Anyway it is a bypass which works for me, so i am glad to have found a solution

Good to hear. I wonder, now, if by any means the fact that the stream is changing sr/bd while keeping the DAC fed with some "skipped" packet headers; letting squeezelite detect the new sr/bd and injecting a proper packet useful to the DAC could in effect be the solution to both problems (they are indeed related).
This leads me also to think that playing local files should not produce the problem.

If you want, I can try to upload somewhere 2 or 3 files with 48000 / 96000 / 24bit, so that you can try interleaving them in a local playlist, and verify the DAC's behavior; just for fun's sake...

Let me know, although I won't probably be able to do it before tomorrow evening.

[thomas2j]

It eliminates the problem of the first missing 1/5s of playback too. The 2 problems are linked i think.
Anyway it is a bypass which works for me, so i am glad to have found a solution

Good to hear. I wonder, now, if by any means the fact that the stream is changing sr/bd while keeping the DAC fed with some "skipped" packet headers; letting squeezelite detect the new sr/bd and injecting a proper packet useful to the DAC could in effect be the solution to both problems (they are indeed related).
This leads me also to think that playing local files should not produce the problem.

If you want, I can try to upload somewhere 2 or 3 files with 48000 / 96000 / 24bit, so that you can try interleaving them in a local playlist, and verify the DAC's behavior; just for fun's sake...

Let me know, although I won't probably be able to do it before tomorrow evening.

I just tested local files and there are the same clicks
Thanks

[Nutul]

It eliminates the problem of the first missing 1/5s of playback too. The 2 problems are linked i think.
Anyway it is a bypass which works for me, so i am glad to have found a solution

Good to hear. I wonder, now, if by any means the fact that the stream is changing sr/bd while keeping the DAC fed with some "skipped" packet headers; letting squeezelite detect the new sr/bd and injecting a proper packet useful to the DAC could in effect be the solution to both problems (they are indeed related).
This leads me also to think that playing local files should not produce the problem.

If you want, I can try to upload somewhere 2 or 3 files with 48000 / 96000 / 24bit, so that you can try interleaving them in a local playlist, and verify the DAC's behavior; just for fun's sake...

Let me know, although I won't probably be able to do it before tomorrow evening.

I just tested local files and there are the same clicks
Thanks

OMG...
Then it would be helpful, at least in some situations, to have the possibility to add silence, somehow...
I'll investigate whether MPD offers out-of-the-box capabilities for such a thing; otherwise the implementation could require more efforts.
Nothing to be granted/expected anytime soon, of course; but I'll have a look, nevertheless.

[DRONE7]

Interested in outcome of 'add silence' vs 'keep alive'

watching

[Nutul]

Interested in outcome of 'add silence' vs 'keep alive'

watching

The keep-alive should be the way to go.
Add-silence was just something I came up with as a workaround for the missing beginning of a track, during the DAC's "figuring-out-what-to-do"...
But let's see, indeed... :-)