I’ve a pretty simple setup and Roon works fine for me with my core on a desktop Mac with an ethernet feed to a Bowers & Wilkins Formation Wedge. However, has anyone ever noticed that the first millisecond or so of a track is slightly clipped when played?.. not clipped as in overload but ever so slightly missing. Normally you would never notice this as there is generally perhaps a second of silence before any music content starts. But the first track of a new album I’ve just put into Roon starts without any silence… it’s straight into the track without the slightest of delay. Bar manually editing the track by including a seconds worth of silence and reimporting is this slight delay normal or something that can be overcome in a setting somewhere?
Yes. In the audio device settings, you can ask Roon to run a little bit of silence to get your DAC locked in to the signal. I use half a second for my Bryston. It doesn’t affect gapless playback, which continues to work fine.
Does this behavior occur during playback of every track, or just in cases where the device is returning after a long period of standby?
As I read that, it’s only for format changes.
I complained about missing the first 1-2 seconds of songs, awhile ago.
For me. it started with the ‘improved’ buffer handling in the first release of V1.7.
Roon support could never recreate it.
It goes on in my system, to this day. Very annoying.
Do you have a Qobuz account?
I have the same issue, on two DACs: one via USB, and one via network.
On the network DAC, this issue occurs with Roon RAAT only, but not with other protocols (Devialet AIR).
Same issue here with a Pi with a IQAudio10 DAC HAT on it - resync delay is set to 6000 milliseconds but every track (irrespective of format change) is clipped
Other endpoints work fine
Thanks Kuryan. Tried 500ms but it didn’t seem to make any difference. If you make the track go back to the beginning using the previous track icon (to the left of play) it will always clip but I noticed if you persist with pressing the small triangular play button next to the track name it will in fact play from the very beginning without any missing audio. This is indeed strange behaviour and one in which it seems others are still suffering despite adding a considerable resync delay. Anyway, I reinstated the track I applied a second of silence at the beginning and there are no problems with playback - the extra second obviously prepares the system in a way it can handle.
Thanks Ken for that. Not very encouraging news. The engineering team you would think must surely know what is behind this behaviour.
Thanks for your input Daniel.
Hi Slim. No I don’t having any streaming account - everything is played from the Mac. It does seem to suggest some kind of buffering problem which disappeared when I added 1 second of audio silence to the beginning of the track.
Hi John. The device is not on standby. You can only hear the clipped audio when there is an insufficient amount of blank run-in to the track. A track that starts immediately will clip but if I add 1 second of silence to the beginning of the track the clipping disappears. It’s as though the system cannot cope unless there is an element of blank space before the audio signal.
I have this problem too. I just upgraded from a BlueSound Pulse Mini to a newer BlueSound Pulse 2. The mini would miss maybe the first second of the first song on an album. Following songs would be fine. With the full size Pulse 2 it misses the first 3-4 seconds. Pretty annoying.
Hi David. Not only annoying but unacceptable. There clearly is something fundamentally wrong here which I hope the engineering team will devote time to solving.
Thanks for the added information. We’re investigating this report internally. Roon Ready devices shouldn’t cut off audio at the beginning of a track, it’s one of our certification requirements. It’s possible there was a regression in a firmware update, we will follow up with Bowers & Wilkins if needed.
The QA team uses the first track on Daft Punk’s “Random Access Memories” album titled “Give Life Back to Music” as one of our “cut off” tests. The first note of the song starts at the 0:00 mark in the track, it’s very easy to identify if the note has been cut off.
Could you try playing this track a few times to see if the beginning of the track is cut off during every playback attempt? What we’re trying to deduce is if there is a second variable here like changing sample rates or starting a new playback session that is causing this to occur.
Either way, we will get this resolved with Bowers & Wilkins.
The track I used that has no blank run-in that causes slight cutoff was track 1 (Hēan) from Snake Davis album ‘Time Stands Still’. I added 1 second of blank space to the beginning of this track and the problem disappeared.
Now this is strange… I downloaded the track you suggested and no clipping!.. however I reintroduced the original track into Roon that caused the clipping and that no longer clips either!. Since last opening Roon I adjusted the resync delay to 1000ms so whether that’s cured it I don’t know. I’ve played the troublesome track a few times now and it doesn’t seem to clip… hooray. If it should resurface I’ll let you know.
Synology ds718 -> chromecast audio -> pro-ject pre dac s2 digital
-> MacBook -> analog out
Hard wired network
Re sync delay 1000ms
Does the same on my system on both my MacBook Air and chromecast.
Especially occurs when skipping tracks. Leaves few ms off start of track and sometimes takes part of the few milliseconds of a track start moves it forward in time and then plays it with a short gap afterwards, then the track plays normally.
Start a new support thread to be seen better.
Make sure to describe your network configuration/topology, including any networking hardware currently in use, so they can have a clear understanding of how your devices are communicating.
Fortunately adjusting the resync delay to 1000ms in my case has definitely cured the problem. Tracks that have no amount of silence at the start no longer clip. Your problem really is very strange though, why on earth it would move data forward and play with a post short gap is weird indeed. Sounds like some buffering is incorrectly being carried forward, however I’m not qualified to say how playback is executed but as ged_hickman1 says it would be better to start a new support thread so the team can help.