[error401]

CS8406 or STA020D, both about $6 at DigiKey, both I2C devices compatible with I2S.

Looking pretty sweet.

Edit: I'm not sure I see the purpose of the flipflop and how it's going to improve the clock accuracy. First of all, its propogation characteristics aren't well defined, and it's very likely that they will be less consistent even than the USB controller's clock dividers (which are intended to be accurate in this respect). Second, I don't see what it does that isn't achieved by simply feeding the master clock to the DAC instead of the derived clock out of the USB chip. The data is going to be latched into the DAC in a similar way as you're doing with the flipflop now, why the extra stage?

Are you forgetting the GPIO to the LCD to latch data in from the shift register?

 

[saratoga]

Quote:

Originally Posted by ericj /img/forum/go_quote.gif I suspect that it's not so much the bandwidth as the available isochronous bandwidth + timing issues. At any rate, there is also the Tascam US144. CMedia has a few usb2.0 audio codecs available, but they sure don't do 96khz. however, this guarantees that cheezy usb2 audio devices will soon be in the $20 range. And they'll probably suck. See my RMAA tests of a Turtle Beach Audio Advantage Micro (CM102-A): http://166.70.233.190/rmaa/Turtle%20...ge%20Micro.htm

Those results are interesting. Any chance you could do a test with a decent load? I'm curious how well that DAC would handle 16 or 32 ohm IEMs. For the price, it still might be fun to play with if it could handle headphones.

 

[DaKi][er]

OK, i've made more progress and have just about finished the board layout for at least now. Missing is the output transformer for the spdif in the top left.

I still haven't decided on what clock to use, I haven't really been looking around much either but I don't think picking that is real important for now, they just have to be 11.2896mhz and 24.576mhz. There is a tristate buffer for the multiplexing so it will be simple to turn them both on and off

What really needs to be done is to start setting up the software and have a list of all the registers and what we need to set them to for all the different frequencies for the USB, SPDIF and DAC chips which the last 2 are on the I2C bus. When I got the the time I'll sit down and make a start of it

 

[error401]

Let me know if you want help with that and we can split it up.

I'm pretty certain that LCD interface isn't going to work as is, it's not going to like us shifting data across it's input without a strobe. I really don't like the flip-flop there either, can you explain how it doesn't contribute significant jitter? I don't know much about the internal properties of the 74HC family, but I'd imagine their propogation delay isn't very constant. Can't the DAC handle MCLK directly, the datasheet indicates that it should; MCLK and CSCLK should be synchronous anyway...

 

[DaKi][er]

I was wondering what you were worrying about with the LCD and shift register and now I see what you mean, the data gets shifted across the output pins as its clocked in, no good, I'll get another chip.

I'm not 100% clued up on the flipflop reclocking but that is the part that is used for doing the same thing in situations that really need it, it can be bypassed easily and I'll ask the guys in the know with regards to help clear that up if it should be there or not

The dac takes in 4 clocks/data but only one of them is used to clock the data from digital to analog once its in there, this is the one where the low jitter is crucial.

Looking through the tas1020b datasheet, it is a little daunting about what registers to set especially for the DMA and other things needed, if you want you can start on that and I'll easily get the DAC and SPDIF registers laid out, then when it comes to writing the MCU code it will just fall in place just about

 

[error401]

