6 channel line level audio interface with teensy 4.1?

Hey! Just looking to confirm, from what I'm reading you can stack 2 audio adapter boards to get 4 channels of audio, either in or out, but I'm looking to do 6. Simply put, I have 2 separate goals, which if achievable on one device (asynchronously) would be ideal. 1 is to be able to take 6 analog line input signals and digitize them such that they can be recorded in a DAW, like one would do with an audio interface, via USB. The other is to be able to output at least 5 signals from a daw to live speakers etc, for live music performance.
The existing offerings I find are 1) bulky, 2) expensive, and 3) have things I don't need (like mic pre-amps), so being able to make something small that does this simple task is really what I'm after.
I've already used a teensy 4.1 for a project (which would be integrated with this second teensy for the capturing part if it does what I need), so am familiar with it's functionality, just not with peripherals like the audio board(s). Any help appreciated!
 
This should be possible if you use both I2S ports.

The first I2S port has 5 data pins, so it can do up to 10 channels. 3 of those data pins can be either input or output.

The second I2S port has 2 data pins, so it's always just stereo input and stereo output.

To make this work, I'd imagine you'd use 4 of the 5 data pins on the first I2S to get 4 channels in and 4 channels out. Then use the second I2S port to get 2 more in and 2 more out.

The tricky part is initializing all 3 boards. With Rev D2 we lost the ability to configure the I2S address. You'll probably need a mux chip to route the SDA and SCL signals to the 3 different audio shields.

The other issue you might face the USB audio (so far) supports only bidirectional stereo. A few people have done some initial effort to get more than stereo, but that capability is far from mature. Hardware-wise, it is possible, but the USB software driver side is quite difficult.
 
This should be possible if you use both I2S ports.

The first I2S port has 5 data pins, so it can do up to 10 channels. 3 of those data pins can be either input or output.

The second I2S port has 2 data pins, so it's always just stereo input and stereo output.

To make this work, I'd imagine you'd use 4 of the 5 data pins on the first I2S to get 4 channels in and 4 channels out. Then use the second I2S port to get 2 more in and 2 more out.

The tricky part is initializing all 3 boards. With Rev D2 we lost the ability to configure the I2S address. You'll probably need a mux chip to route the SDA and SCL signals to the 3 different audio shields.

The other issue you might face the USB audio (so far) supports only bidirectional stereo. A few people have done some initial effort to get more than stereo, but that capability is far from mature. Hardware-wise, it is possible, but the USB software driver side is quite difficult.

Ah, ok, I figured there was a bottleneck somewhere. Makes sense that it might be at the driver. Well, considering I'm looking to make something others could potentially use as well, I may as well see if I can take a crack at the driver portion (no experience but tons with audio/daws in general, and I know what I need it to do). So regarding this mux chip, any more details you can give me there? Just pointing me in a direction is fine. Thanks!
 
Well how about that?
Read through just about everything there, which led me down yet another rabbit hole (trying to figure out the required components), found Paul's pcb for use with the CS42448 that was being used in mcginty's project, and upon googling discovered this perplexing device: https://m.aliexpress.us/item/325680...ppclist.product.0&gatewayAdapt=gloPc2usaMsite
It appears this is at least similar to Paul's, and perhaps would save me the hassle of attempting to collect everything and learning how to solder smds, but, is it in fact the same? Hard to tell with 0 documentation and just a set of 10 unlabeled pins on one end.
As to the I2C component, Paul was suggesting I2S, which as I'm reading is different. That said, this other method apparently uses TDM? I suppose I should rephrase my initial question to:
What is the easiest/cheapest/smallest way to get either 6 line inputs to USB or 6 line outputs from USB using a teensy 4.1?
 
Personally I wouldn't buy anything from AliExpress. Did it once, but the boards that turned up didn't work, and zero luck getting a refund.

Paul did do an update to the 6-in 8-out CS42448 board to bump it to 8 inputs. See https://hackaday.io/project/2984-teensy-audio-library/log/187557-updated-cs42448-pcb-for-teensy-4x. Note that he calls it a "test" board, it has minimal signal conditioning on the audio I/O. You might find that there are enough interested people on here to fund a bulk build (by a reputable supplier) to keep the unit cost down. I've not done that myself, choice of supplier might be location-related, and so on.

The easiest route would be 3x audio adaptors and one of the AdaFruit muxes, plus a Teensy. That gives you 6-in 6-out hardware. It's probably as cheap as it gets, depending on how you value your time. Shouldn't be outrageously big, you need to keep the high-speed digital audio wiring as short as you possibly can anyway.

The USB support is more tricky - I'd suggest you try out the code that mcginty and I were working on and see if it works for you. I think he probably bailed because he'd got it working well enough for him, and couldn't be bothered to finish it properly. Though I could be doing him a disservice... Anyway, you don't need much hardware to test that: just use 6 AudioSynthWaveform objects to create output from the Teensy to your DAW; and some sort of basic audio sketch to route 2 channels at a time to the audio adaptor outputs. It should sound pretty much OK, but my recollection is that we got very occasional clicks as the Teensy and USB stream drifted out of sync.

