Teensy USB Host Audio?

Kent.Swan

Member
You did a great job with the USB Device Audio streaming port. Thanks!!! I'm using the 2 i2s channels to interconnect audio in a prototype embedded project and thus have an Teensy Audio Library update request.

As background, I have an audio array microphone and speaker which uses the XMOS chip in an unusual manner (which works great BTW). Both the array microphone and its integrated speaker port appear as a conventional USB Audio device to my Windows workstation. I then Virtual Audio Cables to patch the audio streams through to a Teensy 3.6 as a USB Audio Device.

This works but is a pain as it's rather hard to lug around a laptop or workstation as a component of a portable device. I noted that the Teensy has the ability to use it's USB Host breakout to attach USB HID and USB Serial Devices. Very cool.

Given that, what's the chance that you can make magic happen and add the ability to provide USB Host support for a USB Audio device as a streaming port just like all the other audio gadgets. This would totally eliminate the need to cart around a workstation just to connect the microphone array/speaker up to Teensy. It would also be handy for hooking up a Headset/Micrphone as well.
 
So far, USBHost_t36 only supports 3 of the 4 USB transfer types. Someday I'll add isochronous, but it's a *lot* of work since the transfer descriptors are totally different from the other 3.

Without isochronous pipe support, a host driver for audio isn't going to happen.
 
When/if an audio driver gets written, in some glorious future where we have EHCI isochronous pipes, there's also the question of which of the 3 isochronous rate feedback mechanisms to support. If we only support adaptive and a device needs asychronous, then that'll be yet another hurdle.
 
When/if an audio driver gets written, in some glorious future where we have EHCI isochronous pipes, there's also the question of which of the 3 isochronous rate feedback mechanisms to support. If we only support adaptive and a device needs asychronous, then that'll be yet another hurdle.

I thought that standard isochronous form for usb audio was not asynchronous due to the overall timing requirements though I may be remembering wrongly.
 
USB is filled with lots of lingo having very specific meaning, sometimes not so obvious from the choice of English words. For USB audio, please refer to page 19. Here's a direct link to the "USB Device Class Definition for Audio Devices" 1.0 specification (the words to google if this link breaks... which seems to happen as usb.org regularly changes their site)

https://www.usb.org/sites/default/files/audio10.pdf

In section 3.3, there are 3 synchronization types. Page 19 is only a quick overview. They're explained in more detail elsewhere, especially in chapter 5 of the USB 2.0 spec.

The key point is for making an audio device, you get to choose which of these 3 you want your device to use. On the host side, you have to deal with whatever choice the device designer made. Even if you have everything about isochronous pipes supported, implementing these synchronization methods is the difficult part of supporting audio.
 
Thanks for the refresher references. It's been a while. Also shows why implementing the USB device audio was more rational - not easy but far fewer design decisions.

I wonder if there is a decent open source 32 bit EHCI USB Audio Host stack somewhere about that could be used as a reference to kick start such an implementation.
 
Read parts of the usbAudio pdf referenced. I had no clue that the damned thing had gotten even more complicated than I remembered.

In any case I was researching another subject and decided to poke into whether there were any potentially useful code bases with audio pipe support that could be referenced for an audio host implementation on the ARM platform. During that I stumbled over the LUFA project (actually restumbled). While it's Atmel based it does purport to implement pipe oriented Audio host capability. While the basics with streaming pipes seemed to be there, etc the implementations seemed piece-meal (ie specific to an embedded requirement) as opposed to being a integrated into a rationalized host stack.
 
I've been using the STM32 Arm M series processors for a couple of years now. I've finally found a 'modern' USB Host Audio example source with pipe support. The code seems to be well made. I can send it to you (I didn't see a way to attach it to the reply)
 
Please only send me that code if it is MIT license, which is used for the Audio and USBHost_t36 libraries.

A lot of example code published by silicon vendors has a license that only allows use on their chips. The last thing I want to do is violate ST's license terms. I'd rather write everything from scratch than get into a messy license problem.
 
Back
Top