[Photostory] Building a Multichannel UAC2 Interface

GroupDIY Audio Forum

Help Support GroupDIY Audio Forum:

This site may earn a commission from merchant affiliate links, including eBay, Amazon, and others.

rkn80

Well-known member
Joined
Sep 20, 2009
Messages
410
Location
Germany
Hi,

this is another subproject of the AD/DA-Box: The Multichannel USB Audio Class 2.0 interface. I know some of you have been already waiting for this project. So here we go.
First start with a 4-layer PCB and a box full of components.  8)

R.
 

Attachments

  • DSC_0926 klein.jpg
    DSC_0926 klein.jpg
    860 KB · Views: 246
The voltage regulators for the processors are done. Input is +5V.
QFN is not really hard to solder I learned today. You can do that with a fine solder iron.
Next step: Let's check that we have now the right voltages on the outputs.

 

Attachments

  • DSC_0930 klein.jpg
    DSC_0930 klein.jpg
    714.2 KB · Views: 232
And no the processor and the basic periphery is done.
Let's see if we can communicate via JTAG with it. But first: DINNER!  :D

R.
 

Attachments

  • DSC_0994 klein.jpeg
    DSC_0994 klein.jpeg
    677.1 KB · Views: 201
Hardware done. Testprogram (blinking LED) programmed and working. Now let's see wether we can communicate via USB.  8)
 

Attachments

  • DSC_1013 klein.jpeg
    DSC_1013 klein.jpeg
    684 KB · Views: 252
rkn80 said:
Hardware done. Testprogram (blinking LED) programmed and working. Now let's see wether we can communicate via USB.  8)

oh, one of the PLX NetChip2272 devices. That's a pretty neat part, and for interfacing to an FPGA where you're doing multichannel streaming audio and the need for a processor is minimal (other than to handle Chapter 9 Control transactions), it's ideal.
 
And currently difficult to get.  :mad:
The first chip I ordered was here within one day, but I made a mistake: It was soldered with the wrong orientation. I should have read the data sheet and not just trust that they do it like all other companies do it...
So I had to order a new one because I could not remove the first one undestroyed from the board.
On that day the distributor said: Expected to be in stock again on 20th February  :eek:
Thus, I had to order it from the USA to get a replacement within one week.

R.
 
nice to see another interesting project from rkn80
is its aim to create a 8 channel (4 stereo output playback or more ?) from usb ?
true there is already usbstreamer from minidsp near perfect for me (adat output as a bonus) but to expensive (and I do not care of the input recording capability useless to me)
there is this one too which is awesome (but I will not have the skill level to have the software transalation side adapted to alsa or jack under linux):
https://sites.google.com/site/koonaudioprojects/usb-to-multi-channel-i2s---simplified
maybe if you had not already done a pcb this koon project would have interested you ?
keep up motivation, thanks

PS: sorry for this off topic of me. I had forgotten you are aiming studio use with DAW meaning universal robust drivers so the koonlab was not a solution for you. On my side I am only looking at a good lowcost playback 8ch device digital i2s output device (adat or usb) with jack or alsa driver. I could still be interested in this project of you... 
 
Hello,

there is now some progress on this project.
First I implemented a stereo in and stereo out configuration in Full-Speed-Mode.  Windows does recognize the new Audio-Device. Mac OSX, too. Now I'm going to switch to High-Speed-Mode (therefore, Windows leaves the party).
The device should support at least 16 inputs and 16 outputs @ 48kHz/24bits full-duplex. This is the minimum. 24 i/os are convenient, 32 i/os @ 48kHz would be nice. Let's see how far we can go. High sampling frequencies will change the channel count and they will follow later step-by-step.

R.
 
Again some news:
The configuration has been changed to UAC2 and the host (MacOSX) accepts the device as a new sound card.  8)
I'm now finding out how the feedback mechanism for async. endpoints works and how the feedback values should be calculated. This is not clear to me, yet. I think I have to send the value per micro frame and not per frame as in UAC1.

R.
 
rkn80 said:
Again some news:
The configuration has been changed to UAC2 and the host (MacOSX) accepts the device as a new sound card.  8)
I'm now finding out how the feedback mechanism for async. endpoints works and how the feedback values should be calculated. This is not clear to me, yet. I think I have to send the value per micro frame and not per frame as in UAC1.

R.

According to Apple if you have a full-duplex soundcard no explicit feedback in async mode is needed - the number of the input samples is used as a number of output samples per given time frame (which sounds logical and correct). On the other hand I haven't verified it, and the XMOS folks keep telling OS X needs feedback and they used much time to get it right. They derive the value from MCLK (which is why MLCK input is needed to XMOS chips in all their USB solutions) so I assume the feeback was generated per micro frame (and indeed the Apple Tech note linked below says the same).

See https://developer.apple.com/library/mac/technotes/tn2274/_index.html

"Explicit feedback endpoint: The device provides an associated isochronous feedback endpoint which sends packets containing the number of samples per USB (micro)frame (see Section 3.7.2.2 of the USB Audio 1.0 Spec and Section 3.16.2.2 of the USB Audio 2.0 Spec.)"

