• WANTED: Happy members who like to discuss audio and other topics related to our interest. Desire to learn and share knowledge of science required. There are many reviews of audio hardware and expert members to help answer your questions. Click here to have your audio equipment measured for free!

XMOS reliability/alternatives?

Rotel75

Member
Joined
Oct 29, 2024
Messages
67
Likes
19
Location
Switzerland
I've been using the SMSL SU-1 for a few months now. When it works I'm very happy. But the USB handling seems poor.
see also https://www.audiosciencereview.com/...xmos-usb-dacs-on-a-windows-pc-reliably.59176/

Basically/technically the XMOS chips seem great, but now I'm afraid to get another DAC that has it.
I'd like to know if all DAC with XMOS USB behave like this.
Is there any alternative to XMOS?


Also discussing the issues on the XMOS forum: https://www.xcore.com/viewtopic.php?t=8941

Issue 1 currently on:
- SMSL SU-1 (XU-316)
- Fosi Audio ZD3 (XU-316)

Issue 2 currently on:
- SMSL SU-1 (XU-316)

1) USB disabled on input switch, DAC maker firmware decision or XMOS feature?

2) Squeezelite-X ASIO USB crash, XMOS driver bug?
 
Is there any alternative to XMOS?

Amanero uses a mix of Atmel and Xilinx.

Mostly a product aimed at DIY though. But some retail products use the module.
 
I've been using the SMSL SU-1 for a few months now. When it works I'm very happy. But the USB handling seems poor.
see also https://www.audiosciencereview.com/...xmos-usb-dacs-on-a-windows-pc-reliably.59176/

Basically/technically the XMOS chips seem great, but now I'm afraid to get another DAC that has it.
I'd like to know if all DAC with XMOS USB behave like this.
Is there any alternative to XMOS?


Also discussing the issues on the XMOS forum: https://www.xcore.com/viewtopic.php?t=8941

Issue 1 currently on:
- SMSL SU-1 (XU-316)
- Fosi Audio ZD3 (XU-316)

Issue 2 currently on:
- SMSL SU-1 (XU-316)

1) USB disabled on input switch, DAC maker firmware decision or XMOS feature?

2) Squeezelite-X ASIO USB crash, XMOS driver bug?
XMOS is the most advanced system for USB audio connections. Alternatively, there is Amanero or Xing Audio/Xingcore. After that, the quality deteriorates significantly.

Under Windows, dedicated hardware and drivers, e.g. with HP Business or WS devices, can significantly reduce such problems.

Under OSX, I have not encountered any problems with USB and especially XMOS over the last 10 years with well over 100 DACs and audio devices.
Simultaneous operation with different XMOS hardware versions (XU208, 216, 316) has always been problem-free, both as a multi-device configuration and with simultaneous output from different sources to different devices.

One must not forget that USB was never planned for audio and was actually only intended to be a very cheap consumer interface. One can only take one's hat off to what XMOS, Amanero and Xing Audio/Xingcore and the developers have achieved to make such high-quality USB audio out of it.
 
That's not an XMOS issue.
I didn't want to say it that directly.
Careful handling of the driver installation and use of dedicated hardware and corresponding drivers can greatly reduce or eliminate these problems under Windows.
 
Issue 1 currently on:
IMO fabriceo at XMOS forum nicely explained the cause - when switching to a different output of the DAC box the XMOS is instructed/programmed by the vendor to disable its USB stack. IMO it is not unreasonable as any software should handle unplugging USB devices at any moment gracefully.
Issue 2 currently on:
- SMSL SU-1 (XU-316)
What does actually happen? I cannot understand that from your video. Does Squeezelite crash (no windows msg is shown) or end correctly (though abruptly)?

Your workaround from the XMOS forum means the issue happens when squeezelite tries to open the output device via Portaudio at samplerates higher than 768kHz - the method test_open https://github.com/ralph-irving/squ...be4390c57c6a43373dfdca2/output_pa.c#L206-L241 is never called when you specify user samplerates with the -r parameter. Do you use wasapi exclusive or shared mode in squeezelite?
 
I didn't want to say it that directly.
Careful handling of the driver installation and use of dedicated hardware and corresponding drivers can greatly reduce or eliminate these problems under Windows.
I was not specifically answering to you, more to the OP. ;)
As others have written, it's an implementation issue. Nobody blames Intel or AMD for a bug in MS Office.
 
Issue 1: When switching to SPDIF, isn't it possible for the DAC to keep the USB device active and just not listen to it any more?

About Issue 2:
In Squeezelite-X (windows app) you have to select/save the audio device in the settings. In my case it's USB DAC ASIO.
The first start of the app always works. But on the 2nd or 3rd start, the USB device disappears, and I have to cycle to opt/coax and back to USB to fix it.
I then tried Squeezelite-x64 (cmd line) with the -r 768000 param. USB device stays.
Is Squeezelite-X stressing the driver too much or is the driver poor?
 
Last edited:
1735650672206.png
 
I recently tried with a BananaPi and Armbian
The device list output of "squeezelite -l" changed depending on the current SU-1 input
 
Issue 1: When switching to SPDIF, isn't it possible for the DAC to keep the USB device active and just not listen to it any more?

About Issue 2:
In Squeezelite-X (windows app) you have to select/save the audio device in the settings. In my case it's USB DAC ASIO.
The first start of the app always works. But on the 2nd or 3rd start, the USB device disappears, and I have to cycle to opt/coax and back to USB to fix it.
I then tried Squeezelite-x64 (cmd line) with the -r 768000 param. USB device stays.
Is Squeezelite-X stressing the driver too much or is the driver poor?
Regarding your problem 1
It is completely normal for most DACs to deactivate the USB connection when switching to another input.

