How to properly trap this request?

[anttikes]

Hi all,

I have a USB 2.0 Audio 2.0 device, implemented with STM32F0 custom board. The current firmware version (if you're interested) is available in https://github.com/anttikes/usb-fm-radio/tree/main/Firmware
It is an STM32 IDE project. Host operating system is Windows 11, and TinyUSB commit is rather recent, I think two, maybe three weeks old.

My device is otherwise working ok but I have a rather peculiar problem. When I enable the audio device from the Sound applet in Windows, I get the SET INTERFACE call to choose the alternative setting 1. Right after that, I get an "unknown type 7f" packet in Wireshark with the "URB transfer type" set to "Unknown (0xff)" directed at the control endpoint 0x00.

TinyUSB probably answers this by stalling the control endpoint and the operating system driver then reports USBD_STATUS_NOT_SUPPORTED.

After this occurs, the operating system then chooses the "muted" interface (alternative 0), obtains the sampling frequency, and then chooses alternative 1 again before starting the streaming. I've come to understand that this is kind of a "soft reset" in response to TinyUSB stalling the unknown request.

What I want to do is trap this "Unknown type 7f" and handle it properly so as to prevent the "soft reset". The reason for wanting this is that I want to start the stream in the firmware (enable I2S and issue a sampling rate command) when I receive the "alternative setting 1", and conversely stop it when "alternative setting 0" arrives. I know I could use a timer in the STM32F0 to solve this but I'd rather handle the request that the host is sending me.

Although not visible in the repository above, I have tried enabling the "vendor" class driver ("CFG_TUD_VENDOR 1") and implementing the "tud_vendor_control_xfer_cb" function but this function is not called in this case. I have looked at the other examples implementing this function but they all have the Microsoft OS 2.0 descriptor and BOS, among other things. I'd rather avoid those, if possible.

Any ideas or pointers on what I should do? Is there some special callback function in TinyUSB that I just don't know about?

[HiFiPhile]

I think you mean AUDIO 2.0 device, UAC1 support it's still pending in #3270.

the operating system then chooses the "muted" interface (alternative 0), obtains the sampling frequency, and then chooses alternative 1 again before starting the streaming.

Although I can't recognized the 0x7f request from poor Wireshark capture, the interface switching sequence is totally normal, there is no "soft reset" thing.

[anttikes]

Here's the Wireshark log file. It consists of me plugging in the device, uninstalling it from Device Manager and then "Scan for hardware changes", and from the Sound applet enable and disable it.

The interesting part is the second "Unknown type 7f" ocurring around 31.53, with URB Function code 0x003d. However, if the "not handling" of this request is not the reason for the several alternative setting 0s and 1s that happen right after, before the actual streaming starts, then my entire question is pretty much moot, and I'll need to utilize a timer here.

Wireshark.pcapng.gz

[HiFiPhile]

Ah so you were using UAC 1.0.

if "enable" means "select alternative setting that provides sound" and "disable" equates to "select alternative setting that doesn't" then a sequence where you first choose the sound-providing one, switch it off to get a frequency reading and then switch is back on is, well, dubious at best. Or is this a case of "that's just how it works"?

Yep that's how it works for UAC2, different from UAC1.

I think you can get ride of the request by setting bcdUSB to 0x0200:

[anttikes]

The capture file contained a few packets from the source "1.1.0" which is the motherboard's Bluetooth chip. Set the display filter to (((usb.src matches "1.2.*") || (usb.dst matches "1.2.*"))) to see only the relevant ones. Sorry for not mentioning this.

My device uses bcdUSB value 0x0200. If this is a UAC2 thing then I'll probably wait for the UAC1 PR to complete, and change my device to use that when possible. I can live with this strangeness in the meantime.

Or could my board be of any use for testing the UAC1 PR, in some way? I know it doesn't account for much but it never hurts to ask.

[HiFiPhile]

After reading the capture more carefully I still not sure what the 0x7f is, looks like a bug of Wireshark rather than a real packet, there is even no setup request data.

There should be no request between set alt=1 and set alt=0

The reason for wanting this is that I want to start the stream in the firmware (enable I2S and issue a sampling rate command) when I receive the "alternative setting 1", and conversely stop it when "alternative setting 0" arrives.

Why the UAC2 interface switching stopped you doing this ?

Or could my board be of any use for testing the UAC1 PR, in some way?

The PR is pretty stable now, the change is also straightforward, you can simply checkout the branch.

[anttikes]

Why the UAC2 interface switching stopped you doing this ?

To enable the stream, I first need to establish the I2S clock & WS signals for the radio chip, wait a specific amount of time for it to stabilize, and then issue another command via I2C to set the sampling rate. When the alternative setting switches occur rapidly back and forth then I have a bit of hard time keeping track of where this process is going, should I react to the "switch off" or "switch on" command, or is my device is still "in-between transitions" and I should ignore the request altogether.

Nothing a proper state management can't fix. It's more about me getting it done, and less about it being "hard".

The PR is pretty stable now, the change is also straightforward, you can simply checkout the branch.

I'll take it for a spin and see if it makes my life easier.

[anttikes]

It took me quite a long while to get this test done but it seems the UAC 1.0 version is working much more logically. There's just one "SET INTERFACE" to start it, and one "SET INTERFACE" to stop it.

Works like a charm.

[anttikes]

One note I made during the migration. The "audio10_feature_unit_control_bitmap_t" seems to be missing a "AUDIO10_FU_CONTROL_BM_NONE" for scenarios where an audio device does not allow individual control for a channel. I'm not sure if this was intentional or not. I can always set that to "0x00", of course.

An example from a two-channel feature unit with my suggestion:

TUD_AUDIO10_DESC_FEATURE_UNIT(
    ENTITY_ID_FEATURE_UNIT,
    ENTITY_ID_INPUT_TERMINAL,
    0x00,
    AUDIO10_FU_CONTROL_BM_MUTE | 
    AUDIO10_FU_CONTROL_BM_VOLUME, 
    AUDIO10_FU_CONTROL_BM_NONE,
    AUDIO10_FU_CONTROL_BM_NONE
),