XMOS driver settings for no cutoff/delay

[Veri]

Wait ... is this issue just for SMSL dacs or any dac using XMOS chips?

It's not brand specific but if there is some relay based solution there should be no or little popping. This thread explains a way in software to keep the driver I/O always open to prevent little pops. In case you have some hardware that suffers from it.

 

[David_M]

It's not brand specific but if there is some relay based solution there should be no or little popping. This thread explains a way in software to keep the driver I/O always open to prevent little pops. In case you have some hardware that suffers from it.

So not all SMSL (or whoever) dacs using this XMOS chips suffer from these glitches?

 

[Veri]

So not all SMSL (or whoever) dacs using this XMOS chips suffer from these glitches?

No it's highly device dependent.

 

[MaxwellsEq]

So not all SMSL (or whoever) dacs using this XMOS chips suffer from these glitches?

To be clear - they are not glitches in the sense that something is corrupting the audio. What's happening is that when you are not listening to audio, the device goes into a lower power mode. Entering and leaving this mode causes a low level "tick" sound. Once you are listening there are no more noises until you stop listening.

This low power mode is an option. If you deselect this option, you use more power, but you don't get the click when the power goes on or off.

Some DACs set this mode on by default. My Sabaj does. Some DACs make the option easily available. My Sabaj doesn't. But the solution proposed here worked for me.

 

[boxerfan88]

Hi there,

I have a clarification question.
In the XMOS control panel, they show ASIO "Input Latency" and "Output Latency".
What do these mean?

Is the total latency through the DAC = Input Latency + Output Latency ?

Thanks for any insights ...

 

[David_M]

Which is a better sound path (jitter wise, SINAD/THD+N), etc.) for my new SMSL DO400 I just received yesterday? Below is my audio path. All my audio and video is via streaming from my PC Workstation (128GB ddr4 ram ).