This may not be the case for DACS from the pro audio sector, but you will have to ask in the relevant forums.
DACs that have special control functions via USB, e.g. EQ or other interventions, should also maintain the USB connection.
USB audio interfaces would also be an option, as the USB connection is required there.
 
Both of these issues are not major of course... they're just annoying.
SINAD 100, PCM 768k, DSD for $80 :)
If SMSL/Fosi/Topping are listening... please try to keep the USB on in the future (like the pros).
I guess I'll really just get another DAC and dedicate one to streaming/USB only.
 
Issue 1: When switching to SPDIF, isn't it possible for the DAC to keep the USB device active and just not listen to it any more?
Fabriceo has already explained the reasons behind in your XMOS forum thread. The vendor chose to use that method.
About Issue 2:
In Squeezelite-X (windows app) you have to select/save the audio device in the settings. In my case it's USB DAC ASIO.
IIUC the Squeezelite-X uses standard squeezelite exe. It's interesting that the DAC is called "USB DAC ASIO" even though the interface is not ASIO, but WASAPI (that's what squeezelite uses via Portaudio https://github.com/ralph-irving/squ...989dc29ce3be4390c57c6a43373dfdca2/output_pa.c )

The first start of the app always works. But on the 2nd or 3rd start, the USB device disappears, and I have to cycle to opt/coax and back to USB to fix it.
I then tried Squeezelite-x64 (cmd line) with the -r 768000 param. USB device stays.
Is Squeezelite-X stressing the driver too much or is the driver poor?
Again - does your squeezelite use wasapi shared or exclusive https://github.com/ralph-irving/squ...c57c6a43373dfdca2/doc/squeezelite.1#L105-L107 + https://github.com/ralph-irving/squ...be4390c57c6a43373dfdca2/output_pa.c#L189-L198 ?

Squeezelite can output logs (parameters d + f). Maybe they could tell more what is going on. However the squeezelite code on top of Portaudio is not exactly verbose https://github.com/ralph-irving/squ...be4390c57c6a43373dfdca2/output_pa.c#L204-L241 , not logging the important errors like https://github.com/ralph-irving/squ...29ce3be4390c57c6a43373dfdca2/output_pa.c#L222 , https://github.com/ralph-irving/squ...29ce3be4390c57c6a43373dfdca2/output_pa.c#L225 etc. Probably the portaudio call Pa_OpenStream itself would be more verbose but IIUC portaudio would have to be compiled with https://github.com/PortAudio/portau...bff84cbaa952cb/src/common/pa_debugprint.h#L96 which probably is not the case.
 
Both of these issues are not major of course... they're just annoying.
SINAD 100, PCM 768k, DSD for $80 :)
If SMSL/Fosi/Topping are listening... please try to keep the USB on in the future (like the pros).
I guess I'll really just get another DAC and dedicate one to streaming/USB only.
Actually, the DACs aren't doing anything wrong, and as I said, I don't know of either problem on the MAC, despite having well over 100 devices and certainly over 50 software products.

Under Windows, this can be a cascaded problem of PC hardware, hardware/system drivers, and XMOS drivers, which is sometimes difficult to isolate or solve.
I always advise people, based on decades of professional experience, to use high-quality and dedicated hardware.
For a customer, I once replaced over 600 PCs and notebooks, known on the market as not bad hardware, with HP Business PCs, notebooks and workstations. The problems (hardware, software, also USB) decreased by well over 90%.
You can get usable used devices from €/$ 150, HP Renew from €/$ 500-1000.

Regarding Squeezelite-X, have a look at the RME forum, I read something about problems with it at some point.
 
You can get usable used devices from €/$ 150, HP Renew from €/$ 500-1000.
IMO there is no HW problem on the USB-host side, and an HP-produced PC would behave exactly same as any other PC model in this particular case. Squeezelite tries to open the wasapi device at > 768kHz samplerates https://github.com/ralph-irving/squ...ce3be4390c57c6a43373dfdca2/squeezelite.h#L641 . It's either the windows mixer (we do not know whether it's involved (wasapi-shared) or not (wasapi-exclusive)), or the windows driver.

To investigate I would suggest to start with wasapi exlusive setup for squeezelite (to avoid the windows mixer alltogether) and windows stock UAC2 driver if the sound device is UAC2 compliant (to avoid a vendor-custom UAC2 driver if actually used). Windows stock UAC2 driver is OK with requests for high samplerates (I have tested it at 3.9MHz samplerate https://www.diyaudio.com/community/threads/linux-usb-audio-gadget-rpi4-otg.342070/post-6725714 )
 
IMO there is no HW problem on the USB-host side, and an HP-produced PC would behave exactly same as any other PC model in this particular case. Squeezelite tries to open the wasapi device at > 768kHz samplerates https://github.com/ralph-irving/squ...ce3be4390c57c6a43373dfdca2/squeezelite.h#L641 . It's either the windows mixer (we do not know whether it's involved (wasapi-shared) or not (wasapi-exclusive)), or the windows driver.

To investigate I would suggest to start with wasapi exlusive setup for squeezelite (to avoid the windows mixer alltogether) and windows stock UAC2 driver if the sound device is UAC2 compliant (to avoid a vendor-custom UAC2 driver if actually used). Windows stock UAC2 driver is OK with requests for high samplerates (I have tested it at 3.9MHz samplerate https://www.diyaudio.com/community/threads/linux-usb-audio-gadget-rpi4-otg.342070/post-6725714 )
That only referred to the first problem, although I'm not sure if there is a problem at all.
 
Back
Top Bottom