usb-uac: Audio source device implementation with isochronous endpoints (device to host)

[Humminghead]

The AudioSource type implements a UAC1 (USB Audio Class 1.0) input terminal, allowing the device to stream audio to the host (e.g., microphone, line-in, or radio receiver). It provides a complete set of interfaces and endpoints for isochronous audio streaming with asynchronous feedback.

Key Features:

• Isochronous data endpoint – An IN endpoint for sending audio samples to the host.
• Asynchronous feedback endpoint – An additional IN endpoint (Isochronous, 3‑byte payload padded to 4) for reporting the actual sample rate in 10.14 fixed‑point format, enabling host‑side clock synchronization.
• Multiple sample rates – Accepts a static slice of supported sample rates (e.g., [16000, 24000, 44100]). The host can switch between them via class‑specific requests.
• Configurable sample width
• Configurable terminal type – optional TerminalType can be set (e.g., TerminalType::Microphone, TerminalType::RadioReceiver) to describe the audio source.
• Volume and mute controls – Implements master, left, and right channel volume (in 1/256 dB units) and mute via class‑specific requests.
• Sample rate change notification – Uses a global PubSubChannel to broadcast sample rate changes. Tasks can be subscribed via sample_rate_subscriber().
• Automatic interface allocation – Creates a composite Audio Control interface (Interface 0) and an Audio Streaming interface (Interface 1) with two alternate settings (zero‑bandwidth and active).

Additionally, the 'uac_source' example for the STM32F1 MCU was added.

[leftger]

Can you try rebasing from the latest changes from main? I feel bad we got UAC host support before device support. I can try testing this out in a week or two if someone hasn't checked it out by then

[leftger]

@AlexCharlton might have insight into this. He did the host to device side in his PR

[AlexCharlton]

This looks like a pretty reasonable interface to me.

@leftger one correction: There is already preexisting device support for an "output" (from the perspective of the host), advertising itself as a speaker. This PR adds an additional "input" device. There's almost no end of complexity to what combination of functions a UAC device can support, though, but I'd say that it's fair that an all-encompassing interface is outside of the remit of this PR. This input device matches the features supported by the existing output device support, which seems good enough to me.

My one critique is that it seems unwarranted for create_control_function to return the an output terminal descriptor (the same critique actually applies for the speaker device too, in reverse). There is no way for a host to output audio to a device using this interface.

[leftger]

Thank you for the insight @AlexCharlton. I appreciate the clarification. On your critique do you recommend amending this PR to address the shortcoming or do you think it's better to fix it in a subsequent PR?

[AlexCharlton]

Oh, you know what, I think I'm just confused. The output described is a "USB streaming" output, which doesn't count as a "true" output, and indeed is probably the right way to define the interface. It's been months since I've closely worked on UAC, so forgive the confusion.

[leftger]

No problem. Anyways seems like a good PR. I'll look into testing this out in a week's time if no one else has looked into it.