JohnSwenson wrote: > > BUT for some reason (presumably cost) the makers of these highly > integrated processors (which include the USB hardware in the processor > chip) have left out the hardware TT, thus the driver has to take on the > responsibility of the TT functionality. The default driver that comes > with linux for these devices seems to be able to handle the TT functions > well as long as packets are going unidirectionaly. But Async USB > interleaves packets going back to the host in the middle of the rapid > stream of packets going to the DAC, the software TT can't seem to handle > this. Triode figured out how to hack the driver so it could at least > handle this situation, but the processor is not fast enough to handle > this interleaving at sample rates faster than 48KHz. >
To add to this. On a "normal" PC USB is implemented in a separate interface chipset from the processor and there are potentially two processing blocks one for low/full speed and one for high speed usb which are selected based on the device plugged in. Low speed usb segments data into frames which are scheduled onto the wire inside 1ms frames. High speed retains these 1ms frames but adds multiple microframes within each 1ms frame. Transaction translators (TT) are normally only needed in this case when you plug a low speed device into a hub which is then connected to the host at high speed. In this case the TT does the translation between low and high speed frame and the host computer uses schedules traffic onto the link knowing the device is a low speed device connected via a transaction translator. Now the Touch and many ARM system on a chip implementation keep cost down by implementing USB on the same chip as the processor, but the commonly used usb processing block implements a cut down transaction translator. This has some corners cut which for most use cases don't cause a problem, but for async usb they do. Specifically it can't do an inbound and outbound conversion for isochronous transfers in the same 1ms frame. As usb audio normally requires 1 outbound frame every 1ms frame, this means the inbound frames which are the feedback data for async usb to work get lost. Adding a hub fixes this as it adds a fully featured transaction translator and bypasses the internal one in the processor system on a chip. The upto 48k work around is a hack I did to the usb device drivers which only send outbound data every other 1ms frame so that there are spaces left for the return traffic. This haves the available data rate and hence limits the bandwidth. Its worth noting that this is a problem which is common to many arm system on a chip processors - the Wandboard (as used by the community squeeze project), Cubox, pogoplug all suffer from the same problem - they work fine with a hub, but async audio doesn't work with the onboard usb transaction translator. I believe this is because the all use the same on chip usb implementation which is one of the the most commonly available arm usb implementation. [other arm usb implementations such as that on the Pi cut even more corners and are much worse for usb audio] ------------------------------------------------------------------------ Triode's Profile: http://forums.slimdevices.com/member.php?userid=17 View this thread: http://forums.slimdevices.com/showthread.php?t=94512 _______________________________________________ Touch mailing list Touch@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/touch
