JRiver + SMSL SU-9 + XMOS keeping previous track in the buffer

Discussions about USB Audio on XMOS devices
User avatar
mikolajek
Junior Member
Posts: 4
Joined: Mon Jan 20, 2025 6:11 pm

JRiver + SMSL SU-9 + XMOS keeping previous track in the buffer

Post by mikolajek »

I'm using SMSL SU-9 DAC with JRiver Media Center set to the DSD output, and the XMOS driver obviously (ver. 5.70). The config works well and plays nicely to my ears, there's just one glitch.

When changing tracks manually (e.g. switching to a different album or even to a different song), it seems a part of the previous song stays in the buffer. So instead of playing a new song from the beginning, I first hear 1-2 seconds of the previous song :( . Is there a way to avoid it?

I tried to decrease XMOS driver buffer size, but when JRiver is started it automatically gets back to the highest value possible (32,768 samples), I also tried to decrease JRiver buffer size and turn off the hardware buffer, but there's no difference...
MaximLiadov
XCore Addict
Posts: 179
Joined: Mon Apr 16, 2018 9:14 am

Post by MaximLiadov »

To rule out any hardware issues, try using foobar2000. For 1-2 seconds of the song, the XMOS MCU has no internal RAM, as a firmware developer I can assure you. As far as I know, XMOS has nothing to do with the 5.70 driver, which was made by the Thesycon guys and licensed by the SMSL people. It's also SMSL that has developed firmware for the XMOS MCU. As a customer who paid your money to SMSL, you'd better ask their technical support or end user forum.The second decent option is to ask the guys at JRiver Software.
MaximLiadov
XCore Addict
Posts: 179
Joined: Mon Apr 16, 2018 9:14 am

Post by MaximLiadov »

I feel your pain. I just installed JRiver. It has a very annoying default option called "Use large hardware buffers". Only when I turned it off, I was able to set it to a small enough one. 32768 samples buffer is totally insane. If you cannot turn off auto buffering, it is certainly a JRiver problem.
User avatar
mikolajek
Junior Member
Posts: 4
Joined: Mon Jan 20, 2025 6:11 pm

Post by mikolajek »

Thanks a lot!

I installed Foobar and indeed no "remnants" of the previous track appear when manually changing tracks. Then I played with JRiver and the XMOS driver, and I found the only settings combination that works:
- JRiver's "use large hardware buffers" option was turned OFF and the "minimum hardware size" was selected under the buffering dropdown (any other buffer size - even 5 ms - leaves some sound in the buffer)
- "Safe Mode" was turned out in XMOS DAC driver, and the number of samples was set at 16,384 (any lower value results in sound breaking)

I still feel though the above config deteriorates my DSP sound quality, and these settings are far from optimal... What do you think?

At the same time I wouldn'y like to drop off JRiver as it typically produces great sound and it library management capabilities (customization primarily) are great.
MaximLiadov
XCore Addict
Posts: 179
Joined: Mon Apr 16, 2018 9:14 am

Post by MaximLiadov »

mikolajek wrote: Wed Jan 22, 2025 9:43 am 16,384 (any lower value results in sound breaking)
This does not look like a good sign.You need to optimize your OS for sound applications. Windows does need in this. https://www.resplendence.com/latencymon would be a good starting point. Turn off all the power saving features in the BIOS if possible. Then disable core parking. Then force the use of the video drivers from the first core to a different one. It's a useless default power saving thing. If you have an Nvidia graphics card, the maximum performance setting in its control panel is a must. I'm sure you can find more information on Google and audio forums for end users. Even with 64 samples, I personally don't have any problems with my XMOS devices in any kind of software. So it really does work.
User avatar
mikolajek
Junior Member
Posts: 4
Joined: Mon Jan 20, 2025 6:11 pm

Post by mikolajek »

Huh, I've tweaked my power plan to "everything disabled", disabled core parking and most of the BIOS items feasible (but I see from Dell it's strongly not advised to disable SpeedStep). It doesn't seem to help though :)
MaximLiadov
XCore Addict
Posts: 179
Joined: Mon Apr 16, 2018 9:14 am

Post by MaximLiadov »

LatencyMon checks if a system running Windows is suitable for processing real-time audio and other tasks. LatencyMon analyzes the possible causes of buffer underruns by measuring kernel timer latencies and reporting DPC and ISR execution times as well as hard pagefaults. It will provide a comprehensible report and find the kernel modules and processes responsible for causing audio latencies which result in drop outs.
User avatar
mikolajek
Junior Member
Posts: 4
Joined: Mon Jan 20, 2025 6:11 pm

Post by mikolajek »

Hmmm... It doesn't seem my system suffers from any issues related to music processing... Anything I can check more?

Image
MaximLiadov
XCore Addict
Posts: 179
Joined: Mon Apr 16, 2018 9:14 am

Post by MaximLiadov »

https://www.google.com/search?q=acpi.sys+audio+dropouts

In my system I had no problems playing music even with a 64-sample buffer. The screenshot below was taken when foobar2000 was playing through ASIO. I do use an XMOS device and Thesycon drivers like you do.
You do not have the required permissions to view the files attached to this post.
User avatar
Ross
Verified
XCore Legend
Posts: 1158
Joined: Thu Dec 10, 2009 9:20 pm
Location: Bristol, UK

Post by Ross »

Sounds like a Jriver issue - there're no buffer large enough in the xcore for multiple seconds of audio - or shouldn't be anyway. Suggest asking them for support.
Technical Director @ XMOS. Opinions expressed are my own