"In order to use implicit feedback, the device must satisfy the following requirements:

* Asynchronous input and output streams reside on one engine (i.e. needs to meet criteria for the Unified Engine Model.)
* The polling intervals (bInterval) for the stream endpoints must match.
* Either the input stream endpoint “Usage type” is set to “Implicit feedback data endpoint” (USB Audio 2.0 only, Section 4.10.1.1) and/or the sync feedback endpoint is omitted (see Table 4.)"

Omitting the feedback endpoint sounds quite easy.
 
mhelin said:
"In order to use implicit feedback, the device must satisfy the following requirements:

* Asynchronous input and output streams reside on one engine (i.e. needs to meet criteria for the Unified Engine Model.)
* The polling intervals (bInterval) for the stream endpoints must match.
* Either the input stream endpoint “Usage type” is set to “Implicit feedback data endpoint” (USB Audio 2.0 only, Section 4.10.1.1) and/or the sync feedback endpoint is omitted (see Table 4.)"

Omitting the feedback endpoint sounds quite easy.

For what it's worth, with the Full Speed USB audio thing I did, the processor (TAS1020B, old, I know!) did not have enough isochronous endpoints to implement the rate feedback, so I just used the implicit feedback and it worked as advertised.

a-
 
Hello everybody,

I already have posted some questions in the 5 YO thread, but I have others questions reporting to USB audio, and I think that is a better place for this kind of questions.

Ok I don't know where to begin ... maybe this post will be a little "miss-ordonned". First an interesting source about USB Auduo :
http://electronicdesign.com/boards/how-create-and-program-usb-devices#1
Some rules about this post : I consider 1 channel is 1 analog channel @ 192Khz and 24 bit, which is the "worst case" possible in terms of bandwith according to
the ADC and DAC choosen by Raphael. So otherwise noted, when I write 1 channel, it is 1 analog (or its digital equivalent) channel, digitalized @ 24x192k. Just to be sure
... 1 I2S channel is 2 analog channel right ?

1) Maximal number of audio channel onto USB
According to the link below, 1 analog channel @ 16x48k uses 0.5% of the bandwith of the USB. So, 1 channel (24x192k) is 3%. So we can put up to 33analog channel 1 one free USB ?

But ! USB (High Speed) is 480Mbps, and 33 channels (24/192k) are only 33*24*192000 = 152064000 = 152Mbps ... so in fact we cant put much more than 33 analog channel !
Which way of thinking is wrong ?
(I need to precise that I know USB maximum bandwith is divided by the number of connected devices, but let's say that I a one completely free USB ... on a PCIe card for example).

2) Number of endpoints
According to the link I gave you, there is up to 16 endpoint on an USB device ... and there are normally 3 obligatory endpoint (2 for control and 1 for feedback).
It remain 13 endpoint, each one have an I2S channel, that made up to 26 analog channel !

I'm sorry, I'm really a newbie in digital audio ... I know digital electronic as I work with FPGA everyday, but not for audio.

I hope someone can reply all this questions.

M.
 
chartanm said:
... 1 I2S channel is 2 analog channel right ?
Yes.

1) Maximal number of audio channel onto USB
According to the link below, 1 analog channel @ 16x48k uses 0.5% of the bandwith of the USB. So, 1 channel (24x192k) is 3%. So we can put up to 33analog channel 1 one free USB ?
Well, let's be clear. You are talking about High Speed USB.

But ! USB (High Speed) is 480Mbps, and 33 channels (24/192k) are only 33*24*192000 = 152064000 = 152Mbps ... so in fact we cant put much more than 33 analog channel !
Which way of thinking is wrong ?
(I need to precise that I know USB maximum bandwith is divided by the number of connected devices, but let's say that I a one completely free USB ... on a PCIe card for example).
Remember that the stated "bandwidth" of 480 Mbps is really the wire speed; for high-speed transactions even one audio channel is still packetized and serialized at that 480 Mbps rate.

Also remember that the operating system will reserve some percentage of available bus bandwidth for the control endpoint.

Now check your math. 192 kHz times 24 bits per sample is 4.6 Mbps per channel.

2) Number of endpoints
According to the link I gave you, there is up to 16 endpoint on an USB device ... and there are normally 3 obligatory endpoint (2 for control and 1 for feedback).
It remain 13 endpoint, each one have an I2S channel, that made up to 26 analog channel !

