Playback not reporting sample rates on windows

[breadbanana]

I've developed a board using a CS42448.
ADCs are capturing, DACs are rendering. Every feature implemented works as intended, but one.
Right now, while debugging we are not working with ASIO, so it is pure WASAPI for now.

On windows sounds panel i want to set the standard format.
On Recording devices both options, 44100 and 48000 apears as intended.
https://imgur.com/kJkSZqR

but the same does not happens on my playback. The device itself is working, but it always reports as being a 44100Hz device.
https://imgur.com/BkfLxAp
I believe this isnt the desired behaviour.

I would like to know more how this information is populated, so i can debug what might be wrong.

Thanks in advance

[danielp]

I can share some of our experiences with this, but unfortunately no real answers.

Firstly, I assume you are using the Microsoft driver that is included with Windows: I have seen the same thing with that driver, but never with the Thesycon driver. Sometimes I have also seen cases where the sample rate box is greyed-out, so the option cannot be changed at all in that menu.

In terms of how the information is populated, the exact details are hidden inside the driver and operating system, but I have collected USB packet captures of the enumeration process and seen the following on Windows:
1. the host requests the list of supported sample rates
2. the complete list is reported by the device to the host
3. the host successfully sets the current sample rate to each in the supported list, one after another
4. finally the host sets the current sample rate to its default (I think it may cache your settings from previous use, etc.)

In my experience, the inability to change to change the sample rate in this Windows menu doesn't prevent the device being used correctly by other software. We use PortAudio for a lot of streaming and that is able to successfully change the sample rate to something supported which is not in the drop-down list. We don't test much with WASAPI though, so I can't comment on that. If using the Microsoft driver, we test all the supported sample rates by streaming with PortAudio using ASIO4ALL and that works well.

[breadbanana]

Firstly, I assume you are using the Microsoft driver that is included with Windows

That's right. We are using windows standard usbaudio driver as our application is intended to be used with WASAPI Host Api.

In my experience, the inability to change to change the sample rate in this Windows menu doesn't prevent the device being used correctly by other software

I don't know in ASIO. But in WASAPI it may prevent the device from being properly used. Using WASAPI Shared mode for instance, the software may not want to change the device sample rate / bit rate because as it is shared, may affect the execution of other applications that may be using the device, in this case of use is not uncommon to you just set the sampling rate / bit rate on windows sounds and them run your application.
On Exclusive mode i believe this should work BUT as far i know Portaudio looks like to be fundamentally broken in wasapi exclusive 24 bits ( which my board is! ). For some reason it just does not work at all and I believe this might be some packing issue.

Does audio stream from XMOS devices are 24bits 3 bytes packed, or is a 32bits 4 bytes packed?

My issue with Asio4All is a great tool for end users, but not for us manufacturers to rely on. For instance, if you disconnect your device from the USB port Asio4All will gracefully reconfigure itself so it does not break anything. but it may not gracefully reconfigure itself when the device is reconnected. And the user may lose some time trying to figure out why his setup isn't working as intended just because he tripped on a usb cable.

