ALSA Linux support / Windows WASAPI

Technical discussions around xCORE processors (e.g. xcore-200 & xcore.ai).
sparkJulio
Junior Member
Posts: 4
Joined: Mon Oct 21, 2024 3:14 am

ALSA Linux support / Windows WASAPI

Post by sparkJulio »

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.
MaximLiadov
XCore Addict
Posts: 179
Joined: Mon Apr 16, 2018 9:14 am

Post by MaximLiadov »

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.
User avatar
Ross
Verified
XCore Legend
Posts: 1163
Joined: Thu Dec 10, 2009 9:20 pm
Location: Bristol, UK

Post by Ross »

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.
Technical Director @ XMOS. Opinions expressed are my own
MaximLiadov
XCore Addict
Posts: 179
Joined: Mon Apr 16, 2018 9:14 am

Post by MaximLiadov »

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.
Last edited by MaximLiadov on Thu Nov 14, 2024 9:49 pm, edited 1 time in total.
User avatar
Ross
Verified
XCore Legend
Posts: 1163
Joined: Thu Dec 10, 2009 9:20 pm
Location: Bristol, UK

Post by Ross »

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
Technical Director @ XMOS. Opinions expressed are my own
MaximLiadov
XCore Addict
Posts: 179
Joined: Mon Apr 16, 2018 9:14 am

Post by MaximLiadov »

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.
User avatar
Ross
Verified
XCore Legend
Posts: 1163
Joined: Thu Dec 10, 2009 9:20 pm
Location: Bristol, UK

Post by Ross »

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
sparkJulio
Junior Member
Posts: 4
Joined: Mon Oct 21, 2024 3:14 am

Post by sparkJulio »

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.
Please define "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.
MaximLiadov
XCore Addict
Posts: 179
Joined: Mon Apr 16, 2018 9:14 am

Post by MaximLiadov »

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.
User avatar
Ross
Verified
XCore Legend
Posts: 1163
Joined: Thu Dec 10, 2009 9:20 pm
Location: Bristol, UK

Post by Ross »

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)
Technical Director @ XMOS. Opinions expressed are my own