Hah, well let me know how that goes as it continues to not be a sausage.
I left the teensy on overnight at 8x 96kHz 16bit and no over/under runs and a relatively stable Momentary Frequency hovering around 96001 and...
Quick update, I'm now able to stream 8 channels of 96kHz 16-bit audio with no overruns/underruns and a pretty stable "momentary frequency." Pushed my code to my repository
Sorry I missed your PR from a couple days ago! I'll check it out. FWIW, I was spending time myself with various levels of complexity in trying to fix the feedback overrun/underrun problem, and have ended up with this:...
Is your glitching at 96kHz, or the library-standard 44.1kHz?
While I observe that drift there were no underflows or overflows, so the feedback code works but could maybe be improved to not allow that slow drift (one...
Yes sorry, by "could" i meant that according to the USB specification, the Teensy has the *option* of reacting to explicit sink feedback, but is not currently. Strangely, grepping for uses of "usb_audio_sync_feedback",...
Sorry just to clarify, in your application are you using AudioInputUSB, AudioOutputUSB, or both?
sync_event() is only called for AudioInputUSB, as AudioOutputUSB reports itself as an adaptive endpoint and has no...
Oops, thank you for correcting me there. Sorry, I'm very new to developing with USB. Well, the poll interval of 125µs did seem to work just fine which is good news :). I suppose it makes sense, as the buffers just get...
Sorry for my late reply (I've been focusing on my PCB design this last week)! Thanks for the followup.
I instrumented with a mix of Linux's ALSA debugging info and Serial4 output on the Teensy (using the debug printf...
edit: some corrections.
I misunderstood (apologies), and the Audio Input is indeed giving feedback to the host, and you can look at ALSA's current frequency based on the feedback from the device, for example:
...