My doubt rn is, this is an issue with my implementation using XMOS framework ( i don't think so ), it is an issue on XMOS implementation of their framework( is this one most probable? ) or is this an issue with windows drivers?
Is this a known bug?

Thanks!

[MaximLiadov]

I would try two options to eliminate the windows driver issue:
https://asio4all.org/about/download-asio4all/
https://www.xmos.com/file/usb-audio-cla ... er-windows
It's free, after all.
To view the full device descriptor, use
https://www.thesycon.de/eng/usb_descriptordumper.shtml

[breadbanana]

yeah installing the TheSysCon driver it works as intended... maybe the xmos implementation is to be compatible with Thesyscon driver not with the standard UAC2.0 windows driver?
i did an test with reaper without the driver and it works as you said. but i can't make it work on portaudio... maybe its time to find another framework

[MaximLiadov]

For your information, the standard Windows driver has also been developed by Thesycon.

You never mentioned which XMOS MCU and sample code version you are using. Is it classified?

In my personal opinion, sample code is just a good starting point, and I am sure you can customize it to fit your scenario.

[breadbanana]

Hello MaxinLiadov!

You never mentioned which XMOS MCU and sample code version you are using. Is it classified?

Sorry for this, I don't think it is classified, but it isnt anything fancy either. I developed a custom board based on the XK-AUDIO-216-MC. It is way simplier as it is basically a usb i2s bridge + hid stuff. No midi, no spdif/adat.
The source code I am using is the app_usb_aud_xk_216_mc framework from the official repository. Just wrote the minimal to work stuff like the CS42448 "driver" 6in 8out, my implementation, and some led feedback. Nothing fancy, to be honest.
Everything works as expected, except the capability to change the sample rate / bit rate on the OS. this may cause some libraries to behave badly ( as my experience with portaudio );

Now about the version of the framework i'm using i'm not sure, is it commented anywhere in the source? it is not the latest version.

For your information, the standard Windows driver has also been developed by Thesycon.

Yeah! I am aware of the thesycon work on the windows usbaudio2 driver.
My doubt is why it works as intended with a 3rd party driver and not with the windows standard driver? if I have a 3rd party driver maybe there is something different in the implementation? i'm aware that the 3rd party driver is packed with features.
But the ability to list device sample rates / bit rates are a basic feature, isnt'?

Is this issue known, or is it something only I am facing? My doubt still remains, it is something with "my" implementation ( my here being xmos framework ), with the xmos framework itself, or with windows standard usbaudio2 driver?

Hope this answers any question that I may have failed to elucidate on previous posts!

[danielp]

I don't believe it's a problem with your code or the XMOS reference design; I suspect the issue is with the usbaudio2 driver - however I haven't checked with a non-XMOS device which uses this driver to see if it is reproducible, so it might not be.

There are a few observations on different systems recorded on this issue: https://github.com/xmos/sw_usb_audio/issues/205

I experimented a bit with the XK-AUDIO-316-MC board using the usbaudio2 driver with WASAPI:
- in the sound menu, the playback device had the sample rate option greyed-out on the default 44100; the recording device had all sample rates available
- changing the recording sample rate to something other than 44100 caused the tab containing the sample rate option on the playback device to disappear; the device doesn't support separate sample rates for playback and record, so I assume this relates to them needing to be the same rate, but I can't set the playback rate, so I couldn't make them match in these menus
- since the device was at 44100 by default, I was able to play and record via PortAudio with WASAPI at this rate
- playing or recording at any other sample rate (without a menu change) gave an invalid sample rate error
- since the recording sample rate was configurable for me, I found that if I change this first to my desired rate I can then record via PortAudio - but was still unable to play at that rate

Is this similar behaviour to what you are seeing?

[MaximLiadov]

Forgive my interruption. I swear the standard Microsoft driver works fine with all my products. I've just tested on W11 23H2, see my screenshot below. So it looks like it's possible to make it work. Personally, I use XMOS XU216 and firmware based on customized sample code sw_usb_audio 6.15.2. But it was buggy. I've done a lot of bug fixes, including the descriptor section, and replaced all the old modules with the modern libraries, including USB. I've also made some fixes that prevented Linux from working properly. So it could also be a sample code problem. The standard driver might get stuck somewhere when being initialized. I like debugging firmware on Linux because the standard UAC driver logs all problems very detailed. That's why I asked you to run tdd.exe just in case. I am trying to share my experience and help. I really love XMOS and the engineers behind it. Their work is a masterpiece. Much respect. Keep up the great work you are doing!

[MaximLiadov]

JFYI, here is a link on how to read logs for Microsoft's USB Audio 2.0 class driver
https://learn.microsoft.com/en-us/archi ... ass-driver