USB allows for a device to have up to 16 endpoints (8 IN, 8 OUT). It only requires the control endpoint, endpoint 0, and both in and out are required. The audio device interface needs only one endpoint in each direction for the isochronous streaming, and if it uses explicit rate feedback, another pair of isochronous endpoints. I believe that the data for the Audio Control interface can go over the control endpoint (I don't remember).

The point being that only one OUT endpoint is needed for ALL of a device's DAC data, and only one IN endpoint is needed for ALL of a device's ADC data.

-a

 
Hi,

Ok ... Good new ... I'm not so stupid, I understood (a few) things !

Now check your math. 192 kHz times 24 bits per sample is 4.6 Mbps per channel.

Yes, 1 channel is 4.6Mbps so 33 are 152Mbps. Remember, the link said that 1channel 16@48k is 0.5% so 1 channel 24@192k is 3% so according to this we can put 33 channels on an High speed USB.
What I wanna show you is that -even with 99 (3%*33 channels) percent of utilisation according to the link I gave you-  it "remains" 480-152 = 328Mbps. So ... I understand that there are the control endpoints ... put if they uses 328Mbps of the bandwidth ... there is a problem no ?

Remember that the stated "bandwidth" of 480 Mbps is really the wire speed; for high-speed transactions even one audio channel is still packetized and serialized at that 480 Mbps rate.
For example, just to see if I understand well ... UART is 115,2bps (it could be more or less, but it is an example). So, I can send 115200 bits for control, redundancy, error check and data in 1 second. The amount of each is defined by the protocol I'm using on this serial link.
Now, USB is 480Mbps. How many channels can-I put in one USB link ? There are 2  control enpoint (1 in and 1 out if i read well but I'm not sure), 1 isosynchronous enpoint IN for data from ADC, 1  isosynchronous enpoint OUT for data to DAC, and 2 others endpoint for the feedback

The point being that only one OUT endpoint is needed for ALL of a device's DAC data, and only one IN endpoint is needed for ALL of a device's ADC data.

Thank you for this clear explanation ! I hope I dont look so stupid ^^
(for the little story ... if I ask you to repeat or somethink like that, it's because I'm French and my English is far away to be perfect ... that's why sometime I prefer to read 2 different sentences explaining the same thing !)

M.
 
chartanm said:
Hi,

Ok ... Good new ... I'm not so stupid, I understood (a few) things !

Now check your math. 192 kHz times 24 bits per sample is 4.6 Mbps per channel.

Yes, 1 channel is 4.6Mbps so 33 are 152Mbps. Remember, the link said that 1channel 16@48k is 0.5% so 1 channel 24@192k is 3% so according to this we can put 33 channels on an High speed USB.
What I wanna show you is that -even with 99 (3%*33 channels) percent of utilisation according to the link I gave you-  it "remains" 480-152 = 328Mbps. So ... I understand that there are the control endpoints ... put if they uses 328Mbps of the bandwidth ... there is a problem no ?

16 bits/sample times 48,000 samples/second * 64 channels = 49.152 Mbps.

24 bits/sample times 192,000 samples/second * 64 channels = 294.912 Mbps.

All well within the bandwidth provided by the bus, even reserving 10% of bus bandwidth (48 Mbps) for the control endpoint, which is excessive (and might not even be a valid assumption for High Speed USB). This is why it's common to see 32-in/32-out USB audio devices.

So what does this all really mean?

It means that when a device enumerates, it tells the operating system that it requires some amount of bandwidth for its isochronous endpoints. Those endpoints are not active immediately; an application has to request their use. When that happens, the drivers check to see if any other device on the bus is actually using the requested bandwidth; if not, the device is granted exclusive use of the requested bandwidth.

When the device needs 294 Mbps, the remaining ~186 Mbps is still available for use by other devices, which means that you can still talk to your hard drive (which uses the Bulk transfer type) and your keyboard and mouse will also still work (they use the Interrupt transfer type, likely over a Low Speed endpoint).

Now if not enough bandwidth exists (perhaps another 32x32 device is running?), the operating system will not allow the device to activate its isochronous endpoints. Hopefully, the OS will also throw up a useful error message. Mac OS X does. Windows? Hah.

Remember that the stated "bandwidth" of 480 Mbps is really the wire speed; for high-speed transactions even one audio channel is still packetized and serialized at that 480 Mbps rate.
For example, just to see if I understand well ... UART is 115,2bps (it could be more or less, but it is an example). So, I can send 115200 bits for control, redundancy, error check and data in 1 second. The amount of each is defined by the protocol I'm using on this serial link.

Do not make the common mistake of confusing the "serial" in USB with your old-school UART-based "serial" port.

When you are talking about a UART, you must understand that the wire speed also defines the character rate. If you choose 9600 bps, then the signaling on the wire is at 9600 bps. If you choose 115,200 bps, that's the speed of transitions on the wire. Not so with USB, which, as noted, always does high-speed transactions with bit transitions at 480 Mbps.

Now, USB is 480Mbps. How many channels can-I put in one USB link ? There are 2  control enpoint (1 in and 1 out if i read well but I'm not sure), 1 isosynchronous enpoint IN for data from ADC, 1  isosynchronous enpoint OUT for data to DAC, and 2 others endpoint for the feedback

See my discussion above.

The point being that only one OUT endpoint is needed for ALL of a device's DAC data, and only one IN endpoint is needed for ALL of a device's ADC data.

Thank you for this clear explanation ! I hope I dont look so stupid ^^

Oh, don't worry about that. USB can handle a wide variety of data transactions, and it has a large spec. Unless you delve into it seriously, it can be very opaque.

 
Back
Top