Well I took a look at this tonight and after a couple hours of datasheet reading, my brain is fried, but I have a decent understanding of how most of this should work, except for all the dozens of clocks floating around and what frequencies they need to be at. Which is the main part of setting the registers in this thing. There seems to be a full implementation of a USB soundcard as part of the dev kit (it's the source for the dev board firmware) that should be a good starting point. I'm not sure we need to map these registers out now, I think I'd personally prefer to work on the software with the hardware in front of me and in a code editor, especially since we can probably steal most of the code from the included implementation. The only major changes should be to get I2S working rather than the AC'97 used in the example, which shouldn't be too bad, and adding all the I2C code to push the registers for the other chips. And of course getting it to compile under SDCC instead of the expensive proprietary compiler TI used.

I did some more research on the clocking techniques you're using and apparently Tent has measured the 74HC74 and found it to be low-jitter, so I'll trust that approach. Not sure about the 74LS125 either; the 74HC125 seems to be faster and might be a better choice, but I'm still not convinced putting digital logic in the clock path isn't going to mess with our clean clock to begin with. I still don't really understand the jitter thing though, at Tent's site he shows some frequency domain graphs of good and bad clocks. The good clock is a perfect sine wave at a single frequency, but obviously the 74HC74 is going to chop that into a square and the frequency domain graph is going to be a mess, I don't see how it can still be low jitter if the definition of low jitter is 'has no frequency components other than the fundamental'. As a result I'm going to defer the clock part of the circuit to you, but I've got some things I think might be problems:

Now that I read more on the PCM1792 I don't see the purpose of the 74HC74, it's part of the digital interface and has nothing to do with the DAC clock. We don't care if it jitters, we need it to be in perfect sync with CDAT0, which it won't be due to the FF. I propose we just ditch the 74HC74 entirely, it adds complexity and serves no purpose I can see. All BCK does is shift data into the DAC's shift registers, shouldn't have anything to do with audio quality.

I'm also not totally sure we are going to be able to un-jitter the data coming over USB. The PC controls the timing on that side and in fact the datasheet for the TAS1020 recommends locking onto the SOF indicators with the internal PLL to establish the output clocks. Providing an external clock to the I2S interface in this case is not going to work, we'll constantly hit buffer over/underruns. I'm not positive on this though, I will investigate further. Those saying USB can never produce low-jitter output may in fact have a point...

A couple more thoughts on the schematic:

P3.0 and P3.1 need to be swapped to the MAX232. P3.0 is the UART output and you've got it connected to the MAX232 output, and vice-versa.

We need a button/switch to turn off the EEPROM or zero the I2C bus to force the chip to load into DFU mode for firmware upload.

And, uh, if we're going to actually design and build this thing maybe we should start a thread for it...

 

[DaKi][er]

If you want to code the whole thing then I'm fine with that, and having the finished hardware in front of you will be a must for that. I was thinking of doing it myself for the MCU and setting up the other chips over the I2C as I’m pretty fluent in the 8051 assembly language I was going to do it all in that.

I don’t see any other way without putting some logic between the clocks and the TAS1020B, we don’t have any other way of selecting the proper one. I just went through the logic gate library and picked one that looked alright, the fact that it is a LS part isn’t really a concern, it’s just the label that the software gave it and HC should be used throughout. I’ll have to read up some more about squarewave /sinewave clocks and if needed an analog switch could be used then. I’m pretty much set on using TentLabs XO’s for this, the specs are pretty good and I don’t know of anything better.

I’ve taken the 74HC74 out for now as well, though I do see some merit for having it in there somewhere, as the reason we need low jitter is only for the clock that transfers the digital data sitting in the parallel registers in the DAC and shifting them to analog, now the datasheets don’t show which of the clock inputs are doing this, but ‘m pretty sure that it is BCLK that is doing it and since that is being produced by the TAS1020B and we don’t really know what evil thing it is doing to create it then I was thinking it is safe to reclock it.

The only reason I’m doing this project is for low jitter digital data out of USB, while it started as just requiring 96khz that is of little concern for me and having it is just a bonus. If there are DMA buffers then I’d think that they are long enough to stop buffer over/under runs and as long as something in there can tell the PC to speed up or slow down a bit then I should be fine. If that isn’t possible at all then I got a few ideas that might be able to overcome that as well, using VXCO’s we can make our own PLL basically but keep its response really slow in the 0.1hz range as long as we have large enough buffers that can take this. I really don’t want it to come down to this

I thought I was pretty sure that I got the pins the right way on the UART output, as the datasheet says there are 4 modes that it can run in and for the first the pins are swapped to the other 3

Will a jumper on the power pin of the EEPROM be enough? Just there isn’t a whole lot of room

And finally, I thought this thread is good enough to discuss the design and build, we’ve already got everything in here so far

 

[error401]

Quote:

Originally Posted by DaKi][er /img/forum/go_quote.gif If you want to code the whole thing then I'm fine with that, and having the finished hardware in front of you will be a must for that. I was thinking of doing it myself for the MCU and setting up the other chips over the I2C as I’m pretty fluent in the 8051 assembly language I was going to do it all in that.

Either way works for me, though I've not used the 8051 architecture before. I was planning on C since there's example code and a proven free compiler (mostly because of the example code). Also makes it easier to collaborate. I suspect that you have better test equipment than I do though, so the final programming and debugging would probably be easier on your side. We aren't really there yet though.
Quote:

I don’t see any other way without putting some logic between the clocks and the TAS1020B, we don’t have any other way of selecting the proper one. I just went through the logic gate library and picked one that looked alright, the fact that it is a LS part isn’t really a concern, it’s just the label that the software gave it and HC should be used throughout. I’ll have to read up some more about squarewave /sinewave clocks and if needed an analog switch could be used then. I’m pretty much set on using TentLabs XO’s for this, the specs are pretty good and I don’t know of anything better.

Maybe gang the outputs together and switch the power with a pair of FETs? Or run the outputs through diodes and pull the 'off' one down through a GPIO (or FET if necessary)?

Tent's XOs are pricey, but the specs are good. I'm very skeptical of that sort of product though, I wouldn't be at all surprised if they're just rebranded generic XOs. Few can measure the difference, and fewer care after shelling out 5x the price of a standard part. On the plus side, that means they're pin compatible so I don't really care.
Quote:

I’ve taken the 74HC74 out for now as well, though I do see some merit for having it in there somewhere, as the reason we need low jitter is only for the clock that transfers the digital data sitting in the parallel registers in the DAC and shifting them to analog, now the datasheets don’t show which of the clock inputs are doing this, but ‘m pretty sure that it is BCLK that is doing it and since that is being produced by the TAS1020B and we don’t really know what evil thing it is doing to create it then I was thinking it is safe to reclock it.

According to the datasheet, SCLK controls the DACs. It also mentions that a low-jitter clock is especially critical here, see pg 13. The DAC is oversampling, so it's run from the internal PLLs anyway, and there's no such thing as a parallel data clock, it's probably a 1-bit DAC. It runs at 64Fs, and I'm assuming it's derived from SCLK, nothing else really makes sense.

Quote:

The only reason I’m doing this project is for low jitter digital data out of USB, while it started as just requiring 96khz that is of little concern for me and having it is just a bonus. If there are DMA buffers then I’d think that they are long enough to stop buffer over/under runs and as long as something in there can tell the PC to speed up or slow down a bit then I should be fine. If that isn’t possible at all then I got a few ideas that might be able to overcome that as well, using VXCO’s we can make our own PLL basically but keep its response really slow in the 0.1hz range as long as we have large enough buffers that can take this. I really don’t want it to come down to this

Yea, I'm pretty sure there's some flow control in there. The datasheet and app notes are pretty light on the detail w.r.t. the USB standard, and I've only skimmed that so I'm not sure. The buffers will be 1ms, as far as I can tell. There's a total of 1308bytes.
Quote:

I thought I was pretty sure that I got the pins the right way on the UART output, as the datasheet says there are 4 modes that it can run in and for the first the pins are swapped to the other 3

You're right, my bad.
Quote:

Will a jumper on the power pin of the EEPROM be enough? Just there isn’t a whole lot of room

Yup, that's fine. Just an easy way to force DFU mode if we upload firmware that jumps to nowhere or gets stuck in a loop or whatnot. Also enables easier upgrading later. I don't know if it's possible to send a software command to request it boot into DFU mode (it's possible from the uC perspective, not sure how easy it is from the driver side). Though I'm not positive the uC will write to the EEPROM if it's not there when it tries to boot. Needs a 'clear all' pin .

