UAC2: Implement feedback by fifo counting.

[HiFiPhile]

Describe the PR

• Implement feedback by fifo counting
• Implement host OS guessing to resolve compatibility issues

Compared to other methods the only thing needed is add a callback to set sample rate, all calculations are done inside the class.

void tud_audio_feedback_params_cb(uint8_t func_id, uint8_t alt_itf, audio_feedback_params_t* feedback_param)
{
  // Set feedback methode to fifo counting
  feedback_param->method = AUDIO_FEEDBACK_METHOD_FIFO_COUNT;
  feedback_param->sample_freq = current_sample_rate;
}

A new example uac2_speaker_fb has been added to show how the mechanism work with a stereo speaker. Both FS (STM32F429) and HS (LPC55S69) configs are tested and FIFO level is well maintained half filled.

---

A HID debug interface can be enabled by setting CFG_AUDIO_DEBUG=1 which export UAC class information and can be read by audio_debug.py.

[HiFiPhile]

Test welcomed @Protoxy22 @Lurcy38 @kf6gpe @PanRe

[Protoxy22]

Wow great work, I will have time to test this next week on an STM32H743 Eval Board with USB HS

Thank you

[Hal9000Space]

This is interesting. I'm curious where can I find audio_debug.py. Any ideas? Thanks a lot!

[HiFiPhile]

This is interesting. I'm curious where can I find audio_debug.py. Any ideas? Thanks a lot!

Just in the PR examples/device/uac2_speaker_fb/src/audio_debug.py

[Hal9000Space]

This is interesting. I'm curious where can I find audio_debug.py. Any ideas? Thanks a lot!

Just in the PR examples/device/uac2_speaker_fb/src/audio_debug.py

Ah, so not in main yet. Ok, thanks!

[Lurcy38]

great :) , I will be very happy to test this implementation in my app, but i cannot reach the branch rx_fb , how to do ?

[HiFiPhile]

@Lurcy38 it's under my user space
https://github.com/HiFiPhile/tinyusb/tree/rx_fb
Or you can download PR by adding .patch
https://github.com/hathach/tinyusb/pull/2328.patch

[HiFiPhile]

@hathach After more tests this PR is ready.

[mastupristi]

Hi, what is the status of this PR? what is missing for it to be approved?

[Marcus2060]

Hi, great work,
very nice feedback method improvement on Tinyusb class Audio !
I Have implemented the feedback method FIFO_COUNTER (stereo 16 bit, 48KHz) on a my RP2040 hardware with I2S DAC with success .. but ...
I observe a good audio USB reproduction on Windows but the system crashes on MAC computer...???
If, instead, I remove only the feedback EP, the system It's starting to work on MAC too ! But obviously not sync ...

Could this be due to the fact that macOS does not accept this feedback method or some other reason such as incorrect descriptors for the MAC?

Thanks!

[HiFiPhile]

Back from holiday...

I would add TUSB_ISO_EP_ATT_EXPLICIT_FB on the data endpoints, just to be sure that all OS are suggested to use the available feedback endpoint @HiFiPhile ?

No it's not how it works...

[HiFiPhile]

I observe a good audio USB reproduction on Windows but the system crashes on MAC computer...???

@Marcus2060 What do you mean crash, does the kernel panic or having popping sound or something else ?

You can try to change

tinyusb/src/class/audio/audio_device.h

Line 196 in 2720392

#define CFG_TUD_AUDIO_ENABLE_FEEDBACK_FORMAT_CORRECTION 0 // 0 or 1

the choice of format is left to the caller and feedback argument is sent as-is. If CFG_TUD_AUDIO_ENABLE_FEEDBACK_FORMAT_CORRECTION is set, then tinyusb
expects 16.16 format and handles the conversion to 10.14 on FS.
Note that due to a bug in its USB Audio 2.0 driver, Windows currently requires 16.16 format for _all_ USB 2.0 devices. 

From other people's experience it seems this format incompatibility issue exist.

On a FS interface, is there a good way to switch between the feedback formats for explicit feedback?

Windows expects 16.16. I get that. It looks very much like macOS and related Apple products adhere closer to the USB spec, and want 14.10 for the clock feedback.