1. PC Optical Out --> FlexDSP Optical In -->FlexDSP Optical Out --> DO400 Optical In... --> Full optical path, hence excellent hum isolation.
2. PC USB_1 Out --> FlexDSP USB In -->FlexDSP Optical Out --> DO400 Optical In... --> Optical path, also excellent hum isolation.
3. PC USB_1 Out --> FlexDSP USB In -->FlexDSP USB Out --> DO400 USB In... --> No hum isolation but I don't hear (yet) in this mode.
4. PC USB_2 Out --> DO400 USB In... --> No hum isolation but also no DSP for my 2.1 monitor/sub setup on my desk. Also this setup has no dsp since my monitors are 3 ft away on my desk from me, the sound FR is lopsided or shelved/tilted to the left (bass freqs are +7 to +8dB and high freqs are -5 to -6dB low from reference line.

 

[AndrewC]

Hi there,

I have a clarification question.
In the XMOS control panel, they show ASIO "Input Latency" and "Output Latency".
What do these mean?

Is the total latency through the DAC = Input Latency + Output Latency ?

Thanks for any insights ...


View attachment 316513

IINM, it's the FIFO Buffers before the DAC conversion stage. It (adds to) but is not directly related to the overall DAC latency.

 

[boxerfan88]

IINM, it's the FIFO Buffers before the DAC conversion stage. It (adds to) but is not directly related to the overall DAC latency.

Thank you for your input.
So it's just the transmission stage (source side XMOS driver latency + DAC side XMOS receiver latency); excluding DAC module conversion latency.

 

[David_M]

Thank you for your input.
So it's just the transmission stage (source side XMOS driver latency + DAC side XMOS receiver latency); excluding DAC module conversion latency.

Win10 performs the sample rate conversion, XMOS driver buffers the audio samples and sends regular DMA bursts or writes to the XMOS buffer. If the XMOS driver in inwodws is set to buffer 512 samples, then 512 samples are sent to the buffer every 'nnn' microseconds.

 

[Grooved]

Hi there,

I have a clarification question.
In the XMOS control panel, they show ASIO "Input Latency" and "Output Latency".
What do these mean?

Is the total latency through the DAC = Input Latency + Output Latency ?

Thanks for any insights ...


View attachment 316513

IINM, it's the FIFO Buffers before the DAC conversion stage. It (adds to) but is not directly related to the overall DAC latency.

I don't think it's linked to FIFO, I think it's just that the inputs on XU316 are actived, even if not used in the DAC, to provide better compatibility in ASIO mode.
It's known that some softwares can use ASIO driver correctly only if there are outputs and inputs listed in the driver.

So I think it's really the "input latency" of the XU316, just that it has no impact here as it's a DAC only, like the "output latency" has no impact for an ADC only. Then both will have impact if the chipset is use in an audio interface with inputs and outputs.

It was the case for example with the Cosmos ADC, the Comtrue ASIO driver started to be really usable once both inputs and outputs were activated on the chipset, even if it's only an ADC.
You can now see the ASIO driver in inputs and outputs selection lists of any software supporting ASIO, but only the inputs will provide sound

 

[th2j]

For Linux, if you use Squeezelite (piCorePlayer, etc.) you can add a delay between tracks with different rates,
1400ms works for me, it stops the clicks/pops (a lower value doesn't work) :

Squeezelite parameter :
-r 44100,48000,88200,96000,192000:1400

 

[oidarnam]

I bought

Thank you very much. Works with SMSL D-6 DAC.

That's great. Looks like I'm returning my S.M.S.L. D-6. I could not get it to stop "ticking" or "clicking" all the time (and throw in a loud pop, too, when selecting DAC USB input) on my Linux desktop. I tried setting session.suspend-timeout-seconds = 0 in alsa-monitor.conf and a few other things—nothing helped. I have an old Emotiva USB DAC and Schiit Modi 3E and they don't make any of these irritating noises. I'm not sure if I got a bad unit or this is a design flaw. My uneducated guess is that the DAC is not muting the output during USB stream negotiations. I'm going to include an excerpt below of what I sent to the retailer support team in case it's useful to others.

Here are my system details:

Standard Ubuntu Linux 22.04 LTS install with 6.2.0-37-generic kernel.
Audio stack is totally standard for 22.04 "jammy" installation with the kernel USB, ALSA, and PulseAudio server, with PipeWire for WebRTC using pipewire-pulse interface.

The host is an HP Z230 workstation with Intel(R) Core(TM) i7-4790 CPU @ 3.60GHz x8 virtual cores, 1TB SSD, 4TB RAID 1, and 24.0 GiB of RAM.

I have the above host computer plugged into the D-6 USB input. I have a TCL smart TV plugged into the D-6 optical input.
The clicking and popping only seem to occur with USB.

Here are some symptoms:

• I get no clicks, ticks, or pops from toslink, except two ticks when Opt input first selected.
• Even with the host computer audio server muted, if I select to the D-6 USB input, I hear a set of "tick-tick-[...] tick-tick-POP-tick..." coming through my amp and speakers. This happens with any open USB port on the computer, USB2 or USB3. Also, I still hear these "input selection" ticks/pops when D-6 volume is set to 0 but NOT when the D-6 itself is muted.
• When I use a PC audio application that goes direct to the D-6, bypassing the host audio server/mixer (e.g. Plexamp which I use to listen to my local music library and Tidal streaming), I only hear a series of ticks/clicks if the sample rate changes. So there are no annoying artifacts between tracks or albums at the same sample rate. That's good.
• The ticking problem is worse in some PC applications I use like browsers (Chrome-based and Firefox) and Plex or HTPC player programs. In this case, the series of ticks happen when I first select something with audio, like a YouTube video or watch a movie. I also usually hear a series of ticks if I "timeshift" the video/music to start at a different point. I also hear a series of ticks some time after stopping or leaving an AV player. Sometimes I hear ticks when I change a volume control.
• Changing the D-6 from preamp mode to DAC mode doesn't make a difference.
• I have Emotiva and Schiit DACs too. They don't have any of these audio artifacts like the S.M.S.L.
• I have read quite a few discussions on the web about DAC clicks and pops in general. It isn't uncommon. And there are several discussions about audio artifacts on this brand and model of DAC too.
• I'm no expert, but given the symptoms, some information I've read, and the fact that my other dacs don't do this—I tend to think the D-6 mute isn't properly masking these noises during some sort of stream initiation and release. Now whether it's just this particular unit or the D-6 design in general, I don't know.

 

[JIW]

I have an SMSL DL200 with XMOS XU-316 connected via USB on macOS and have found a way to avoid dis- and reconnecting.

When the DL200 is selected as output in the Qobuz app without even having played anything or not playing anything anymore, the DL200 is always connected as long as the Qobuz app is not quit even after the sample rate is changed in the Audio MIDI Setup. The same might work for other programs where the DL200 can be selected as output device.

 

[danielpugh]

worked for my smsl-d6s

 

[bboris77]

I have an SMSL DL200 with XMOS XU-316 connected via USB on macOS and have found a way to avoid dis- and reconnecting.

When the DL200 is selected as output in the Qobuz app without even having played anything or not playing anything anymore, the DL200 is always connected as long as the Qobuz app is not quit even after the sample rate is changed in the Audio MIDI Setup. The same might work for other programs where the DL200 can be selected as output device.

OMG, this workaround actually 100% worked. This means that solution is very simple but someone has to write a piece of software that does this in Mac OS.

 

[JIW]

OMG, this workaround actually 100% worked. This means that solution is very simple but someone has to write a piece of software that does this in Mac OS.

Did it work with Qobuz or did you use another program?

 

[bboris77]

Did it work with Qobuz or did you use another program?

With Qobuz specifically.

 

[bboris77]

With Qobuz specifically.

If I were @SMSL-Mandy, I’d be contacting Qobuz to figure out how they are managing to keep these XMOS devices from going to sleep. It ought to be a fairly simple/trivial fix that would keep a lot of Mac users happy. I know we tend to be forgotten since we’re in the minority, but we are fairly vocal .

 

[JIW]

If I were @SMSL-Mandy, I’d be contacting Qobuz to figure out how they are managing to keep these XMOS devices from going to sleep. It ought to be a fairly simple/trivial fix that would keep a lot of Mac users happy. I know we tend to be forgotten since we’re in the minority, but we are fairly vocal .

It might just stream zeros continuously at the last used file format. That way the DAC receives samples preventing disconnecting but there is no output. Even if the sample rate is changed, the zero samples are just resamples by the OS but still transmitted.

The challenge is sending those samples in conjunction with other samples from another program. In macOS it goes through the Core Audio mixer anyways and assuming there is a cutoff time for summing samples from sources, since the samples are all zero they add nothing to another signal and transmission of the latter is bit perfect as long as the sample rates are both identical to that of the file being played and it is 24 or 32 bits depending on the file and what is selected in the Audio MIDI Setup.