USB Audio firmware development - Multiple Bit Resolutions and Sample rates

[alambert]

Well, working more. So I have confirmed that my chosen microcontroller has endpoints with a maximum size of 512 bytes. I wish to send more than 512 bytes in a single USB microframe. So how would this work? I tried using the same endpoint twice consecutively, and it ended up being in the next available microframe (4 microframes later, since I have bInterval = 3 at high speed). But, I've tried configuring two endpoints and sending some of the data in endpoint 1, and the rest in endpoint 2; the host does not recognize the second packet. Is there something specific with USB Audio or Isochronous for forming a (micro)frame packet from two IN endpoints? Or is this more likely to be some particular detail of the microcontroller?

[Jan Axelson]

In a USB 2.0 endpoint descriptor, bits 12..11 indicate how many additional transactions
per microframe a high-speed interrupt or isochronous endpoint supports: 00 =
no additional transactions (total of 1 / microframe), 01 = one additional (total of 2 /
microframe), 10 = 2 additional (total of 3 / microframe).

[alambert]

Oh, is that different than the high bandwidth mode that uses the DATA1 and DATA2 packets in addition to DATA0? I thought that that was different. Also, will it still work if bInterval is not set to the smallest value, 1? Mine is currently on 3 to comply with Windows (every 500us).

[Jan Axelson]

The endpoint descriptor specifies the number of packets per microframe for high-bandwidth endpoints, which use DATA0, DATA1, and DATA2. See 5.9.2 in the USB 2.0 spec.

5.6.4 in the USB 2.0 spec says:

A high-bandwidth endpoint must specify a period of 1x125 μs (i.e., a bInterval value of 1).

[alambert]

I think the underlying issue may be in how the microcontroller's USB DMA handles writes to the bus, and I just have to configure the write to be larger than the endpoint size to get multiple transfers from the endpoint buffer to the DMA buffer, which will then place the packet on the USB.

So the next problem I have to tackle is simultaneous In and Out packets to and from my device. The goal is to have a PC host send the audio device samples, which will go to a DAC chip and drive an output, then sample a sensor with an ADC chip, and send that sample back to the PC host.

Is this going to be a game of taking turns between IN and OUT transactions, e.g. time multiplexing? I'm a bit concerned, because currently I can only afford 2 transactions every 1ms frame, and until I deal with the DMA buffer size I have a limit of 512 bytes per packet. If I could somehow have two bInterval = 3 high speed transactions (every 4 microframes), but have the IN and OUT periods offset, that would be ideal. Not sure if I can actually do this, though. E.g., if I implement a microframe number check and send IN transactions to the host on mFrames 0 and 4, and receive OUT transactions from the host on mFrames 2 and 6, will both of these pipes be valid?

[Jan Axelson]

During enumeration, the host should determine if the requested bandwidth is available and refuse to configure the device if not.

After enumeration, the device can only respond to what the host does (send or request data).

Not sure what you mean by "implement a microframe number check".

[alambert]

In my microcontroller, as the host sends start-of-frames and microframes, the SOF count and MSOF count is stored in a register. So, in order to fulfill the indicated 2 transactions per ms, I check for microframe values of 0 and 4, and fulfill IN requests then.

I'm not sure how to do timing of reading OUT packet data though, since I currently don't know when the host will send these packets, relative to when I'm having the microcontroller send IN packets.

Basically, I need to figure out how to juggle the timing of receiving packets from the host, and sending packets to the host via OUT and IN transactions, respectively.

[Jan Axelson]

The device should try to be ready to receive data whenever it arrives, usually using an interrupt-driven routine to get received data and arm the endpoint so it can receive the next packet.

In a similar way, the device can arm the IN endpoint with data to send, and the host will retrieve the data when it wants. An interrupt routine can detect the sending of data and arm the endpoint with new data to send.