There's two reasons Isochronous endpoints aren't going to work out of the box for audio applications - the common endpoint buffer size, and the lack of double banking.
When I originally made LUFA, I wasn't thinking at all about portability, just overall compiled binary size and RAM usage (given the very limited space in the targeted ICs). That meant I designed the API to be a thin abstraction around the USB controller in the USB AVR8 devices. It's unfortunate that what makes it simple, also makes it a poor candidate to port (e.g. the global endpoint selection, which doesn't gel with RTOSes and the like very well).
The API meant that I had to cut some corners for XMEGA, where the
USB controller expects the endpoint buffers to be user-provided in
regular RAM rather than internal to the controller from its own
DPRAM space. This forced me to pick a common maximum endpoint size
(64 bytes, as you found) for all endpoints, which I felt was a
good choice given it's the maximum size for all endpoint types
other than Isochronous. If you increase the buffer size as you
have done, it will allow you to use larger Isochronous endpoint
sizes at the expense of using more RAM. This will actually work in
a limited fashion as you've already found.
The other issue is the lack of double buffering, which is crucial for isochronous transfers. Unlike all other USB endpoint types, Isochronous endpoints do not re-transmit data if the recipient isn't ready to receive it or if it wasn't received correctly. Any missed traffic is simply dropped, as the sender assumes that the data (in this case audio, but also commonly video) is time critical and anything missed should be discarded permanently as there will be more up-to-date streaming data to take its place. That makes Isochronous transfers useless for anything where data integrity is important, but it's fantastic for streams where a dropped frame or sample or two doesn't really matter.
Because I haven't coded in the double banking, the XMEGA USB controller will discard traffic once it has filled up the single endpoint bank, while you process it and release it back to the stack. On the USB AVR8 devices where double banking is supported, the controller will continue to receive data into a second bank while you're processing the first, so that no data is lost. Without the double banking, you will find that you will miss audio samples which were sent while you're processing the last received endpoint bank.
Cheers!
- Dean
--
You received this message because you are subscribed to the Google Groups "LUFA Library Support List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to lufa-support...@googlegroups.com.
To post to this group, send email to lufa-s...@googlegroups.com.
Visit this group at https://groups.google.com/group/lufa-support.
For more options, visit https://groups.google.com/d/optout.