Warning for desktop users: SMSL stacks have issues without workarounds (PC/Mac)

[analogue]

Hi,

I just acquired an SMSL stack for desktop use composed of:

• SMSL SH-9 desktop amp
• SMSL SU-9 Pro desktop DAC

And after a day of configuring, testing and digging, I found out issues that will make me return the stack as it's an UX downgrade compared to my old Schiit stack Modi3+Magni3.

Here are the issues:

Low: Too many volume steps on the SMSL SH-9 amp​

The volume of the SH-9 goes from 0 to 100, but it only increases by 20 per full turn (10 for a comfortable half-turn), which means that to go from a low volume 10 which I use on a quiet night to a 50 when I want to enjoy the depth of a song, it takes me 4 half turns. This issue could easily be solved with a volume step setting in the firmware, but given that I saw the same complains about the SMSL amp for months, I doubt it's ever going to be fixed.

Low: Misleading "Filter Off" PCM Filter on the SMSL SU-9 Pro​

With the new ES9039MPRO chip, SMSL added the "Filter Off" PCM Filter option. When I setup the DAC, I reset it and went to all settings to set them to the most clean and basic set. This was a bad idea, because the Filter Off makes songs saturate. I spent a lot of time trying to understand what was wrong, and after finding out this thread: https://www.audiosciencereview.com/...l-d400es-dac-review.40884/page-7#post-1451478 I noticed it was the PCM Filter Off setting. It's not a big issue as we just don't have to use it, but I'd rather state it here because it's a very misleading issue that others might encounter and think their DAC is faulty.

High: the DAC goes "away" after 5s with no sound on the SMSL SU-9 Pro​

This one is the biggest issue: The DAC goes into pseudo "sleep" mode if no application sends data on USB after 5s. This is fine if you are listening to some music or playing some game. But when you do desktop stuff, it means any new sound will get its 1st 1/2s silent. This makes the DAC unusable as any notification sound will be silent, and each time you go see some youtube video, the sound always starts .5s after the real start, leading to a sound that's always "cut". It's a known issue found by others: This annoying enabled feature in the SMSL firmware can be overridden on Windows by following those instructions: https://www.audiosciencereview.com/...os-driver-settings-for-no-cutoff-delay.25838/ but there is no driver on MacOS and thus there is no way to disable this behavior. This is easy to replicate under Windows or MacOS: On Windows, go to the sound properties of your OS (where you chose your system sound) and click the test sound button. After 5s of silence, you'll never hear it the 1st time. Same on MacOS in the sound properties if you click the "sound alert": You can't hear the 1st sound, or any alert sound after a 5s silence.

No hope -> RMA​

Those 3 problems could be fixed with a firmware upgrade, but given that the SH-9 is years old now, and that there is no firmware upgrade at all on https://www.smsl-audio.com/portal/product/downlist/id/13.html for both SMSL amps and stacks, I'm not optimistic, and I'd rather send them back. I sent SMSL an email just in case.

I wonder if it's an SMSL issue (they set bad defaults), or an XMOS XU316 issue (it would impact Topping and others).

I just know that the DAC issue does not happen on my Schiit stack, which does not use an XMOS USB chip, but an "Schiit Unison USB™".

I'm making this post for 3 reasons:

1. Maybe someone will mention workarounds for any of those issues before I can RMA my stack.
2. It was hard for me to find the reason of those issues, and it might help new owners understand what's wrong with their units when they Google it.
3. Warning for potential SMSL MacOS buyers.

 

[metalrufflez]

Hello, I've just received an SMSL C200 last sunday and I'm in the same predicament as you.

I've noticed the issue seems to be with XMOS itself and not specific brand/model, as my Fiio K3, which also contains a XMOS have the same behavior, while my Qudelix 5k does not (and it doesn't seem to uses an XMOS chip).

I'm still researching how to deal with this, as I'm sure we're not the first ones to hit this issue and there's certainly a way to configure coreaudiod to use "always on" mode, similar as in Windows.

 

[Lambda]