The tricky part is initializing all 3 boards. With Rev D2 we lost the ability to configure the I2S address. You'll probably need a mux chip to route the SDA and SCL signals to the 3 different audio shields..
Paul mis-typed this - he should know better, the terminology is quite confusing enough as it is! He meant I2C address, as I2S doesn't really have addresses. The former is the slow (100kHz) control bus used to set up the SGTL5000; the latter is the digital audio path, which is much faster with a master clock of 11.29MHz. Revision C and D audio adaptors can be configured to use one of two I2C addresses, but the D2 uses a part that doesn't allow this. I'm hopeful that Rev D will become available again once shortages ease, though I'm also hoping for a Rev E with decent power routing to prevent power supply bounce when the SD card is in use.
 
Opps, yes, indeed I meant configure the I2C address.

I'm hopeful that Rev D will become available again once shortages ease, though I'm also hoping for a Rev E with decent power routing to prevent power supply bounce when the SD card is in use.

Rev D (with configurable I2C address) will return within the next couple months. Robin & I have been putting a lot of work into the supply chain side, so hopefully we'll avoid another prolonged period of being out of stock, and avoid needing to make Rev D2 again (which is functionally identical to Rev D except for ability to configure alternate I2C address).

The PCB is already finalized and in production, so this point is far too late to redesign the power delivery. Even if it were to change, I really don't believe we could isolate the STGL5000 from fluctuation on the 3.3V power line... unless a separate 3.3V power were created from the 3.6-5.5V VUSB/VIN power pin. But I really suspect the much larger issue most people face is ground loops. Long-term, I'd like to consider making another more advanced audio shield. Now really isn't a feasible time to do so, but maybe later this year or in early 2024...
 
upon googling discovered this perplexing device: https://m.aliexpress.us/item/3256804...gloPc2usaMsite
It appears this is at least similar to Paul's.

AMh4yn0nnym0u5e is correct, you are taking a risk when buying from those "knockoff" sites. But what is the risk, really? $27? It appears to me that the board is a reference implementation of the chip. The row of pins along the one edge seem to correspond to the datasheet exposing all of the data and clock lines for I2S mode. This means that the chip can send stereo pairs of data to the DSP (Teensy) for each input/output on the CS42448, with many data lines. You will only need to tap into one set of I2S lines, because Paul's implementation uses TDM which shares one I2S bus with up to 16 "slots" of data (in this case only 6/8). It's hard to see in the low-resolution photo where the I2C is connected, but I think maybe it will connect to that "Modular Control" header. It will be 2 pins (SDA and SCL). You might need some pullups on the I2C (depending on if this board has them or not). The I2S will connect to with BCLK, LRCLK, MCLK ( MCLK is optional on some chips), SDOUT, and SDIN. Then you'll power the board with 5v and ground. So it would be 9 wires, between the Teensy and the board.

NOTE: Keep the wires short for I2S.


perhaps would save me the hassle of attempting to collect everything and learning how to solder smds.

I've been lurking on this forum since 2018 with very similar goals and similar needs. I've since learned how to design my own hardware in Kicad, program (very basically), and assemble my own SMD boards. I have poor eyesight so I had to buy a microscope, although I think anyone would need that for these tiny parts. I also tried hot air rework stations but ultimately I wound up building a reflow oven. Assembling something like this is going to far exceed the cost of trying that $27 board.

Part of me does wish that there was an off the shelf component that fit my needs, but I'm also very thankful that there wasn't - because I've learned so much. I'm still chasing that goal now after almost 5 years and numerous attempts to create just the right solution. My first kickstarter didn't work out, but it's probably for the better because I've rethought my project and it's much more advanced.

Long-term, I'd like to consider making another more advanced audio shield. Now really isn't a feasible time to do so, but maybe later this year or in early 2024...

Hopefully I can finish my project and beat you to it. :) I have a prototype on my desk that is slowly but surely coming alive. I hope to launch it with kickstarter once I have a fully working model. It's exciting, because conversations like this indicate to me that there truly is a market for it. ModalModule, don't get too excited because it's still a work in progress but my board is aimed at making multichannel audio easier (and more high-end), exposing all features of the Teensy Audio Library.

take 6 analog line input signals and digitize them such that they can be recorded in a DAW, like one would do with an audio interface, via USB.

How important is the quality of the audio in your recordings?
 
Rev D (with configurable I2C address) will return within the next couple months. Robin & I have been putting a lot of work into the supply chain side, so hopefully we'll avoid another prolonged period of being out of stock, and avoid needing to make Rev D2 again (which is functionally identical to Rev D except for ability to configure alternate I2C address).
Excellent news!

The PCB is already finalized and in production, so this point is far too late to redesign the power delivery. Even if it were to change, I really don't believe we could isolate the STGL5000 from fluctuation on the 3.3V power line... unless a separate 3.3V power were created from the 3.6-5.5V VUSB/VIN power pin. But I really suspect the much larger issue most people face is ground loops.
I'm sure ground loops are significant, but I'm equally sure there's a power routing issue whereby the SD card power is not starred from the source pins, but runs first to the SGTL5000.

