OSX UAC2 Feedback weirdness

[FearLabsAudio]

I am working on a UAC2 audio device with an explicit feedback endpoint. I am using the QUIRK_OS_GUESSING with the alternate feedback format for OSX. It works very reliably on Windows, however on OSX I am noticing the FIFO size oscillating about once every second or so. This is an rp2350 device, full speed.

Does anyone have any inkling on what may be causing this? Thanks in advance!

[HiFiPhile]

Honestly it's a pain to make OS X happy with UAC, apart from feedback format correction and OS guessing.

OS X's feedback rate adjustment is slower than Windows/Linux and somehow has a 2nd order response, so when the feedback variation is too big it becomes unstable.

Is anything change if you use sample rate multiples of 48k (or vice versa) ?

Otherwise rate_const need to be lowered:

tinyusb/src/class/audio/audio_device.c

Line 1989 in 2a3025e

audio->feedback.compute.fifo_count.rate_const[0] = (uint16_t) ((audio->feedback.max_value - nominal) / fifo_lvl_thr);

[FearLabsAudio]

Thanks for the reply! So I mentioned this on another discussion thread regarding board support. I possibly need to report my custom clock setup to tinyusb?

After more testing, a stock pico2 running the stock uac2_playback_fb works perfectly. A stock pico2 running a different clock oscillator (we are running 12.288mhz instead of 12mhz for i2s reasons), has issues.

I'm adding all the correct directives so that the pico-sdk reports the correct clock speed and the PLL is adjusted so the USB peripheral runs at the correct rate (48mhz). For some reason this is messing with the feedback behavior but only on OSX.

[HiFiPhile]

Sorry I don't play with raspberry MCUs so I don't have precise suggestions.

After more testing, a stock pico2 running the stock uac2_playback_fb works perfectly. A stock pico2 running a different clock oscillator (we are running 12.288mhz instead of 12mhz for i2s reasons), has issues.

I assume you are playing with stock example without I2S implemented yet ?

In the example audio sample consumption speed is determined by board_millis() in audio_task(), maybe in your case board_millis() become less accurate depending how CPU clock is configured and resulting a larger feedback variation.

If you clock I2S at 12.288MHz and read sample using I2S clock I hope the feedback will be stable.

[FearLabsAudio]

The first example I showed above is with i2s implemented, and on Windows, everything is working and sounding great with stable FIFO.

I was trying to simplify by going back to stock boards, changing one variable at at time. I'll tweak the example and verify that the board_millis() fake callback is behaving as expected. (EDIT: It was not! Also not the source of the problem)

I just want to verify this: is there anything internal to tinyusb's audio/feedback implementation that relies on a correctly reported clock?

Thanks again for the advice!

[HiFiPhile]

I just want to verify this: is there anything internal to tinyusb's audio/feedback implementation that relies on a correctly reported clock?

No there is no callback for CPU or USB clock. The feedback is updated each time a packet is received from the host, at 1khz for FS or 8kHz for HS.

[FearLabsAudio]

Alright, problem solved.

1.) We noticed that the averaging filter/HPF filter in audiod_fb_fifo_count_update() was possibly causing a phase shift that interacted with the OSX's 2nd order behavior. We started by lowering the number of averages, and eventually removing it completely. This caused the FIFO to stabilize fairly quickly with seemingly no ill effects on either OSX or Windows.

2.) As you suggested, lowering the rate (P-gain) significantly stabilized the behavior on both OSX and Windows. I just shifted it right one bit. Initial testing is showing a much more stable feedback control now.

Here's the modified audiod_fb_fifo_count_update() function I ended up with:

static void audiod_fb_fifo_count_update(audiod_function_t *audio, uint16_t lvl_new) {
  /* Low-pass (averaging) filter */
  //uint32_t lvl = audio->feedback.compute.fifo_count.fifo_lvl_avg;
  //lvl = (uint32_t) (((uint64_t) lvl * 15 + ((uint32_t) lvl_new << 16)) >> 4);
  uint32_t lvl = (uint32_t)(lvl_new << 16);
  audio->feedback.compute.fifo_count.fifo_lvl_avg = lvl;

  uint32_t const ff_lvl = lvl >> 16;
  uint16_t const ff_thr = audio->feedback.compute.fifo_count.fifo_lvl_thr;
  uint16_t const *rate = audio->feedback.compute.fifo_count.rate_const;

  uint32_t feedback;

  if (ff_lvl < ff_thr) {
    feedback = audio->feedback.compute.fifo_count.nom_value + (ff_thr - ff_lvl) * (rate[0]>>1);
  } else {
    feedback = audio->feedback.compute.fifo_count.nom_value - (ff_lvl - ff_thr) * (rate[1]>>1);
  }

  if (feedback > audio->feedback.max_value) feedback = audio->feedback.max_value;
  if (feedback < audio->feedback.min_value) feedback = audio->feedback.min_value;
  audio->feedback.value = feedback;

  // Schedule a transmit with the new value if EP is not busy - this triggers repetitive scheduling of the feedback value
  if (usbd_edpt_claim(audio->rhport, audio->ep_fb)) {
    audiod_fb_send(audio);
  }
}

I can put together a proper PR next week if you'd like and I'm curious of your thoughts. Thanks again for your help on this.