Open DeflateAwning opened 6 months ago
Done
I missed the note in the README. Here's what I've worked out; let me know if you see any mistakes:
A single stereo sample uses 2x3 = 6 bytes. The estimated latency in seconds is((AUDIO_TOTAL_BUF_SIZE/2) / 6) * (1/sample_freq_hz)
// per stm32_usb/Class/AUDIO/Inc/usbd_audio.h:
USBD_AUDIO_FREQ_MAX = 96000
AUDIO_OUT_PACKET_NUM = 8
AUDIO_TOTAL_BUF_SIZE = ((uint16_t)((USBD_AUDIO_FREQ_MAX / 1000U + 1) * 2U * 3U * AUDIO_OUT_PACKET_NUM))
= (96000 / 1000 + 1) * 2U * 3U * 8)) = 4656
sample_freq_hz = 44100 // not sure if this should be 44100, or 96000
estimated latency in seconds is: = ((AUDIO_TOTAL_BUF_SIZE/2) / 6) * (1/sample_freq_hz)
= ((4656/2) / 6) * (1/44100) = 0.0088 sec = 8.8ms
8.8ms isn't bad; nice!
Can you confirm if sample_freq_hz
in the above example should be 96,000, 44,100, or something else? And also that the rest of the math seems sound?
You didn't miss it, I just appended the note now :-). If you have configured Windows/Ubuntu/Android as per the documentation, the host will always resample the audio playback to 24bits @ 96kHz. So you should use 96kHz for the latency calculation in your comment above, not 44.1kHz.
If not, just look at the LED feedback, and use the actual sample rate being used (44.1, 48 or 96 kHz) for calculating latency. Note that I have no idea about any other sources of latency (USB host drivers etc).
This project appears incredibly impressive!
I'm interested in knowing the overall latency and whether you've conducted any measurements. Adding this information to the README would be valuable for potential builders, especially for applications like games and voice calls that thrive on low latency. Confirming that it's <10ms would provide useful assurance.
When I eventually undertake the build, I'll certainly include this stat in the project documentation, if you haven't done so already