Every High-Speed capable device must be able to enumerate at Full-Speed.
The functionality at different speeds can be different. Sometimes it is
possible to support exactly the same functionality on both High-Speed
and Full-Speed, but sometimes it is not. The problem is particurarly
relevant for UAC2 because it utilizes isochronous endpoints which means
that the available bandwidth is drastically different between High-Speed
and Full-Speed.
Full-Speed isochronous endpoint can support up to 1023 bytes per frame.
Typical 48 kHz 16-bit stereo stream consumes 48 * 2 * 2 = 192 bytes per
frame. Zephyr UAC2 instances with such streams are fine to work both at
Full-Speed and High-Speed.
An example stream that is too much for Full-Speed is the sometimes used
192 kHz 24-bit stereo (whether or not it is useful is out-of-scope here,
because it should be up to application developer) which would require
192 * 3 * 2 = 1152 bytes per frame.
Because the bandwidth required for audio stream depends on three
different parameters (sample rate, bit resolution and number of
channels), the UAC2 implementation should not automatically limit
available parameters to fit bandwidth requirements.
Adding explicit full-speed and high-speed boolean options to zephyr,uac2
compatible seems to be not only the easiest solution to the problem, but
also the most flexible one. Depending on the use case, the application
developer can then decide for example:
* to not support High-Speed at all - by having one zephyr,uac2 instance
with full-speed property
* to not support Full-Speed at all - by having one zephyr,uac2 instance
with high-speed property
* to support limited number of channels at Full-Speed and all channels
at High-Speed - by having one zephyr,uac2 instance with full-speed
property and separate instance with high-speed property
* to have exactly the same functionality at both speeds - by having one
zephyr,uac2 instance with both full-speed and high-speed properties
Signed-off-by: Tomasz Moń <tomasz.mon@nordicsemi.no>
22bde52b37