[error401]

Quote:

Originally Posted by ericj /img/forum/go_quote.gif I suspect that existing 96khz usb audio products are all using custom ASICs. We could probably come up with a high-sample-rate usb-to-i2s solution using something like a Cypress EZ-USB chip, but first you'd have to find someone who knows how to program the things.

The TAS1020B mentioned above seems to have built-in support for I2S, and seems like it'd be quite easy to get working (compared to a generic USB controller). I may be trivializing things a bit, but I think all you'd need the MCU to do is enumerate and set up the in/out endpoints (the USB Audio device class is directly supported by this device). I think the biggest real problem would be the requirement of uploading firmware to the device. We'd either have to write our own driver to do this whenever it's connected, or provide a preprogrammed EEPROM on board to upload the firmware. The TQFP48 package would probably be quite difficult to solder by hand, even with decent SMD skills.

Could be a fun project, but not something I want badly enough to try (and expend serious resources working on, I doubt I could get a working board 1st rev and I don't have a scope or logic analyzer). It's fun enough to do the research though .

Edit: Actually, it looks like TI already provides a DFU driver that would allow the firmware to be sent automatically when the device is connected, rather than requiring an EEPROM. Cool. If someone with design skills wants to pursue this I'd definitely be willing to assist with design and programming.

 

[ericj]

Quote:

Originally Posted by error401 /img/forum/go_quote.gif The TAS1020B mentioned above seems to have built-in support for I2S, and seems like it'd be quite easy to get working (compared to a generic USB controller).

Right, but the datasheet seems to indicate that it won't do 96khz, and at any rate it's a usb 1.1 part, and likely lacks the bandwidth to do it.

 

[error401]

Quote:

Originally Posted by ericj /img/forum/go_quote.gif Right, but the datasheet seems to indicate that it won't do 96khz, and at any rate it's a usb 1.1 part, and likely lacks the bandwidth to do it.

The datasheet doesn't seem to specify data rates at all, but I didn't get into detail in the ACG or DMA timing sections. I didn't see anything specifically precluding it, it seems to be a pretty generic device.

Stereo 96KHz/24bit is 4.6mbit, USB1.1 can handle 12mbit if there's nothing else going on. Should be fine as long as there aren't too many devices on that root hub.

 

[DaKi][er]

I'm looking over the TI chips linked and they look pretty promising for 96khz audio

They have and 8052 uC core which I can easily program in either straight assembly or C but overall I don't really have much of an idea of what else would be required especially on the PC driver side. what would be perfect is if we could supply our own audio data clock and and the USB slaves off that as the phase noise and jitter of the diy popular PCM290*'s is pretty piss poor and if we could design it to feed out a very clean clocked audio stream at 96khz then we could have a very good performer on our hands

I'll stick up my hand in assisting in designing this, and I'll read up some more and see exactly what is possible to do with these things

 

[Regus]

well 12Mb is enough even for 192kHz 24bit - that only adds up to 9,216,000 bits per second but the problem might very esily turn out to be getting the mcu to put the data onto the I2S bus fast enough and not just that but at the precise speed required for the sampling rate in question

 

[DaKi][er]

I've been reading through the TAS1020B datasheet and I haven't found out if it is 96khz compatible but it does say it allows an external source for its clock used in I2S and it is built for AC'97 spec which is only either 48 or 96khz
Quote:

The features of the codec port interface that can be configured are: • The mode of operation • The number of time slots per codec frame • The number of serial clock cycles for slot 0 • The number of serial clock cycles for all slots other than slot 0 • The number of data bits per audio data time slot • The time slots to be used for command/status address and data • The serial clock (CSCLK) frequency in relation to the codec master clock (MCLK) frequency • The source of the serial clock signal (internally generated or an input from the codec device) • The source of the codec master clock signal used to generate the internal serial clock signal (internally generated by the ACG or an input to the TAS1020B device) • The polarity, duration, and direction of the codec frame sync signal • The relationship between the codec frame sync signal and the serial clock signal • The relationship between the codec frame sync signal and the serial data signals • The relationship between the serial clock signal and the serial data signals • The use of zero padding or a high-impedance state for unused time slots and/or bits • The byte ordering to be used

I'd love to allow it to run all 44.1, 48 and 96khz sources so it will probably need 2 separate clocks and allowing the device to switch between them when needed and hopefully we can get it to do that itself or maybe a clock compatible with both (48 and 96 are already fine as 96/2=48) and have it select its own divider from there. I got a bit more to look into it seems

 

[error401]

Quote:

Originally Posted by Regus /img/forum/go_quote.gif well 12Mb is enough even for 192kHz 24bit - that only adds up to 9,216,000 bits per second but the problem might very esily turn out to be getting the mcu to put the data onto the I2S bus fast enough and not just that but at the precise speed required for the sampling rate in question

The device includes 2 DMA ports to solve this problem. When data is received on USB, it's placed in a ring buffer and the DMA controller clocks it out the I2S lines. The uC doesn't need to get involved at all, except to set up the DMA port and USB endpoint.

After reading quite a bit more, it seems like this is definitely doable. The device itself looks like it'll do most of the work, really all we'd have to program the uC to do is set up the USB endpoints and configuration registers properly, enumerate on the USB bus (which is pretty trivial) and properly deal with a handful of USB control commands, many of which are implemented by routines on the chip's ROM. I'm thinking the uC code is going to be on the order of a couple hundred lines, and it looks like TI has a firmware dev kit that provides example code, so it's really probably not much work.

On the PC driver side, we'll have to set up a DFU driver (TI provides sample code for this as well) to upload the firmware to the chip via USB when it's connected. Once the firmware is sent, the chip reboots and runs the uploaded firmware which implements the standard USB audio device class that doesn't require any drivers, so we don't need an EEPROM. One might be nice to have though as once the firmware is sent once the device could be used on any machine supporting the USB audio device class, rather than whatever OS we write the driver for (probably Windows). The chip automatically accesses and can program the EEPROM over I2C so even this should be quite trivial.

@DaKi][er

I thought one of the advantages of I2S was that it was inherently immune to jitter? Provided the DAC clock is clean, won't we get good output regardless of the quality of the USB controller's clock? I'm pretty new at this audio stuff, so not totally sure on that...

I don't think we're stuck with AC'97 bitrates though, while it supports this interface standard it seems to be a lot more flexible, the datasheet mentions 8KHz sample rates in numerous places, for example. As far as my cursory reading indicates, the c-port clock is based on the ACG module that is based on the chip's 48MHz (PLL based on 6MHz crystal) master clock. The range of the ACG is 750KHz-25MHz so it should be able to generate the 4.608MHz bit clock for 24bit/96KHz stereo as well as any other conceivable bitrate we'd want to use. This clock signal can then be used directly by the DMA/c-port to fire data out the I2S interface.

I'm a bit worried that the USB polling rate for iso transfers and the size of the buffer necessary to support this will create a stumbling block for us. If the device won't support 96KHz, I think this is why it won't work. However, if we don't care about audio input we have access to the entire buffer space, and it seems like it can definitely support 2x48KHz buffers for duplex operation so I think it'd be OK.

This is looking more and more realistic to me as I read more...but I'm not confident enough in my EE skills (even in the digital realm!) to be sure.

 

[DaKi][er]

If the device itself is going to be used to generate the clocks needed for the I2C output, then it does go though quite a process in doing so and it never will achieve the very low jitter that I think is needed for audio. I2S doesn't do anything magic to jitter. here is a thread on measurements of the jitter and phase noise of a few different USB chips most of them were shocking. But if we can provide our own clock and the chip should just feed the data out of the DMA buffer and then the usb device just has to make sure that it is filled from the pc side as fast as we need it

I don't know exactly how it'll work but it probably is going to come down to mostly software in setting up the registers in the MCU (and figuring out which ones) and the hardware is going to be pretty basic. If we really want it to happen then I'll whip up a test board that we can get a few of and then jump into the software which where most of the work will be from my point of view

 

[error401]

Quote:

Originally Posted by DaKi][er /img/forum/go_quote.gif If the device itself is going to be used to generate the clocks needed for the I2C output, then it does go though quite a process in doing so and it never will achieve the very low jitter that I think is needed for audio. I2S doesn't do anything magic to jitter. here is a thread on measurements of the jitter and phase noise of a few different USB chips most of them were shocking. But if we can provide our own clock and the chip should just feed the data out of the DMA buffer and then the usb device just has to make sure that it is filled from the pc side as fast as we need it

If we use the GP codec port interface (instead of the I2S interfaces which require CSCLK to be an output), then we can provide directly a clean clock for the I2S output. It may require extra work to configure the GP codec interface to act the same as I2S, but again, it should just be a matter of programming the registers properly. The problem here, I think, would be implementing a clean multi-frequency clock ourselves. The internal clock for CSCLK passes through 2 or 3 different PLLs as far as I can tell, and this is probably not the greatest for jitter. PLLs are notoriously difficult to design well, and testing them would be problematic. Further, crystals probably don't exist that are the right frequency for what we want. Conclusion: we need at least one oscillator and a configurable divider that will allow the frequencies we need.

I've been looking for the past few minutes for ICs that fit the bill, but there don't seem to be many out there that list low jitter as a specific design goal, so many of them are probably no better than the on-chip oscillators. What I did find are the ADF4001 which seems suitable, but doesn't specify jitter performance, AD9540 which seems like extreme overkill, will be very difficult to solder, and is probably expensive and difficult to source. There seem to be quite a few chips that would be suitable if they supported lower frequencies, most seem to be 20MHz+ minimum. Suggestions for how we're going to get this clean clock to apply?

 

[DaKi][er]

From what I see, we need 2 MCLK frequencies, 11.2896mhz and 24.576mhz for the 3 frequencies of of 44.1, 48 and 96khz, for 44.1 and 96khz, you use a BCLK divider of 4 and for 48khz you use 8 as its running off the clock for the 96khz which we just use the DIVB register to set. We just use regular crystal oscillators and as long as we can get the computer too tell us which frequency we should be using (I'm not up to that yet) then we can just use a multiplexer to switch between the 2 frequencies via the GPIO bits on the MCU

I don't have a link to the good clock oscillators to use but I've got a friend to ask who should know (Garbz) but he's away at the moment

I have been playing around with a quick Schematic and Board layout and this is what I have so far -



This would just be an experimental board layout, I added an LCD header and a few pushbuttons that will allow some user I/O while its running, and will put on a Texas Instruments PCM179* DAC of some sort, and most probably one with I2C controls and voltage outputs instead of current output to make it simpler for now

 

[error401]

Ah, I was under the impression that you wanted to completely avoid any of the clock circuitry on the chip and derive our own clock. I guess a simple frequency divider won't cause many problems for jitter. The input to MCLK is 3v3 though, so I don't think it'll be as simple as dropping a mux in. We'll need an amplifier and edge detector (schottky?) to get a 3v3 signal, and then feed this to the mux. I'm not sure what this will do for jitter performance. Also, it locks us in to a specific bit depth; I've been thinking of 24bit the whole time, but as far as I can tell that'd require an additional 2 oscillators with your scheme if we wanted to support it, or we can ignore 44.1 and support 16/24 bit @ 48 or 96 instead.

This arbitrary clock requirement seems to be what makes USB receivers have such crappy jitter performance. Maybe it's better to just select a single rate (48/96KHz @ 16 bit?) and provide a single high performance clock signal?

It does indeed look like the USB Audio Class specifies that the sampling frequency can be sent when setting up an endpoint, however (from a cursory glance) it isn't clear to me whether it's required or optional. In any case, I suspect that this information is available to the MCU, sent by the host. We can definitely access anything sent over USB.

A couple points on the layout:

I can't tell where AVdd is actually sourcing voltage from, but it definitely needs to be isolated from the digital side. At least on a production board I'd place a separate regulator entirely, and some passive filtering. Per the datasheet, AVss should be connected through a ferrite as well.

What's the purpose of the NAND? Couldn't the same be done in firmware just as easily?

For a dev board, why not use RS232 instead of the LCD? Easier to implement and more flexible, plus it leaves some GPIO for other uses (eg. selecting the crystal). The chip has an onboard UART as well.

A few thoughts on the production device as well...

IMO we should include an (optional) SPDIF encoder, as well as bring the I2S lines out for those that want to connect directly to a DAC IC. What's the output of this thing going to be at the end of the day? Digital only? Analog option?

I also think that the I2C lines should be exposed; this could have some fun applications like making the OS volume control manipulate a digital attenuator in the amp, and with the firmware upgradeable easily via USB, would make it fairly easy to make addon modules for this kind of thing.

 

[DaKi][er]

Quote:

Originally Posted by error401 /img/forum/go_quote.gif Ah, I was under the impression that you wanted to completely avoid any of the clock circuitry on the chip and derive our own clock. I guess a simple frequency divider won't cause many problems for jitter. The input to MCLK is 3v3 though, so I don't think it'll be as simple as dropping a mux in. We'll need an amplifier and edge detector (schottky?) to get a 3v3 signal, and then feed this to the mux. I'm not sure what this will do for jitter performance. Also, it locks us in to a specific bit depth; I've been thinking of 24bit the whole time, but as far as I can tell that'd require an additional 2 oscillators with your scheme if we wanted to support it, or we can ignore 44.1 and support 16/24 bit @ 48 or 96 instead.

As long as we have the original clock source then we can reclock anything that comes out of the chip with flipflops very easily. The data rate will easily be fixed at 64Fs which gives 32 bits per left and right channel and that is actually pretty common for all I2S and if needed, we can tell the dac how many effective bits we are sending and it should deal with it fine. So we have the bit clock running at 64FS and then the master clock can be 256 or 512Fs

If we use oscillators with the amplifier stuff built into it so that we just supply the voltage and out comes the clock then I don't see why a simple mux cannot switch between them, here is a quick link to the type I'm talking about but I'm sure there are some low noise better alternatives out there
Quote:

Originally Posted by error401 /img/forum/go_quote.gif This arbitrary clock requirement seems to be what makes USB receivers have such crappy jitter performance. Maybe it's better to just select a single rate (48/96KHz @ 16 bit?) and provide a single high performance clock signal?

I don't see why we cannot achieve something that will take any of the common audio frequencies. 44.1 is the standard for CD audio and is the most important requirement for me, I'm just trying to build something that will do 24/96 as well straight off USB as well
Quote:

Originally Posted by error401 /img/forum/go_quote.gif It does indeed look like the USB Audio Class specifies that the sampling frequency can be sent when setting up an endpoint, however (from a cursory glance) it isn't clear to me whether it's required or optional. In any case, I suspect that this information is available to the MCU, sent by the host. We can definitely access anything sent over USB. A couple points on the layout: I can't tell where AVdd is actually sourcing voltage from, but it definitely needs to be isolated from the digital side. At least on a production board I'd place a separate regulator entirely, and some passive filtering. Per the datasheet, AVss should be connected through a ferrite as well.

Another reg is needed for AVdd, I just didn't add it in yet. I should add ferrites on all supply lines before the ceramic bypass caps for good measures as well
Quote:

Originally Posted by error401 /img/forum/go_quote.gif What's the purpose of the NAND? Couldn't the same be done in firmware just as easily?

That is there to trigger the external interrupt pin if any of the 4 buttons is pushed, means we can idle the MCU and have it only wake up on a button push otherwise it will be continuously polling the inputs and I don't overly like the idea of that but it could just be left out (and it is an AND gate)
Quote:

Originally Posted by error401 /img/forum/go_quote.gif For a dev board, why not use RS232 instead of the LCD? Easier to implement and more flexible, plus it leaves some GPIO for other uses (eg. selecting the crystal). The chip has an onboard UART as well.

I really have never done any work with rs232 and microcontrollers, most of the things I've built have had an LCD in them and its worked well in debugging along the way as well, though an rs232 will probably be easily added.
Quote:

Originally Posted by error401 /img/forum/go_quote.gif A few thoughts on the production device as well... IMO we should include an (optional) SPDIF encoder, as well as bring the I2S lines out for those that want to connect directly to a DAC IC. What's the output of this thing going to be at the end of the day? Digital only? Analog option?

I like the idea of having everything on the same board, so that it is a fully working dac with analog outputs as standard. SPDIF really ruins the idea of what I think this is meant to be achieving by getting the best possible clocked audio out of USB but its another option that could easily be added. A header for the I2S line should be in there for sure
Quote:

Originally Posted by error401 /img/forum/go_quote.gif I also think that the I2C lines should be exposed; this could have some fun applications like making the OS volume control manipulate a digital attenuator in the amp, and with the firmware upgradeable easily via USB, would make it fairly easy to make addon modules for this kind of thing.

Great idea.

 

[error401]

Quote:

Originally Posted by DaKi][er /img/forum/go_quote.gif As long as we have the original clock source then we can reclock anything that comes out of the chip with flipflops very easily. The data rate will easily be fixed at 64Fs which gives 32 bits per left and right channel and that is actually pretty common for all I2S and if needed, we can tell the dac how many effective bits we are sending and it should deal with it fine. So we have the bit clock running at 64FS and then the master clock can be 256 or 512Fs If we use oscillators with the amplifier stuff built into it so that we just supply the voltage and out comes the clock then I don't see why a simple mux cannot switch between them, here is a quick link to the type I'm talking about but I'm sure there are some low noise better alternatives out there

Ah. I completely missed that I2S provides for padding to a constant word length. That makes this whole multiclock strategy much easier. I wasn't aware of these all-in-one oscillators either...my inexperience with large products is showing clearly today. Most of the stuff I've done doesn't require accurate timing and involves mostly uC programming. Glad you know what you're doing

.

I'm still thinking it might be possible to get more flexibility and better jitter performance out of a clock generator IC though. A PLL should (theoretically, anyway) be able to integrate out some crystal oscillator error and a chip with an integrated multistage divider would remove the need for a second oscillator. For the frequencies we're interested in, this Maxim application note indicates that a typical VCXO circuit has jitter from 50-100ps in the range we're interested in.

While I was looking around I found a lot that could do 256Fs and supported all the normal sampling rates, which would generate all of the clocks we're interested in. I'm not quite sure what good jitter performance numbers are, but many of them seem quite good when compared to the post linked above. A 5-minute search before I leave work gives these: Maxim has the MAX9485 that claims RMS jitter of 21ps, has an I2C interface and supports all the frequencies we're interested in. TI has the 50ps-rated PLL1708 for $4. There must be others.

Quote:

Originally Posted by DaKi [er;2742575']That is there to trigger the external interrupt pin if any of the 4 buttons is pushed, means we can idle the MCU and have it only wake up on a button push otherwise it will be continuously polling the inputs and I don't overly like the idea of that but it could just be left out (and it is an AND gate) I really have never done any work with rs232 and microcontrollers, most of the things I've built have had an LCD in them and its worked well in debugging along the way as well, though an rs232 will probably be easily added.

Ah, I'm used to AVR and PIC where you're usually provided with either half or a full GPIO port that will trigger interrupts. Didn't even come to mind, I didn't do any more than skim the microcontroller section of the datasheet.

I'm just thinking that we're going to need more than 1 GPIO line to prototype everything, and it seemed an easier way to free up ports than adding a shift register to control the LCD serially. Also allows your screen buffer on the terminal to hold some historical data ie. boot sequence etc, and probably has a better response time for fast events. Since the uC has a built-in UART, programming for it should be trivial, probably easier than the LCD - but we would need a level changer to at least get TTL levels, if not proper RS232 for it to be useful. But then again, we should only need 1 pin to switch frequencies anyway, so I suppose the extra GPIO wouldn't be strictly necessary.

Quote:

Originally Posted by DaKi [er;2742575']I like the idea of having everything on the same board, so that it is a fully working dac with analog outputs as standard. SPDIF really ruins the idea of what I think this is meant to be achieving by getting the best possible clocked audio out of USB but its another option that could easily be added. A header for the I2S line should be in there for sure

Agreed, I don't think SPDIF is any good either, I just thought that many might prefer to use their high-end DAC than whatever we would choose to integrate. Since many of these higher-end DACs reclock the signal anyway, it shouldn't be quite as heinous as it looks. Since the idea was proposed, I've though a decent DAC should be included, if only an option, especially since I don't currently have a DAC and am interested in prototyping and helping design this

.

 

[DaKi][er]

Good jitter numbers that I've heard people quoting is <2ps and is something that I'm going to be aiming for. I'll have a look later on what other clock options are out there

There is plenty of opportunity to free up GPIO pins, I've only just chucked some stuff on there for now, once all the hardware is decided on then I'll see what fits where

And I'm open to adding just about anything on as long as it doesn't effect the core features of what we are trying to achieve

 

[DaKi][er]

Well once I get a design in my head there is nothing stopping me...





RS232 with a MAX232
Shift register on the LCD reducing its pins used to 2
PCM1792 DAC with I2C control
5 GPIO pins left unused

I've laid out just about all the parts in at least their general place and I'm happy with most of it. There are a few things that need to be finalised with the master clock in to the TAS1020B and the i/v and filter stage of the dac is just thrown together just to conceptualise it, that is pretty standard datasheet stuff for at least now

One thing I cannot find is an IC to encode I2S into SPDIF, anyone know of what there is out there? Google and Digikey brought up nothing