Quote:

And finally, I thought this thread is good enough to discuss the design and build, we’ve already got everything in here so far

Sure.

 

[DaKi][er]

Just found this thread - http://www.diyhifi.org/forums/viewtopic.php?t=958

 

[error401]

Quote:

Originally Posted by DaKi][er /img/forum/go_quote.gif Just found this thread - http://www.diyhifi.org/forums/viewtopic.php?t=958

Well that's a bit disheartening.

Looks like we're either going to be doing ASRC (SRC4392 looks impressive, if expensive, and includes an S/PDIF receiver, but doing two TQFPs scares my cheap soldering iron), which would be my preferred solution; or some sort of PLL clock recovery. Unless we can find a suitable low-jitter VCXO controller/PLL on an IC I doubt we can design one with sufficiently good specs to compete with the onboard clock coming out of the TAS1020. Hmm, maybe we can track the USB data with a VCXO at ~6MHz as the TAS1020 master clock?

Another option that I'm not sure is feasible, and that is guaranteed to introduce artifacts now and then, might be to buffer the I2S bus somehow. If we can isolate samples in the buffer stage we might miss/duplicate a sample every now and then (hopefully our clocks are close enough that this happens rarely). Basically, clock the data into one shift register on the TAS1020 clock. Then parallel-load this data into another shift register on the clean wordclock before dumping it into the DAC with the new clock. This should be stable, but it's basically a shoddy ASRC and if we're going to do that, may as well use an ASIC. We could effectively get rid of the buffer over/underrun condition with a large enough buffer that it can eat clock differences before the next period of digital silence and reinitialize then. Problem there is that available microcontrollers are way too slow to do this with SRAM and I can't think of another way to reach the buffer size we'd need. So we'd be looking at an FPGA to handle this task, and this project is deep enough into advanced EE voodoo.

 

[DaKi][er]

Quote:

Originally Posted by error401 /img/forum/go_quote.gif Well that's a bit disheartening. Looks like we're either going to be doing ASRC (SRC4392 looks impressive, if expensive, and includes an S/PDIF receiver, but doing two TQFPs scares my cheap soldering iron), which would be my preferred solution; or some sort of PLL clock recovery. Unless we can find a suitable low-jitter VCXO controller/PLL on an IC I doubt we can design one with sufficiently good specs to compete with the onboard clock coming out of the TAS1020. Hmm, maybe we can track the USB data with a VCXO at ~6MHz as the TAS1020 master clock? Another option that I'm not sure is feasible, and that is guaranteed to introduce artifacts now and then, might be to buffer the I2S bus somehow. If we can isolate samples in the buffer stage we might miss/duplicate a sample every now and then (hopefully our clocks are close enough that this happens rarely). Basically, clock the data into one shift register on the TAS1020 clock. Then parallel-load this data into another shift register on the clean wordclock before dumping it into the DAC with the new clock. This should be stable, but it's basically a shoddy ASRC and if we're going to do that, may as well use an ASIC. We could effectively get rid of the buffer over/underrun condition with a large enough buffer that it can eat clock differences before the next period of digital silence and reinitialize then. Problem there is that available microcontrollers are way too slow to do this with SRAM and I can't think of another way to reach the buffer size we'd need. So we'd be looking at an FPGA to handle this task, and this project is deep enough into advanced EE voodoo.

Personally I don't like ASRC, they really aren't getting rid of the jitter and just convert the jitter to amplitude errors so that technically it reduced the jitter measured but it is now hidden in the data, so I wont be using one of them

My idea on a PLL & VCXO is pretty much along the lines of this - http://www.diyhifi.org/forums/viewtopic.php?p=24351I was actually reading it a few days but never noticed that he was using the TAS1020B as well and it has me wondering that most of the stuff needed is present in the TAS1020B that we don't need an external PIC or FIFO and all that would be needed is a DAC to control the VCXO but then that would require running the TAS1020B as a FIFO buffer output that has a clock in from the PC and us feeding the clock on its output into it and I really don't know if it would like that, the buffers are going to be too short and I don't think the DMA controller is going to let us do it, I really haven't looked through the datasheet in enough detail to get an idea of what it really can do

One day i'm going to build a DAC that is controlled by a FPGA with a similar clocking scheme to the thread I linked to with everything managed by the FPGA and it would take any spdif signal, do its synchronous reclocking, oversampling and digital filtering and then custom crossovers for a 3 way speaker setup before outputting to a bunch of DAC chips, then amps and then speakers. It is only an idea that I've been thinking about for the last few months so far and I'd only start it once I'm a bit further in my education to actually accomplish it. I love to be involved in every single process in the signal chain and do it myself without the restriction that the actual chip makers are under when they design their part, and I should have the best performing application that I can possibly have. I was really keen on this USB idea as it achieved all of the digital requirements that I think is needed in a DAC with regards to the clock and it was simple and small enough that I thought it was really worth doing. Now that core requirement is just about gone I'm not so keen any more, though I'm thinking of having a go at writing drivers and trying to get asynchronously clocked data out of the PC. There was a small mention that it isn't possible with the native XP drivers but Vista has async built in

 

[Skubasteve]

It looks like the 96kHz requirement is a significant stumbling block. However, the prospect of a low-jitter 44.1 kHz solution is certainly interesting. The 44.1 kHz solution could also perhaps accept 88.2 kHz date (since the oscillator probably wouldn't need to be finagled as extensively as in the 96 kHz solution); this would allow for CD material that’s been upsampled 2x to be accommodated.

If we relax the 96 kHz requirement, and instead focus on a low-jitter 44.1/88.2 solution, does using the tas1020 yield a potential improvement in jitter performance over something like the PCM270x? I gather from the comment (by dakiller I think) regarding the PCM290x that anything with a run-of-the-mill internal clock is going to be compromised. So it may be worth it to have a go at the TAS1020 solution just for the sake of low jitter, and add capability to handle additional input frequencies if and when a solution arises.

Is this the sort of clock we want to use to get low jitter?
Crystek Crystals CMOS Clock Osc 4pad (Mouser has it under P/N 549-C3390)

 

[error401]

Quote:

Originally Posted by Skubasteve /img/forum/go_quote.gif It looks like the 96kHz requirement is a significant stumbling block. However, the prospect of a low-jitter 44.1 kHz solution is certainly interesting. The 44.1 kHz solution could also perhaps accept 88.2 kHz date (since the oscillator probably wouldn't need to be finagled as extensively as in the 96 kHz solution); this would allow for CD material that’s been upsampled 2x to be accommodated. If we relax the 96 kHz requirement, and instead focus on a low-jitter 44.1/88.2 solution, does using the tas1020 yield a potential improvement in jitter performance over something like the PCM270x? I gather from the comment (by dakiller I think) regarding the PCM290x that anything with a run-of-the-mill internal clock is going to be compromised. So it may be worth it to have a go at the TAS1020 solution just for the sake of low jitter, and add capability to handle additional input frequencies if and when a solution arises. Is this the sort of clock we want to use to get low jitter? Crystek Crystals CMOS Clock Osc 4pad (Mouser has it under P/N 549-C3390)

The biggest problem probably isn't really the clock switching, we can probably handle that part of things relatively easily. What's really a stumbling block is the way the USB data transfer happens. It seems from my research that the way this is supposed to work is the computer sends exactly 1ms worth of audio data in every packet, and sends a new one every 1ms, regardless of the data rate. There doesn't seem to be a way to request more data, the host just pumps it out at the 1ms/packet rate. The intent is for the controller to lock on to these frames as a timing source; basically count the bits in each packet, multiply by 1000 and use this as the clock frequency, then track to any changes or fluctuations. This is why these are fairly high jitter devices. The most technically apt solution would be to use a relatively large buffer and a very slow control circuit to minutely modify a VCXO's frequency, but integrating this with the USB interface is absolutely a difficult task.

Personally I'd like to build an over-the-top USB-based DAC, and I'd be happy with ASRC. I may still design something, but I'm not sure I'm capable of doing it all myself. I don't have a good grasp of I/V techniques and I'm not the greatest at layout.