search

xmos / lib_xua

XMOS USB Audio
Other
17 stars 13 forks source link

Runtime check for packet size limit #76

Open larry-xmos opened 5 years ago

larry-xmos commented 5 years ago

A very long time was spent chasing down audio issues on new hardware that in the end was nothing to do with the new hardware. The application specified 8 channels at 48kHz/24bit and audio class 1.0. This exceeds 1,023 bytes per packet, but there is no clear indication of that.

A check in USB buffer or decouple with a runtime assertion would greatly help catch this early. Suggest leaving it disabled by default, similar to an existing one in xmos/lib_mic_array.

xross commented 5 years ago

There is a build time check for HS byte count, it is missing for FS. However, complete checking is not quite as easy as just checking packet counts in one direction, as the full bus throughput needs to be considered.

N.B. some basic knowledge of the USB specifications is assumed when modifying the code.

larry-xmos commented 5 years ago

Thanks. I guess it could check for gross violations, such as the above incident where we ended up with packet size of 1,176 bytes. A good place for a runtime check would be samplerate and format changes in USB buffer. As you eluded to, compile check doesn't take into account combinations of samplerates and formats that actually occur.

xross commented 5 years ago

Are you saying the host was actually sending this invalid packet size? That would be naughty.. (and require RT check)

larry-xmos commented 5 years ago

No, there is clearly a transport layer below an audio layer. The transport layer gets passed one too big a packet and it trims it to 1,023 before passing on for transmission. The result is noisy audio.