I see there are 3 solutions:

• Identify host OS on enumeration and change format correction on the fly : TODO, could be tricky to implement
• Change the MCU and use high-speed
• Ask Microsoft to fix their code

[Marcus2060]

Hi,
I continued working with a Full-Speed USB audio system RP2040 48KHz 16 bit by using feedback explicit endpoint.
(TinyUSB with FIFO counter feedback mechanism).

I've done other experiments and I get the impression that the usbd_edpt_xfer() function on low-level stack doesn't work well when we try to send 3 bytes.
These are my two scenarios:

MAC:

1. The system works fine with 10.14 feedback (CFG_TUD_AUDIO_ENABLE_FEEDBACK_FORMAT_CORRECTION=1) but only if I set MaxPacketBytes=3 in the feedback descriptor.
2. The system doesn't work if I try to send 3 Bytes (10.14) via usbd_edpt_xfer() but with MaxPacketBytes=4 ??? (MaxPacketBytes means Max number of bytes transfer on the endpoint ??...)
3. The system doesn't work with 16.16 feedback (4 bytes sent) because seems that macOS does not accept 16.16 for full speed devices.

Windows:

1. The system works well with 16.16 feedback (4 bytes sent).
2. The system doesn't work with 10.14 format (CFG_TUD_AUDIO_ENABLE_FEEDBACK_FORMAT_CORRECTION=1) when I try to send 3 bytes by usbd_edpt_xfer() (MaxPacketBytes = 4 in the descriptor) ... I listen some click audio due, as we know, with more or less bytes on Audio buffer respect to the DAC buffer...
3. If I use, instead, the same code of MAC (as above MaxPacketBytes = 3 in the descriptor) unfortunately the system stops working because the Audio class it is not enumerate on WIndows and I no longer see the card ... ???

Also:
I tested the pico-playground usb_sound_card project (Pico board + DAC board) and it works well both Windows and MAC. If we see the code (usb_sound_card.c) seems that feedback routine uses 10.14 format putted in 3 bytes.

So, could the problem be on the low level of the Tinyusb stack when we try to send 3 bytes feedback via usbd_edpt_xfer() to Host ???

Thanks!

[HiFiPhile]

So, could the problem be on the low level of the Tinyusb stack when we try to send 3 bytes feedback via usbd_edpt_xfer() to Host ???

No it can't be, you also tested 3 bytes works on MAC.

If I use, instead, the same code of MAC (as above MaxPacketBytes = 3 in the descriptor) unfortunately the system stops working because the Audio class it is not enumerate on WIndows and I no longer see the card ... ???

It's true.

I tested the pico-playground usb_sound_card project (Pico board + DAC board) and it works well both Windows and MAC. If we see the code (usb_sound_card.c) seems that feedback routine uses 10.14 format putted in 3 bytes.

Pico use UAC 1.0 while TUSB uses UAC 2.0, you can see their descriptors are quite different.

[Marcus2060]

Hi,
thank you for reply and sorry if I try to clarify better:

No it can't be, you also tested 3 bytes works on MAC.

No, my previous comment is precisely because I tested that the 3 bytes don't seem to work (see my pont 1, 2 about MAC):

1. The system works fine with 10.14 feedback (CFG_TUD_AUDIO_ENABLE_FEEDBACK_FORMAT_CORRECTION=1) but only if I set MaxPacketBytes=3 in the feedback descriptor.
2. The system doesn't work if I try to send 3 Bytes (10.14) via usbd_edpt_xfer() but with MaxPacketBytes=4 (MaxPacketBytes means Max number of bytes transfer on the endpoint ??...)

I highlighted the 3 bytes sent problem because:
Point 1 could it be a mechanism where the low-level USB stack forces anyway the 3 bytes ??
Point 2 why doesnt'work while point 1 works ??

Thanks anyway for your attention.

[HiFiPhile]

@Marcus2060

The system doesn't work if I try to send 3 Bytes (10.14) via usbd_edpt_xfer() but with MaxPacketBytes=4 (MaxPacketBytes means Max number of bytes transfer on the endpoint ??...)

