I recently started working with XS1(U8A) and this week I had the opportunity to get to know XS2(XU208).
XS1 [2in/2out]
Linux works great! (latest kernel 6.11).
Windows10/11 requires a device driver if it has inputs.
When there is only 2out, then it is detected by Windows natively (WASAPI).
XS2(XU208) the situation is reversed, in Windows the inputs are detected normally, but in Linux they are not.
Can someone explain if Linux support for XS2 is not yet complete, or why this happens?
XS1 works well, I thought XS2 would too.
best regards.
ALSA Linux support / Windows WASAPI
-
- Junior Member
- Posts: 4
- Joined: Mon Oct 21, 2024 3:14 am
-
- XCore Addict
- Posts: 179
- Joined: Mon Apr 16, 2018 9:14 am
XS2 may or may not be compatible. It's fully programmable. Both Windows and Linux use the UAC2.0 driver with some limitations, so you need to make sure you have the right firmware. It would be better to use Explicit Feedback no matter what OS or XMOS generation.
In my XS2 based commercial products with very customized firmware I have 100% tested compatibility with any OS (iOS, Android, Linux, Mac OSX, Windows). So it's all about firmware and programmer skills.
In my XS2 based commercial products with very customized firmware I have 100% tested compatibility with any OS (iOS, Android, Linux, Mac OSX, Windows). So it's all about firmware and programmer skills.
-
Verified
- XCore Legend
- Posts: 1163
- Joined: Thu Dec 10, 2009 9:20 pm
- Location: Bristol, UK
For your windows issues consider clearing your driver cache, here is a neat tool: https://www.nirsoft.net/utils/usb_devices_view.html
If you've built the device without input and they rebuilt with input (and not changed the VID/PID pair) then expect issues related to driver caching on Windows.
If you've built the device without input and they rebuilt with input (and not changed the VID/PID pair) then expect issues related to driver caching on Windows.
Technical Director @ XMOS. Opinions expressed are my own
-
- XCore Addict
- Posts: 179
- Joined: Mon Apr 16, 2018 9:14 am
When you debug your firmware in Linux, go look to the /var/log/kern.log in your system.
If you see "clock source 41 is not valid, cannot use"
While Windows and Apple don't care and worked fine, Linux was hanging on the get clock or set clock command. I saw many users with XMOS based devices reported exactly the same problem on Linux forums here and there.
Solution that worked for me for XS2 code, see my post:
https://www.xcore.com/viewtopic.php?p=39957#p39957
Just reporting all the time Internal Clock selected if you don't use SPDIF/ADAT input.
So it's all about proper firmware, not XMOS hw doesn't compatible with Linux. Right? 'Cause my devices work fine with any OS.
If you see "clock source 41 is not valid, cannot use"
While Windows and Apple don't care and worked fine, Linux was hanging on the get clock or set clock command. I saw many users with XMOS based devices reported exactly the same problem on Linux forums here and there.
Solution that worked for me for XS2 code, see my post:
https://www.xcore.com/viewtopic.php?p=39957#p39957
Just reporting all the time Internal Clock selected if you don't use SPDIF/ADAT input.
So it's all about proper firmware, not XMOS hw doesn't compatible with Linux. Right? 'Cause my devices work fine with any OS.
Last edited by MaximLiadov on Thu Nov 14, 2024 9:49 pm, edited 1 time in total.
-
Verified
- XCore Legend
- Posts: 1163
- Joined: Thu Dec 10, 2009 9:20 pm
- Location: Bristol, UK
Maxim,
The code should already report Internal Clock if no other clocks are present (the c_clk_ctl chanend should be null). See:
https://github.com/xmos/lib_xua/blob/50 ... qs.xc#L538
(that magic number "1" should be using CLOCK_INTERNAL really..)
Were you using an older codebase maybe?
Setting shouldn't matter, unless the code you were using was missing the isnull() check on the c_clk_ctl chanend - that would cause the device to lock up I should imagine.
Cheers
Ross
The code should already report Internal Clock if no other clocks are present (the c_clk_ctl chanend should be null). See:
https://github.com/xmos/lib_xua/blob/50 ... qs.xc#L538
(that magic number "1" should be using CLOCK_INTERNAL really..)
Were you using an older codebase maybe?
Setting shouldn't matter, unless the code you were using was missing the isnull() check on the c_clk_ctl chanend - that would cause the device to lock up I should imagine.
Cheers
Ross
Technical Director @ XMOS. Opinions expressed are my own
-
- XCore Addict
- Posts: 179
- Joined: Mon Apr 16, 2018 9:14 am
You are right. I used this trick a few years ago, before lib_xua existed. Very glad to hear you fixed it in the new code. Cannot wait to try it for my new XU316 project. Anyway, my speech was about debugging firmware with /var/log/kern.log I hope it helps sparkJulio as his symptoms are exactly what I had in the past. Please, take no offence.
-
Verified
- XCore Legend
- Posts: 1163
- Joined: Thu Dec 10, 2009 9:20 pm
- Location: Bristol, UK
Absolutely no offence taken, just wanted to make sure we hadn’t missed a bug. Thanks for your help :)
Technical Director @ XMOS. Opinions expressed are my own
-
- Junior Member
- Posts: 4
- Joined: Mon Oct 21, 2024 3:14 am
Please define "programmer skills".MaximLiadov wrote: ↑Thu Nov 14, 2024 10:52 am XS2 may or may not be compatible. It's fully programmable. Both Windows and Linux use the UAC2.0 driver with some limitations, so you need to make sure you have the right firmware. It would be better to use Explicit Feedback no matter what OS or XMOS generation.
In my XS2 based commercial products with very customized firmware I have 100% tested compatibility with any OS (iOS, Android, Linux, Mac OSX, Windows). So it's all about firmware and programmer skills.
Nowhere in the documentation are there any explicit differences in code between operating systems... so, asked.
Maybe i'm not aware of this necessary "skill" you're referring to.
Thanks anyway.
-
- XCore Addict
- Posts: 179
- Joined: Mon Apr 16, 2018 9:14 am
sparkJulio
I apologize if I am wrong about the grammar. My first language is C, not English. :) Being a bit more experienced, I shared my knowledge with you for free, buddy. It's your choice to use it or not.
I apologize if I am wrong about the grammar. My first language is C, not English. :) Being a bit more experienced, I shared my knowledge with you for free, buddy. It's your choice to use it or not.
-
Verified
- XCore Legend
- Posts: 1163
- Joined: Thu Dec 10, 2009 9:20 pm
- Location: Bristol, UK
I think what Maxim was trying to say is that the chip doesn’t matter too much, in this respect, it’s the software that’s important.
The only caveat to that is that xs1 is EOL and the code is not longer actively maintained for it. However, we have products still launching that are based on xs1. It’s solid (though not recommended)
The only caveat to that is that xs1 is EOL and the code is not longer actively maintained for it. However, we have products still launching that are based on xs1. It’s solid (though not recommended)
Technical Director @ XMOS. Opinions expressed are my own