Here's a plot with the microphone straight onto the audio adaptor so minimal lead length. The top plot is recorded to the adaptor's SD card slot, and the bottom one to the Teensy 4.1's built-in SD card slot. Same card in both cases, nothing else changed:
2023-05-31 18_12_06-.jpg
Note the spikes every 92ms in the top plot only, corresponding exactly to the write interval of 4k samples. I've seen them much worse, possibly due to use of stacking connectors - that rig is not available right now.

Long-term, I'd like to consider making another more advanced audio shield. Now really isn't a feasible time to do so, but maybe later this year or in early 2024...
Also excellent news! But if you have to re-spin the existing design at some point...

Sorry ModalModule, we've hijacked your thread...
 
Not at all! In fact I'm just glad to see how vibrant this community is! Also, that there's still interest in doing something similar to what I'm attempting to.
@JayShoe I really appreciate the insight on how you think the ali board works. I'm definitely more tempted now, but...
How important is the quality of the audio in your recordings?
Very important... the results would be for an album. Likewise, the outputs would be for live performance (specifically 2 channels of live midi perf, 2 backing tracks, 1 dedicated bass line, with 1 to spare) and the more I was thinking of it last night I realize I'd also want those outputs to be balanced to avoid 6 DI boxes/3 stereo DIs, and that is all conveniently in commercial audio interfaces. The main thing I wanted was something smaller than the usual 8x8 which would be a rack mount. However, if I want clarity, and balance, and driver support, I may be fooling myself just a bit. Someone feel free to tell me otherwise! Haha
Regardless I *do* think if there was something that ticked all those boxes while still being in a relatively small form factor, and was less expensive for not having pre-amps etc, I may not be the *only* one in the world that'd want it? I know plenty of people who use recording audio interfaces live simply because they're the only readily available way to get multiple outs from a computer cleanly. Anyway, really just throwing it out there to see what can come of it.
Back to the inputs, as I said these *could* be separate devices, I was just trying to catch all my eggs with one basket so to say. So at least if there was a way to capture 6 inputs (3 stereo) cleanly and if that was easier than the 6 balanced outputs need, I think I'd still be willing to build something, as this is something I'm eager to get started with, and I've been limping along with a live solution (for outputs) well enough for now.
 
Sounds like you’d have to put some effort into the analogue side, then. As much fun as it’d be to build your own, you might find something like a Focusrite Scarlett 8i6 would tick the boxes, and give you 24/192k quality instead of 16/44k.

One thought on recording … it is feasible to stream straight to an SD card, so you could eliminate the USB part of the equation there.
 
Woops, tried to edit my post and it got nuked.
I would actually also need to monitor the source through this device as well, so vaguely possible would be sd card capture but a mix with the 6 channels into 2 outputs to monitors, but then of course I'd need to be able to mix them which adds yet more complications.
And the problem with the 8i6 is it actually only has 4 analog outputs, the other 2 are spdif, and I don't want to deal with *more* converting through another device. I do wish it was all analog.
 
Ah, hadn’t twigged that the Focusrite spec was misleading…

Easy enough to get the Teensy to mix 6 inputs (and the outputs too, if you want) to a stereo monitor mix. All the bits you need are in the audio library, apart from compression or limiting. I think those might be in the F32 float audio library, if needed. Of course, that might mean even more audio I/O required! An 8x8 TDM interface on I2S2 and something on I2S1 would do it :D
 
Hmm, and that said going to studio monitors I'd still want a balanced signal if possible. Anyone know anything about that?
But ya, I just meant such that the 3 left channels aren't summing into 1 and distorting, likewise for right, and perhaps being able to turn them up and down from each other to test balancing. So are you saying that straight to SD would be better somehow? Someone mentioned USB being less efficient for data transfer?
 
There seem to be differential amp modules available based on the OPA1632 which might be useful. Not sure, never used them…

I was just thinking that if the USB recording quality isn’t perfect, the SD would be a backup, as it can come straight from the digital inputs.

mcginty and I got up to 8x8 at 96kHz, so throughput shouldn’t be a problem, apart from the pesky sync issue which seemed to drop the occasional sample. There’s code in there to ensure sync, but it doesn’t seem to work for me (on Windows 10). mcginty was using Linux, and seemed happy enough when he vanished! Also, I only got it working with illegal descriptor values (>1024 byte packets, 1 frame/ms), where it should have been smaller packets more often.
 
Well first off, it'd only need to be 44.1 realistically (maybe 48), the source itself is not super high quality, I just want to capture it authentically if possible. Same for the outputs for live.
I am also on windows, but am fine with hacking things to work right. Luckily the material isn't having to sync to anything in the daw, it would just be used on its own.
But ya, with the McGinty setup, I'd need to get/make one of Paul's CS42448 boards right? Still trying to fast pass that portion...
 
As Paul said in post #2, there are 7 total I2S data pins, of which 2 must be input and 2 output. Each pin is 2 channels. An audio adaptor has 1 each input and output (2 channel) pin. So 3 adaptors would give you 6x6, and you could add one more (half-used) to give 8x6 or 6x8.