Sorry I've some problem understanding, you mean 3 Bytes && MaxPacketBytes=4 doesn't work ? How about 3 Bytes && MaxPacketBytes=3 ?

[Marcus2060]

Sorry I've some problem understanding, you mean 3 Bytes && MaxPacketBytes=4 doesn't work ? How about 3 Bytes && MaxPacketBytes=3 ?

Below 4 different tests on MAC using 10.14 format:

1. When (4 Bytes sent) && (MaxPacketBytes=4) -> Wrong Audio (I think the macOS recognize 16.16).
2. When (3 Bytes sent) && (MaxPacketBytes=4) -> No Sync, some clicks.
3. When (3 Bytes sent) && (MaxPacketBytes=3) -> No Sync, some clicks.
4. When (4 Bytes sent) && (MaxPacketBytes=3) -> Works fine, no click!

Below the function to send feedback (feedback value is an uint32_t) :
usbd_edpt_xfer(audio->rhport, audio->ep_fb, (uint8_t *) &value, 4);

[HiFiPhile]

Last commit optimized debug interface fifo count, it's not the real count inside UAC class but a replication, it was less accurate.

[ra1nb0w]

maybe someone is interested in a rebased version to the latest master
https://github.com/ra1nb0w/tinyusb/tree/rx_fb

[HiFiPhile]

maybe someone is interested in a rebased version to the latest master https://github.com/ra1nb0w/tinyusb/tree/rx_fb

Thank you, will rebase when free, also move #2628 into example.

[HiFiPhile]

@hathach This PR has been tested my multiple users and works well, since @PanRe is not here could you take a look and merge?

[PanRe]

Impressive work! Thank you all for your effort in improving the UAC2 driver!!

[ra1nb0w]

thank you to everyone!

[geekbozu]

Woo love to see this finally get in! Thanks for keeping it going :D

[mstaack]

great! hello proper uac:)

[skuep]

Nice work @HiFiPhile !
Regarding the OS guessing, I have done some work regarding Windows WCID in the past which could theoretically be used for reliably detecting windows (7 and up I Believe) by detecting string Descriptor 0xEE. See
https://github.com/pbatard/libwdi/wiki/WCID-Devices#user-content-Microsoft_OS_String_Descriptor

But I am not sure if the Descriptor is requested before the configuration Descriptor. Because I think it needs to change the maxPackstSize for the feedback endpoint, correct?

Other than that we could force renumeration by disconnecting and connecting the USB device virtually 🤣 EDIT: LOL of course that is patented. Insane. https://patents.google.com/patent/US20120054372A1/en

[HiFiPhile]

But I am not sure if the Descriptor is requested before the configuration Descriptor. Because I think it needs to change the maxPackstSize for the feedback endpoint, correct?

Yes the detection should be done before configuration descriptor request, that's why I put Windows' descriptor as default. I think 0xEE is requested in the same order as MsOS 2.0 descriptor.

Other than that we could force renumeration by disconnecting and connecting the USB device virtually 🤣 EDIT: LOL of course that is patented. Insane. https://patents.google.com/patent/US20120054372A1/en

I think I read it, many patents are just some nonsense...

[skuep]

@HiFiPhile thanks a lot for your effort. I looked through this and was wondering if it's wise to use the BOS Descriptor for the quirk detection because apparently the BOS Descriptor is mandatory only for USB versions > 2.0 if I read correctly.

In addition, device, config and string Descriptor order is already enough to distinguish between MacOS and not-MacOS.

What do you think?

[HiFiPhile]

@HiFiPhile thanks a lot for your effort. I looked through this and was wondering if it's wise to use the BOS Descriptor for the quirk detection because apparently the BOS Descriptor is mandatory only for USB versions > 2.0 if I read correctly.

In addition, device, config and string Descriptor order is already enough to distinguish between MacOS and not-MacOS.

What do you think?

You are right, config and string Descriptor is already enough to distinguish between MacOS and not-MacOS.

It's a full detection method from #2628 which allows each OS to be treated differently. In my testing BCD 2.01 is well supported, normally it shouldn't be an issue.