Would be nice if we would have Open source Digital to Digital interface or "DAC controller" and some manufactures that focus on building good actual "DAC modules."

 

[analogue]

I've noticed the issue seems to be with XMOS itself and not specific brand/model, as my Fiio K3, which also contains a XMOS have the same behavior, while my Qudelix 5k does not (and it doesn't seem to uses an XMOS chip).

You are right, it has a XMOS XUF208. This means this problem would happen on all DAC with XMOS, including toppings? It seems weird that everyone would live with this issue. I thought it would be a problem specific to SMSL implementation given how few people complain.

I plugged back my Schiit stack and their "Schiit Unison USB™" and the the problem is no more.

 

[rentaclaus]

This means this problem would happen on all DAC with XMOS, including toppings?

IMHO this problem is related to powersavings of the operation system... you can disable powersaving in e.g. Windows and Linux (don't know how to in OS-X for macs) and the problem is magically away.
How to in Windows has already been linked in this thread, here's how to in linux.
https://www.audiosciencereview.com/.../how-to-disable-power-savings-in-linux.40511/

 

[analogue]

IMHO this problem is related to powersavings of the operation system... you can disable powersaving in e.g. Windows and Linux (don't know how to in OS-X for macs) and the problem is magically away.
How to in Windows has already been linked in this thread, here's how to in linux.
https://www.audiosciencereview.com/.../how-to-disable-power-savings-in-linux.40511/

The problem is not related to the powersavings of the OS as a whole, but to the USB XMOS chip:
- on Windows, setting the power savings to "High Performance" does not fix the issue
- on MacOS, setting the power savings to "none" does not fix the issue

If you look at your instructions on Linux, you actually touch /sys/module/snd_usb_audio/parameters/power_save which is telling the usb audio to not power save, not the whole OS, and I'm guessigng this is the same as hacking the windows driver to not let the USB chip enter powersave in

XMOS driver settings for no cutoff/delay

I was contemplating on creating a "tutorial" of sorts for all XMOS drivers on devices that have a cutoff -- latency between the start of a sound and the dac "reacting" and actually playing said sound... So here it is: XMOS drivers use a control panel not unlike this: Usually the "Options"...

www.audiosciencereview.com

The problem is that there is no such setting on MacOS.

 

[Snoopy]

And there is no way to do this in the Unix based terminal on Mac? I can't imagine it's not possible.

Anyway...I use the amphetamine app for Mac os. Prevents it from going to sleep. And I stream my music to roon endpoints.

No issue at all.

 

[metalrufflez]

Agreed this is not related to power saving. Looking at the console, ever sound that systemsoundserverd wants to emit, a new session is created to coreaudiod, that closes it as soon as the sound is played. When a music/movie is playing a session is always open, hence, no delay, which is what the option in the xmos driver in windows does.

There's got to be a hacky way to keep a "silent" session always open in the background somehow.

 

[rentaclaus]

There's got to be a hacky way to keep a "silent" session always open in the background somehow.

Maybe this

"defaults write NSGlobalDomain NSAppSleepDisabled -bool YES"

but it affects the system as a whole...

 

[analogue]

And there is no way to do this in the Unix based terminal on Mac? I can't imagine it's not possible.

Yes there is a terminal, but there is no kernel module, it's not using the Linux kernel.

Anyway...I use the amphetamine app for Mac os. Prevents it from going to sleep. And I stream my music to roon endpoints.

So you are using an application to keep you Mac always fully on, that works but at what cost... Yes if I keep some audio app running silent, the problem goes away. But I prefer to just not use an XMOS DAC and not have to have to use dirty workarounds messing with OS powersaving.

There's got to be a hacky way to keep a "silent" session always open in the background somehow.

Or better, tell the XMOS to not powersave. I mean, it's working great with the Schiit USB DAC, and it's working great with a Creative DAC, both don't use XMOS...

I can live without an XMOS powered DAC, too bad for them.

 

[analogue]

Maybe this

"defaults write NSGlobalDomain NSAppSleepDisabled -bool YES"

but it affects the system as a whole...

Can't test anymore as I RMAed the SMSL DAC, maybe someone else can? But even if it works, who wants to lose the amazing battery saving of the Mac just to use an XMOS powered DAC? Seriously... =(
Desktop DAC should not powersave unless the actual OS is asleep...

 

[Snoopy]

M1 & M2 Mac's don't waste that much energy if you leave them always on. I don't see the issue here. My MacBook is on all the time anyway because I use it as roon server.


And you can tell the app to prevent the Mac from going to sleep only while a certain app is running.
Let that cpu idle all day long...no big deal.

 

[BenF]

You are right, it has a XMOS XUF208. This means this problem would happen on all DAC with XMOS, including toppings? It seems weird that everyone would live with this issue. I thought it would be a problem specific to SMSL implementation given how few people complain.

I plugged back my Schiit stack and their "Schiit Unison USB™" and the the problem is no more.

I use a Topping D30 Pro with XMOS XU208 chipset on my Mac mini M1 (2020). I have no problems at all...

 

[analogue]

M1 & M2 Mac's don't waste that much energy if you leave them always on. I don't see the issue here. My MacBook is on all the time anyway because I use it as roon server.


And you can tell the app to prevent the Mac from going to sleep only while a certain app is running.
Let that cpu idle all day long...no big deal.

Either NSAppSleepDisabled has an effect, and in this case more energy will be wasted, and the battery will drain faster, either it's useless and why even talking about it?

 

[metalrufflez]

I use a Topping D30 Pro with XMOS XU208 chipset on my Mac mini M1 (2020). I have no problems at all...

That's interesting. So after 5~10 seconds of silence, if you play a quick sound notification (Jump for example) a couple of times, you always hear the two and not just the second one?

 

[BenF]

That's interesting. So after 5~10 seconds of silence, if you play a quick sound notification (Jump for example) a couple of times, you always hear the two and not just the second one?

Yes, I do.

Edit: I also tested with Topping D90 (original D90, non-MQA version). No problems there either.

 

[analogue]

Here's the official answer from [email protected], which does the official support for SMSL:

Hi there dear customer
There is no driver on the Apple system ...
It is recommended that you do not adjust the performance of DAC to the energy saving mode
Looking forward to your reply

So not sure if it's XMOS or SMSL/FiiO/... specific, but that's definitely not fixable on MacOS, and it's suggested to not even touch the energy saving mode on Windows.
I'll pass.

 

[bbrown]

High: the DAC goes "away" after 5s with no sound on the SMSL SU-9 Pro

It's amazing to me how anyone with live with this behavior. I just received a SMSL C200 and it does the same thing with my new Mac mini M2 pro. I think people are conflating the OS going to sleep (and there may be other issues with that) and the XMOS chip going to sleep. The XMOS chip is a micro controller and is capable of turning this sleep mode off as proven by the Windows driver fix. We just need a fix for MacOS. I realize there's no "driver" in MacOS that has parameters exposed through the GUI, but there maybe there's a parameter accessible through the shell. This could also be easily fixed with a firmware update with or without a setting on the DAC. But like you, sadly my C200 is going back to Amazon this week. Do you know of a similar product in a similar price range that doesn't use the XMOS chip or at least doesn't have this problem? My DAC requirements are: TRS balanced outputs, USB, coax, toslink, BT inputs and a headphone output with high gain setting. Thanks.

 

[analogue]

Do you know of a similar product in a similar price range that doesn't use the XMOS chip or at least doesn't have this problem? My DAC requirements are: TRS balanced outputs, USB, coax, toslink, BT inputs and a headphone output with high gain setting. Thanks.

I can confirm 2 brands (not necessarily fitting your reqs): Any Schiit will do as they have their own USB chip. The Creative Soundblaster X5 works well too.

Someone in this thread said Topping does not have the issue despite using XMOS: they might have disabled this "feature" on the chip, but I can't confirm myself.

 

[Wekhrlin]

Had the C200, too. Replaced it with the SMSL C100 (and a suitable amplifier) which has a XMOS XU-316. It works perfectly fine now.