So, no need for special hardware, at least to start with. You might choose to go for it later for convenience, channel count or reliability reasons - fewer parts are likely to be more reliable and smaller.

You’d also need the I2C mux, unless you can find at least one rev D audio adaptor. You might as well use it anyway, as putting an adaptor on the other Wire port means a non-standard audio library to control it. Which I have implemented, if needed.

In your shoes, I’d get a Teensy 4.1, a couple of audio adaptors, a mux, and a decent micro SD, and have a play. If you’re shopping anyway, get a PSRAM or two. 8MB/16 MB extra RAM is quite useful on occasion.
 
Ok, this is great info, and I really appreciate it! Now Paul had also mentioned that the driver side of things was not yet ready to handle all that, but is that in fact true? The work you and McGinty did, did it include audio drivers for applications like a DAW?
 
Well, it was intended to expand the capability of the existing USB audio from 2x2 to up to 8x8, and other sample rates. As far as I know it’s all standard USB descriptors and behaviour, so should work with any DAW software on a PC. Windows drivers seem to operate just fine, nothing special needed, the Teensy just appears as an audio device with the expected number of channels.

Actually, there is one minor wrinkle. If the USB VID/PID values aren’t changed, Windows assumes the channel count must be the same. So you may have to uninstall the old device before the Teensy shows the correct channel count.
 
In my opinion getting 8 channels USB it's one thing but getting it without any glitches it's another.

My biggest issue is I am getting a bit of a glitching sound on USB (WIN10) regardless if I use the standard 2 Channel USB audio library or my own modified 8 channel USB audio library based on the work on some of the people mentioned here.

TEENSY 8ch USB.png

I'm using Thesycon USB Descriptor Dumper and here is the current output:
Code:
Information for device Teensy Audio (VID=0x16C0 PID=0x04D2):

------------------------------
Connection Information:
------------------------------
Device current bus speed: HighSpeed
Device supports USB 1.1 specification
Device supports USB 2.0 specification
Device address: 0x0038
Current configuration value: 0x01
Number of open pipes: 2


------------------------------
Device Descriptor:
------------------------------
0x12	bLength
0x01	bDescriptorType
0x0200	bcdUSB
0x00	bDeviceClass      
0x00	bDeviceSubClass   
0x00	bDeviceProtocol   
0x40	bMaxPacketSize0   (64 bytes)
0x16C0	idVendor
0x04D2	idProduct
0x0280	bcdDevice
0x01	iManufacturer
0x02	iProduct     
0x03	iSerialNumber
0x01	bNumConfigurations

Device Qualifier Descriptor:
------------------------------
0x0A	bLength
0x06	bDescriptorType
0x0200	bcdUSB
0x00	bDeviceClass      
0x00	bDeviceSubClass   
0x00	bDeviceProtocol   
0x40	bMaxPacketSize0   (64 bytes)
0x01	bNumConfigurations 
0x00	bReserved 


-------------------------
Configuration Descriptor:
-------------------------
0x09	bLength
0x02	bDescriptorType
0x00EF	wTotalLength   (239 bytes)
0x04	bNumInterfaces
0x01	bConfigurationValue
0x00	iConfiguration
0x80	bmAttributes   (Bus-powered Device)
0x7D	bMaxPower      (250 mA)

Interface Descriptor:
------------------------------
0x09	bLength
0x04	bDescriptorType
0x00	bInterfaceNumber
0x00	bAlternateSetting
0x02	bNumEndPoints
0x03	bInterfaceClass      (Human Interface Device Class)
0x00	bInterfaceSubClass   
0x00	bInterfaceProtocol   
0x00	iInterface

HID Descriptor:
------------------------------
0x09	bLength
0x21	bDescriptorType
0x0111	bcdHID
0x00	bCountryCode
0x01	bNumDescriptors
0x22	bDescriptorType   (Report descriptor)
0x0021	bDescriptorLength

Endpoint Descriptor:
------------------------------
0x07	bLength
0x05	bDescriptorType
0x82	bEndpointAddress  (IN endpoint 2)
0x03	bmAttributes      (Transfer: Interrupt / Synch: None / Usage: Data)
0x0040	wMaxPacketSize    (1 x 64 bytes)
0x01	bInterval         (1 microframes)

Endpoint Descriptor:
------------------------------
0x07	bLength
0x05	bDescriptorType
0x02	bEndpointAddress  (OUT endpoint 2)
0x03	bmAttributes      (Transfer: Interrupt / Synch: None / Usage: Data)
0x0020	wMaxPacketSize    (1 x 32 bytes)
0x02	bInterval         (2 microframes)

Interface Association Descriptor:
------------------------------
0x08	bLength
0x0B	bDescriptorType
0x01	bFirstInterface
0x03	bInterfaceCount
0x01	bFunctionClass      (Audio Device Class)
0x01	bFunctionSubClass   (Audio Control Interface)
0x00	bFunctionProtocol   (Audio Protocol undefined)
0x00	iFunction

