This isn’t specific to ROCK. I currently have an Aurender X100L which is in effect a small computer running a customised version of Linux. I go from Aurender to Singxer SU-1 via USB then a short HDMI cable into my PS Audio DirectStream DAC’s I2S interface. This is the best sound quality I have achieved.
Often I get the same issue when the next song plays. It is a burst of what I would describe as white noise and then silence. The only solution is to toggle the power on the Singxer. It only happens when the sample rate changes from one song to the next and is not consistent. I have the latest firmware installed on the Singxer.
I have also built a NUC to run ROCK (7i7BNH) and would like to replace the Aurender as I prefer the UI of Roon. However I think for ultimate sound quality I will go NUC (ROCK) -> USB -> Singxer -> HDMI (I2S) -> DirectStream.
An alternative may be to go Ethernet from the NUC direct into the Bridge II card I have in the DirectStream and then use a second USB to Ethernet “pigtail” to connect the NUC to the main network. This takes the Singxer and the Aurender out of the supply chain but the DirectStream is markedly better when fed via its I2S interface.
So having brought my Intel NUC into the listening room and tried both bridged Ethernet connection and USB to Singxer then HDMI to DIrectStream, the Singxer does sound better. The DirectStream always responds better to I2S input and the Singxer “decrapifiies” the USB output of the NUC.
However changing sample rate from one song the to the next does cause the Singxer to have a burst of white noise and then stop working. You need to toggle the power on the Singxer to resurrect the music.
The Matrix Audio SPDIF-2 may be an alternative option to convert USB to I2S.
I’m having the same issue with white loud noise when switching between tracks.I have been turning the singxer off and on again to fix the issues when they arise. I have a similar setup, roon rock is connected directly to a singxer su1 then via i2s hdmi into my directstream junior dac. This is an issue that is isolated to the roon rock and the singxer. I am able to use an audiophpnics i2s streamer via hdmi into my directstream junior with no white noise issues in my setup. Singxer played from win7 had no issues when switching songs.
Funnily enough it seems that the issue is aggrivated if you switch songs manually during playback.
.
I’ve tried all sorts of settings in roon to fix this but it seems to be an issue with the roon rock kernel.
Just to corroborate @Soeren_Schulze and @Mark_Kelly1 point it does seem related to the Linux kernel. I have created a “Live CD” on a bootable USB stick of the Euphony Stylus Music OS. I have this on my NUC with Singxer attached via USB then onto DAC via I2S over HDMI. I run Roon Core on this and it has mounted the local SSD (ROONSTORAGE) so I have all the music that is on my native ROCK install.
No issues with Sinxger but it doesn’t support Native DSD (which the Singxer does in ROCK). Can we have a driver update as I actually think ROCK sounds better than Euphony Stylus as an optimised version of Linux for music playback. @eric
Hi @Ian_Oliver —— Thank you flagging me down here and sharing the observations made during the mentioned test exercises. Having that insight is very appreciated! @Mark_Kelly1 thank you as well!
Moving forward, we’re going to need to get an SU-1 in house for testing with ROCK. We work with over a hundred hardware partners to make sure we can resolve issues like this, but I’m going to need to check whether we have a working relation with Singxer.
If we are able to get some hardware from them, we’re confident we’ll be able to resolve the issue on our side, or pass on technical feedback to Singxer about what might be happening here.
In the meantime, I did touch base with our tech team today and they would like to have a look at your Roon logs so we can have a closer look into this behavior when tracks are switching and there is the mentioned “burst” of noise. With this mind may I very kindly ask you both to please reproduce the issue and take note of the following:
What time it occurred.
The track and/or album that was being played at the time of the error.
Eric
Thanks for picking up on this. As an experiment I set the audio settings inside roon to output a max 16bits to the singxer. I can report that after a whole day of use there has not been a single glitch.
Obviously not having to decimate the bitdepth will be the goal but i think my testing has at least conclusively shown that it is bitdepth switching that seems to be causing the hiccup.
I have a 500ms as the reply delay and a fairly large buffer. The must be some issue with the way that roon rock addresses the xmos chip when bitdepth is rapidly switched mid signal.
Hope that adds some perspective.
From memory the last glitch was at my local time monday 8th AEST.
Mark
Hi @Mark_Kelly1 ---- Thank you for touching base with me and sharing the observation(s) made during your testing. The additional insight is appreciated!
Now that I have a sense as to when the issue last occurred I am going to enable diagnostics on your account. What this action will do is the next time Roon is active on your core machine a diagnostics report containing a set of your Roon logs will automatically be generated/uploaded directly to our servers. Once the report arrives I will be sure to touch base so you know that we have it.
I forced my singxer to error again today by setting the bit depth to 24bits Max. If I am not mistaken the error occurred when the switch went from 24bit down to 16bit. I switched the max bitdepth back to 16 bits and restarted the singxer and it played flawlessly after that.
Now that I know diagnostics is on, I’ll force it again to make it obvious in the logs. I’ll be back in the office in about 8 hours so it will pop up on your logs about then. That’s about 9am AEST.
Thanks for the follow up @Mark_Kelly1, appreciated!
Letting you know that I have received the mentioned diagnostics report from your system and have passed it over to our tech for review. Once the team has updated your ticket and passed it back to me I will be sure to share their thoughts/findings asap.
As mentioned previously what would be really helpful is when you go to trigger this issue again can you please note the time as well as the track/album that was being played when the error occurred?
I think I’ve cracked it. If you look up my log from about 15-5mins ago you might see what’s happening. Long story short, I was trying to isolate the issue and I had thought this was something to do with going from 16bits to 24bits tracks. But my experiments proved this was not the case. So I then set the DSP to resample to 192khz and that didn’t fix the issue so it’s not related to switching sampling rates. I then thought it might be to do with file formats but flac to MP3 or vis versa didn’t seem to evoke the issue and to be honest I can’t see how that would affect anything anyway.
So I started playing around with other things inside the device settings, Under DSD Playback Strategy, I changed “native DSD” to “convert to PCM”. Result = issue solved (at least as far as I can see).
What is odd is that the files that are having the issue are not DSD files at all. In fact, it’s almost the polar opposite in that MP3 files seem to give the most issues - pretty far removed from a DSD file!
Example, switching from Panthu Du Prince FLAC 24bits 44.1khz to Peter Selway “coming up for air” MP3
44.1khz 24bits 260kbps causes the white noise and dropout every time when DSD is set to “native”. Switching from the Peter Selway MP3 track back to the Panthu Du Prince track does not cause the issue. Both files are 44.1khz, 24 bit and the only difference is the file format and I guess data-rate is lot higher from the FLAC file.
So to conclude - I can now set my Singxer to 32bit operation and can avoid dropouts when playing any type of music from any format / bitdepth / dampling rate at the moment - as long as I keep DSD playback strategy to “convert to PCM”. Weird!!!
Picking up on @Mark_Kelly1 point I’ve been switching between Euphony OS and ROCK on my Intel NUC. When I run Roon Core on Euphony the driver for the Singxer does not support native DSD, whereas in ROCK it does. However I still get the white noise issue when switching from 16 to 24 bit but much less frequently as I need to have DSD Convert to PCM enabled.
It always occurs when stepping down from 24 to 16 bit on ROCK. It occurs frequently when going up to 24 from 16 on ROCK.
Again as suggested by @Mark_Kelly1 keeping everything at 16 bit stops the issue completely.
Given that this issue doesn’t occur in Windows or Mac (allegedly) I’m still suspicious of the UAC2 driver in various flavours of Linux.
@eric I would be happy to let you switch logging on but as I say I’m bouncing between ROCK on my M2 SSD and Euphony OS on a “Live CD” USB stick. There is a difference in sound characteristics but I don’t know which one I prefer…
I think Euphony is based on Arch Linux as is ROCK?
@Mark_Kelly1 and @Ian_Oliver ---- Thank you both for the follow ups and the diligence here Having this additional feedback is greatly appreciated!
Mark I enabled diagnostics on your account and can confirm that the new report has hit our servers. Ian I am going to do the same for you so I can attach the report to your ticket for our techs to review.
Furthermore, I did talk to our tech team regarding your latest posts and they have asked if you could please confirm what firmware version is being used on the SU-1?
@eric I’m using file 2.22 which is version 2.02 of the firmware for the PS Audio DAC. My understanding of 2.00 vs 2.02 is the former swaps Left & Right channels for the Holo Audio Spring DAC.
I was running 2.02 up until Tuesday morning.
I upgraded the firmware to 2.22 to make sure that this was not the source of the issue and it is still there.
So both the new and old firmware have the same issue.
@Ian_Oliver and @Mark_Kelly1 — Thank you both for getting back to me with the requested information!
Both of your tickets have been updated with the above and diagnostic reports from both of your systems have been attached as well. I am going to be passing over to our tech team for review and once I have an update I will be sure to share the team’s thoughts/findings with you both asap.
Hi @Ian_Oliver ---- Thank you for providing the requested time stamps, VERY appreciated!
I know you mentioned that you had been switching back and forth between various devices acting as core machines. Just to avoid any assumptions this was performed on your ROCK machine correct?
Thanks for verifying @Ian_Oliver! I am going to enable diagnostics on your account now and as mentioned in my previous post this action will automatically be generated/uploaded a diagnostics report containing a set of your Roon logs do the next time Roon is active on that machine. Once the report arrives I will be sure to touch base so you know that I have it.
@eric replicated same problem using same songs starting at 15:39 UK time
When changing bit depth AND sample rate i.e. 16 to 24 and 44.1 to 96 kHz there doesn’t seem to be a problem. However when sample rate remains 44.1 but bit depth goes up from 16 to 24 then we ALWAYS trigger white noise.
Having this additional feedback is greatly appreciated!
this was performed on your ROCK machine correct?