Interface Descriptor:
------------------------------
0x09	bLength
0x04	bDescriptorType
0x01	bInterfaceNumber
0x00	bAlternateSetting
0x00	bNumEndPoints
0x01	bInterfaceClass      (Audio Device Class)
0x01	bInterfaceSubClass   (Audio Control Interface)
0x00	bInterfaceProtocol   (Audio Protocol undefined)
0x00	iInterface

AC Interface Header Descriptor:
------------------------------
0x0A	bLength
0x24	bDescriptorType
0x01	bDescriptorSubtype
0x0100	bcdADC
0x0044	wTotalLength   (68 bytes)
0x02	bInCollection
0x02	baInterfaceNr(1)
0x03	baInterfaceNr(2)

AC Input Terminal Descriptor:
------------------------------
0x0C	bLength
0x24	bDescriptorType
0x02	bDescriptorSubtype
0x01	bTerminalID
0x0602	wTerminalType   (Digital audio interface)
0x00	bAssocTerminal
0x08	bNrChannels   (8 channels)
0x01FF	wChannelConfig
0x00	iChannelNames
0x00	iTerminal

AC Output Terminal Descriptor:
------------------------------
0x09	bLength
0x24	bDescriptorType
0x03	bDescriptorSubtype
0x02	bTerminalID
0x0101	wTerminalType   (USB Streaming)
0x00	bAssocTerminal
0x01	bSourceID
0x00	iTerminal

AC Input Terminal Descriptor:
------------------------------
0x0C	bLength
0x24	bDescriptorType
0x02	bDescriptorSubtype
0x03	bTerminalID
0x0101	wTerminalType   (USB Streaming)
0x00	bAssocTerminal
0x08	bNrChannels   (8 channels)
0x0003	wChannelConfig
0x00	iChannelNames
0x00	iTerminal

AC Feature Unit Descriptor:
------------------------------
0x10	bLength
0x24	bDescriptorType
0x06	bDescriptorSubtype
0x31	bUnitID
0x03	bSourceID
0x01	bControlSize
bmaControls: 
 0x01	Channel(0) - Mute
 0x03	Channel(1) - Mute / Volume
 0x03	Channel(2) - Mute / Volume
 0x03	Channel(3) - Mute / Volume
 0x03	Channel(4) - Mute / Volume
 0x03	Channel(5) - Mute / Volume
 0x03	Channel(6) - Mute / Volume
 0x03	Channel(7) - Mute / Volume
 0x03	Channel(8) - Mute / Volume
0x00	iFeature


AC Output Terminal Descriptor:
------------------------------
0x09	bLength
0x24	bDescriptorType
0x03	bDescriptorSubtype
0x04	bTerminalID
0x0602	wTerminalType   (Digital audio interface)
0x00	bAssocTerminal
0x31	bSourceID
0x00	iTerminal

Interface Descriptor:
------------------------------
0x09	bLength
0x04	bDescriptorType
0x02	bInterfaceNumber
0x00	bAlternateSetting
0x00	bNumEndPoints
0x01	bInterfaceClass      (Audio Device Class)
0x02	bInterfaceSubClass   (Audio Streaming Interface)
0x00	bInterfaceProtocol   (Audio Protocol undefined)
0x00	iInterface

Interface Descriptor:
------------------------------
0x09	bLength
0x04	bDescriptorType
0x02	bInterfaceNumber
0x01	bAlternateSetting
0x01	bNumEndPoints
0x01	bInterfaceClass      (Audio Device Class)
0x02	bInterfaceSubClass   (Audio Streaming Interface)
0x00	bInterfaceProtocol   (Audio Protocol undefined)
0x00	iInterface

AS Interface Descriptor:
------------------------------
0x07	bLength
0x24	bDescriptorType
0x01	bDescriptorSubtype
0x02	bTerminalLink
0x03	bDelay
0x0001	wFormatTag   (PCM)

AS Format Type 1 Descriptor:
------------------------------
0x0B	bLength
0x24	bDescriptorType
0x02	bDescriptorSubtype
0x01	bFormatType   (FORMAT_TYPE_1)
0x08	bNrChannels   (8 channels)
0x02	bSubframeSize
0x10	bBitResolution   (16 bits per sample)
0x01	bSamFreqType   (Discrete sampling frequencies)
0x00AC44 	tSamFreq(1)   (44100 Hz)

Endpoint Descriptor (Audio/MIDI 1.0):
------------------------------
0x09	bLength
0x05	bDescriptorType
0x83	bEndpointAddress  (IN endpoint 3)
0x09	bmAttributes      (Transfer: Isochronous / Synch: Adaptive / Usage: Data)
0x02D0	wMaxPacketSize    (1 x 720 bytes)
0x04	bInterval         (8 microframes)
0x00	bRefresh
0x00	bSynchAddress

AS Isochronous Data Endpoint Descriptor:
------------------------------
0x07	bLength
0x25	bDescriptorType
0x01	bDescriptorSubtype
0x00	bmAttributes
0x00	bLockDelayUnits   (undefined)
0x0000	wLockDelay

Interface Descriptor:
------------------------------
0x09	bLength
0x04	bDescriptorType
0x03	bInterfaceNumber
0x00	bAlternateSetting
0x00	bNumEndPoints
0x01	bInterfaceClass      (Audio Device Class)
0x02	bInterfaceSubClass   (Audio Streaming Interface)
0x00	bInterfaceProtocol   (Audio Protocol undefined)
0x00	iInterface

Interface Descriptor:
------------------------------
0x09	bLength
0x04	bDescriptorType
0x03	bInterfaceNumber
0x01	bAlternateSetting
0x02	bNumEndPoints
0x01	bInterfaceClass      (Audio Device Class)
0x02	bInterfaceSubClass   (Audio Streaming Interface)
0x00	bInterfaceProtocol   (Audio Protocol undefined)
0x00	iInterface

AS Interface Descriptor:
------------------------------
0x07	bLength
0x24	bDescriptorType
0x01	bDescriptorSubtype
0x03	bTerminalLink
0x03	bDelay
0x0001	wFormatTag   (PCM)

AS Format Type 1 Descriptor:
------------------------------
0x0B	bLength
0x24	bDescriptorType
0x02	bDescriptorSubtype
0x01	bFormatType   (FORMAT_TYPE_1)
0x08	bNrChannels   (8 channels)
0x02	bSubframeSize
0x10	bBitResolution   (16 bits per sample)
0x01	bSamFreqType   (Discrete sampling frequencies)
0x00AC44 	tSamFreq(1)   (44100 Hz)

Endpoint Descriptor (Audio/MIDI 1.0):
------------------------------
0x09	bLength
0x05	bDescriptorType
0x03	bEndpointAddress  (OUT endpoint 3)
0x05	bmAttributes      (Transfer: Isochronous / Synch: Asynchronous / Usage: Data)
0x02D0	wMaxPacketSize    (1 x 720 bytes)
0x04	bInterval         (8 microframes)
0x00	bRefresh
0x84	bSynchAddress

AS Isochronous Data Endpoint Descriptor:
------------------------------
0x07	bLength
0x25	bDescriptorType
0x01	bDescriptorSubtype
0x00	bmAttributes
0x00	bLockDelayUnits   (undefined)
0x0000	wLockDelay

Endpoint Descriptor (Audio/MIDI 1.0):
------------------------------
0x09	bLength
0x05	bDescriptorType
0x84	bEndpointAddress  (IN endpoint 4)
0x11	bmAttributes      (Transfer: Isochronous / Synch: None / Usage: Feedback)
0x0004	wMaxPacketSize    (1 x 4 bytes)
0x04	bInterval         (8 microframes)
0x07	bRefresh
0x00	bSynchAddress


-------------------------------------
Other Speed Configuration Descriptor:
-------------------------------------
0x09	bLength
0x07	bDescriptorType
0x00EF	wTotalLength   (239 bytes)
0x04	bNumInterfaces
0x01	bConfigurationValue
0x00	iConfiguration
0x80	bmAttributes   (Bus-powered Device)
0x7D	bMaxPower      (250 mA)

Interface Descriptor:
------------------------------
0x09	bLength
0x04	bDescriptorType
0x00	bInterfaceNumber
0x00	bAlternateSetting
0x02	bNumEndPoints
0x03	bInterfaceClass      (Human Interface Device Class)
0x00	bInterfaceSubClass   
0x00	bInterfaceProtocol   
0x00	iInterface

HID Descriptor:
------------------------------
0x09	bLength
0x21	bDescriptorType
0x0111	bcdHID
0x00	bCountryCode
0x01	bNumDescriptors
0x22	bDescriptorType   (Report descriptor)
0x0021	bDescriptorLength

Endpoint Descriptor:
------------------------------
0x07	bLength
0x05	bDescriptorType
0x82	bEndpointAddress  (IN endpoint 2)
0x03	bmAttributes      (Transfer: Interrupt / Synch: None / Usage: Data)
0x0040	wMaxPacketSize    (1 x 64 bytes)
0x01	bInterval         (1 frames)

Endpoint Descriptor:
------------------------------
0x07	bLength
0x05	bDescriptorType
0x02	bEndpointAddress  (OUT endpoint 2)
0x03	bmAttributes      (Transfer: Interrupt / Synch: None / Usage: Data)
0x0020	wMaxPacketSize    (1 x 32 bytes)
0x02	bInterval         (2 frames)

Interface Association Descriptor:
------------------------------
0x08	bLength
0x0B	bDescriptorType
0x01	bFirstInterface
0x03	bInterfaceCount
0x01	bFunctionClass      (Audio Device Class)
0x01	bFunctionSubClass   (Audio Control Interface)
0x00	bFunctionProtocol   (Audio Protocol undefined)
0x00	iFunction

Interface Descriptor:
------------------------------
0x09	bLength
0x04	bDescriptorType
0x01	bInterfaceNumber
0x00	bAlternateSetting
0x00	bNumEndPoints
0x01	bInterfaceClass      (Audio Device Class)
0x01	bInterfaceSubClass   (Audio Control Interface)
0x00	bInterfaceProtocol   (Audio Protocol undefined)
0x00	iInterface

AC Interface Header Descriptor:
------------------------------
0x0A	bLength
0x24	bDescriptorType
0x01	bDescriptorSubtype
0x0100	bcdADC
0x0044	wTotalLength   (68 bytes)
0x02	bInCollection
0x02	baInterfaceNr(1)
0x03	baInterfaceNr(2)

AC Input Terminal Descriptor:
------------------------------
0x0C	bLength
0x24	bDescriptorType
0x02	bDescriptorSubtype
0x01	bTerminalID
0x0602	wTerminalType   (Digital audio interface)
0x00	bAssocTerminal
0x08	bNrChannels   (8 channels)
0x0003	wChannelConfig
0x00	iChannelNames
0x00	iTerminal

AC Output Terminal Descriptor:
------------------------------
0x09	bLength
0x24	bDescriptorType
0x03	bDescriptorSubtype
0x02	bTerminalID
0x0101	wTerminalType   (USB Streaming)
0x00	bAssocTerminal
0x01	bSourceID
0x00	iTerminal

AC Input Terminal Descriptor:
------------------------------
0x0C	bLength
0x24	bDescriptorType
0x02	bDescriptorSubtype
0x03	bTerminalID
0x0101	wTerminalType   (USB Streaming)
0x00	bAssocTerminal
0x08	bNrChannels   (8 channels)
0x0003	wChannelConfig
0x00	iChannelNames
0x00	iTerminal

AC Feature Unit Descriptor:
------------------------------
0x10	bLength
0x24	bDescriptorType
0x06	bDescriptorSubtype
0x31	bUnitID
0x03	bSourceID
0x01	bControlSize
bmaControls: 
 0x01	Channel(0) - Mute
 0x03	Channel(1) - Mute / Volume
 0x03	Channel(2) - Mute / Volume
 0x03	Channel(3) - Mute / Volume
 0x03	Channel(4) - Mute / Volume
 0x03	Channel(5) - Mute / Volume
 0x03	Channel(6) - Mute / Volume
 0x03	Channel(7) - Mute / Volume
 0x03	Channel(8) - Mute / Volume
0x00	iFeature


AC Output Terminal Descriptor:
------------------------------
0x09	bLength
0x24	bDescriptorType
0x03	bDescriptorSubtype
0x04	bTerminalID
0x0602	wTerminalType   (Digital audio interface)
0x00	bAssocTerminal
0x31	bSourceID
0x00	iTerminal

Interface Descriptor:
------------------------------
0x09	bLength
0x04	bDescriptorType
0x02	bInterfaceNumber
0x00	bAlternateSetting
0x00	bNumEndPoints
0x01	bInterfaceClass      (Audio Device Class)
0x02	bInterfaceSubClass   (Audio Streaming Interface)
0x00	bInterfaceProtocol   (Audio Protocol undefined)
0x00	iInterface

Interface Descriptor:
------------------------------
0x09	bLength
0x04	bDescriptorType
0x02	bInterfaceNumber
0x01	bAlternateSetting
0x01	bNumEndPoints
0x01	bInterfaceClass      (Audio Device Class)
0x02	bInterfaceSubClass   (Audio Streaming Interface)
0x00	bInterfaceProtocol   (Audio Protocol undefined)
0x00	iInterface

AS Interface Descriptor:
------------------------------
0x07	bLength
0x24	bDescriptorType
0x01	bDescriptorSubtype
0x02	bTerminalLink
0x03	bDelay
0x0001	wFormatTag   (PCM)

AS Format Type 1 Descriptor:
------------------------------
0x0B	bLength
0x24	bDescriptorType
0x02	bDescriptorSubtype
0x01	bFormatType   (FORMAT_TYPE_1)
0x08	bNrChannels   (8 channels)
0x02	bSubframeSize
0x10	bBitResolution   (16 bits per sample)
0x01	bSamFreqType   (Discrete sampling frequencies)
0x00AC44 	tSamFreq(1)   (44100 Hz)

Endpoint Descriptor (Audio/MIDI 1.0):
------------------------------
0x09	bLength
0x05	bDescriptorType
0x83	bEndpointAddress  (IN endpoint 3)
0x09	bmAttributes      (Transfer: Isochronous / Synch: Adaptive / Usage: Data)
0x02D0	wMaxPacketSize    (1 x 720 bytes)
0x01	bInterval         (1 frames)
0x00	bRefresh
0x00	bSynchAddress

AS Isochronous Data Endpoint Descriptor:
------------------------------
0x07	bLength
0x25	bDescriptorType
0x01	bDescriptorSubtype
0x00	bmAttributes
0x00	bLockDelayUnits   (undefined)
0x0000	wLockDelay

Interface Descriptor:
------------------------------
0x09	bLength
0x04	bDescriptorType
0x03	bInterfaceNumber
0x00	bAlternateSetting
0x00	bNumEndPoints
0x01	bInterfaceClass      (Audio Device Class)
0x02	bInterfaceSubClass   (Audio Streaming Interface)
0x00	bInterfaceProtocol   (Audio Protocol undefined)
0x00	iInterface

Interface Descriptor:
------------------------------
0x09	bLength
0x04	bDescriptorType
0x03	bInterfaceNumber
0x01	bAlternateSetting
0x02	bNumEndPoints
0x01	bInterfaceClass      (Audio Device Class)
0x02	bInterfaceSubClass   (Audio Streaming Interface)
0x00	bInterfaceProtocol   (Audio Protocol undefined)
0x00	iInterface

AS Interface Descriptor:
------------------------------
0x07	bLength
0x24	bDescriptorType
0x01	bDescriptorSubtype
0x03	bTerminalLink
0x03	bDelay
0x0001	wFormatTag   (PCM)

AS Format Type 1 Descriptor:
------------------------------
0x0B	bLength
0x24	bDescriptorType
0x02	bDescriptorSubtype
0x01	bFormatType   (FORMAT_TYPE_1)
0x08	bNrChannels   (8 channels)
0x02	bSubframeSize
0x10	bBitResolution   (16 bits per sample)
0x01	bSamFreqType   (Discrete sampling frequencies)
0x00AC44 	tSamFreq(1)   (44100 Hz)

Endpoint Descriptor (Audio/MIDI 1.0):
------------------------------
0x09	bLength
0x05	bDescriptorType
0x03	bEndpointAddress  (OUT endpoint 3)
0x05	bmAttributes      (Transfer: Isochronous / Synch: Asynchronous / Usage: Data)
0x02D0	wMaxPacketSize    (1 x 720 bytes)
0x01	bInterval         (1 frames)
0x00	bRefresh
0x84	bSynchAddress

AS Isochronous Data Endpoint Descriptor:
------------------------------
0x07	bLength
0x25	bDescriptorType
0x01	bDescriptorSubtype
0x00	bmAttributes
0x00	bLockDelayUnits   (undefined)
0x0000	wLockDelay

Endpoint Descriptor (Audio/MIDI 1.0):
------------------------------
0x09	bLength
0x05	bDescriptorType
0x84	bEndpointAddress  (IN endpoint 4)
0x11	bmAttributes      (Transfer: Isochronous / Synch: None / Usage: Feedback)
0x0003	wMaxPacketSize    (1 x 3 bytes)
0x01	bInterval         (1 frames)
0x05	bRefresh
0x00	bSynchAddress

Microsoft OS Descriptor is not available. Error code: 0x0000001F


--------------------------------
String Descriptor Table
--------------------------------
Index  LANGID  String
0x00   0x0000  
0x01   0x0000  "Teensyduino"
0x02   0x0000  "Teensy Audio"
0x03   0x0000  "7521140"

------------------------------

Connection path for device: 
USB xHCI Compliant Host Controller
Root Hub
Generic USB Hub
Teensy Audio (VID=0x16C0 PID=0x04D2) Port: 4

Running on: Windows 10 or greater (Build Version 19044)

Brought to you by TDD v2.17.0, Feb 23 2021, 14:04:02
 
Well this is more or less why I was asking about drivers, because in my experience with windows there isn't usually a way to decide buffer size unless you have a dedicated driver. One possible solution is asio4all, but even that's a bit touch and go. On that note, I completely forgot you can setup interface arrays through that, so I think before I proceed I'll see if I can chain my 4 channel with my 2 channel, and if so, I may just go with that for this album/project, and worry about this later. Haha
 
To be clear, usually pops/clicks/glitches are just a result of the buffer size being too small, and lengthening it can solve those issues.
 
In my opinion getting 8 channels USB it's one thing but getting it without any glitches it's another.

My biggest issue is I am getting a bit of a glitching sound on USB (WIN10) regardless if I use the standard 2 Channel USB audio library or my own modified 8 channel USB audio library based on the work on some of the people mentioned here.
That sounds much like my observation, though perhaps a little contradictory - you're saying 8 channels makes it worse, then that you get glitches even with 2 channels?! :confused:

But ... it does appeaar that if we can fix the glitches for the standard stereo USB audio, it should also fix it for the higher channel count variants. The descriptors you show look much like what I'd expect; in particular, a max packet size of 720 bytes every 8 microframes (720,000 bytes/s) is easily enough for 8 channels at 44.1k (705,600 bytes/s). I was getting issues making a working and valid descriptor for 96k, but I think that's a separate thing.

To be clear, usually pops/clicks/glitches are just a result of the buffer size being too small, and lengthening it can solve those issues.
Usually, but I believe not in this case. The issue is that the PC and Teensy clocks are not quite the same speed, and although the USB protocol should be able to overcome this, in fact it doesn't as things stand. It's something to do with getting the feedback endpoint working correctly, and ensuring that the audio data endpoints are asynchronous where needed. It's notable that one of them is "adaptive", which I don't think the Teensy can be without a lot of (unnecessary?) work to tweak the I²S clock rate to match the PC. Far better to get the PC (which has memory and processing power on its side) to be the adaptive element.

But I freely confess not to understand fully how this should be properly set up, and to be waiting for a motivated expert to rock up and wave their magic wand!
 
Hahaha aren't we all. Save us oh mighty teensy master! Anyway I should be able to mess with my potential temp solution today. Not at all teensy audio related, but would at least get me by. Time will tell.
 
Back
Top