Drive NOS AD1865/62,PCM1704/02/63,TDA1541 from FIFO: Universal I2S-PCM driver board

[iancanada]

Rather than I2S signals, most of R-2R NOS DACs (PCM63, AD1865, AD1862, PCM1704, PCM1702, TDA1541...) driven by LL/LR, DL, DR and BCK. I might be wrong, but to make it easier, I call them “PCM” signals.

Usually those signals are generated by digital filter chips (DF1704, PDM100, SM5842/43/47...). However, for applications such as NOS mode, software based up-sampling mode, or to interface directly with FIFO KIT, we don’t need that digital filter. In this case, how to design a low jitter I2S to PCM driver daughter board becomes an issue.

Zinsula, vzs and other members provided a lot of good suggestions on this driver board, I summarize those the requirements as blow

1. Support 16,18,20,24 bit PCM format
2. Support PCM63,AD1865,AD1862,PCM1704,PCM1702,TDA154 and other 2-2R DAC
3. L,R simultaneous timing, latching at same latching edge to eliminate L/R phase difference
4. Bit clock can be stopped after data shifted into DAC to reduce DAC noise floor further
5. Optional tail clocks after latching work for PCM17XX DAC
6. Optional one leading clock to “warm up” logic state machine(may not need in most of cases)
7. FPGA/CPLD based low jitter synchronized logic design clocked by MCLK only
8. High speed design capable for 384KHz Fs with maxima MCLK over 100MHz
9. Support dual mono DAC mode
10. Very high speed re-clocking at last stage optimized for low jitter performance
11. Daughter board architecture can stack on top of the FIFO clock board

I started this I2S to PCM driver daughter board project a couple of month ago. Now I’m almost done. Here are some previous progresses posted on the FIFO thread:

http://www.diyaudio.com/forums/digital-line-level/192465-asynchronous-i2s-fifo-project-ultimate-weapon-fight-jitter-33.html#post2980088

http://www.diyaudio.com/forums/digital-line-level/192465-asynchronous-i2s-fifo-project-ultimate-weapon-fight-jitter-35.html#post2983484

http://www.diyaudio.com/forums/digital-line-level/192465-asynchronous-i2s-fifo-project-ultimate-weapon-fight-jitter-36.html#post2985663

http://www.diyaudio.com/forums/digital-line-level/192465-asynchronous-i2s-fifo-project-ultimate-weapon-fight-jitter-39.html#post2989034

http://www.diyaudio.com/forums/digital-line-level/192465-asynchronous-i2s-fifo-project-ultimate-weapon-fight-jitter-40.html#post2991350

http://www.diyaudio.com/forums/digital-line-level/192465-asynchronous-i2s-fifo-project-ultimate-weapon-fight-jitter-40.html#post2991644

http://www.diyaudio.com/forums/digital-line-level/192465-asynchronous-i2s-fifo-project-ultimate-weapon-fight-jitter-40.html#post2991670

http://www.diyaudio.com/forums/digital-line-level/192465-asynchronous-i2s-fifo-project-ultimate-weapon-fight-jitter-43.html#post2995428

http://www.diyaudio.com/forums/digital-line-level/192465-asynchronous-i2s-fifo-project-ultimate-weapon-fight-jitter-47.html#post3016242

http://www.diyaudio.com/forums/digital-line-level/192465-asynchronous-i2s-fifo-project-ultimate-weapon-fight-jitter-59.html#post3041836

http://www.diyaudio.com/forums/digital-line-level/192465-asynchronous-i2s-fifo-project-ultimate-weapon-fight-jitter-60.html#post3043110

http://www.diyaudio.com/forums/digital-line-level/192465-asynchronous-i2s-fifo-project-ultimate-weapon-fight-jitter-60.html#post3047114

http://www.diyaudio.com/forums/digital-line-level/192465-asynchronous-i2s-fifo-project-ultimate-weapon-fight-jitter-81.html

http://www.diyaudio.com/forums/digital-line-level/192465-asynchronous-i2s-fifo-project-ultimate-weapon-fight-jitter-88.html

regal suggested me opening a new thread for this project. That makes sense. NOS DAC and DS DAC belong to different application. It’s not good mixing them up.

Will start evaluating this daughter board very soon.

Ian

 

[TV Man]

This is a very interesting project. Can't wait until the PCB is available!

 

[iancanada]

Testing result of AD1865 timing from a logical analyzer

To get the perfect timing, CLK will be stopped after 18 bit DL and DR shifted into AD1865. Left and right converting will be launched at the same moment of the falling edge of LLLR. All of the signals will keep low for rest of time to reduce the noise. Please refer to the first waveform from logic analyzer.

Jumper settings:
J18bit: shorted
Rest jumpers: keep open

We can still go back to the traditional continue clock mode by just short another JCONT jumper. The second waveform is the result of this mode.

Ian

 

[qusp]

despite not being aimed at it, this could be interesting for use as an external filter for ESS in NOS mode

 

[glt]

Ian,
It is amazing how fast you can design and build boards.

 

[iancanada]

AD1862 timing, Testing result from logic analyzer

AD1862 is a 20bit mono DAC. We need two AD1862, one for left, one for right.
To get the perfect timing, CLK will be stopped after 20 bit DATA shifted into AD1862. Left and right AD1862 converting will be launched at the same moment of the falling edge of LE. All of the signals will keep low for rest of time to reduce the noise. Please refer to the attached waveform from logic analyzer.

Jumper settings:
J20bit: shorted
Rest jumpers: keep open

We can still go back to the traditional continue clock mode by just short another JCONT jumper.

 

[vzs]

The waveforms looks good!
I'm rejoicing the stoppable bit clock feature, with simple logic ICs would have been a pain to do it.

Seems that people started to read sampling theory docs and keep away from everything that contains the NOS word (for good reason I must say)
They surely forget that free software like SoX can software oversample and do the "black magic" that only proprietary FPGA or DSP algorithms could do - like apodizing or minimum phase filters (google for who are using these...): e.g. Minimum Phase SoX settings

So the only thing needed is USB or SPDIF up to 192KHz and a NOS DAC

 

[qusp]

exactly, NOS dac, but not NOS signal path. computers have enough processing power to make light work of more demanding filters very difficult to achieve otherwise.

 

[Lupulroz]

The waveforms looks good!
I'm rejoicing the stoppable bit clock feature, with simple logic ICs would have been a pain to do it.

Seems that people started to read sampling theory docs and keep away from everything that contains the NOS word (for good reason I must say)
They surely forget that free software like SoX can software oversample and do the "black magic" that only proprietary FPGA or DSP algorithms could do - like apodizing or minimum phase filters (google for who are using these...): e.g. Minimum Phase SoX settings

So the only thing needed is USB or SPDIF up to 192KHz and a NOS DAC

It surely can be a way, but I don't feel it's the ideal approach.
First of all, the 192k limit is small for oversampling of any kind. Even 384k that is the limit for Ian's board will not allow more than 8x os. But the thing is that we go again in all that mumbo-jumbo which is computer audio software.
The FPGA/DSP impementation of apodizing or minimum phase filters is not at all "black magic", it just pure math.

 

[qusp]

hmm what makes you think fpga is any less mumbo jumbo than a software implementation of the same thing? ians board will allow 384khz at 128x FS. for me I really dont care where it happens. but I think i'll let you guys have the promised land, or it'll turn into a turf war lol

 

[vzs]

I'm a skeptical person so I think ideal approaches don't exist.
Point me to an off the shelf FPGA/DSP DF board __not complete DAC product__ which implements these apodizing or minimum phase filters and will be happy to try it. So compared to off the shelf DFs this approach might be better - will see.
Agree that 384k would be better but with SPDIF I'm tied to 192k and a fifth-sixth order LPF on the analog side.
I'm crossing my fingers that KOON3876 will make the 25$ Raspberry Pi stream 192k and who knows, 384k too. For that price that can be a game changer digital source.

LE: don't care either where the pure math happens until I get a clean stream to my DAC

 

[Lupulroz]

hmm what makes you think fpga is any less mumbo jumbo than a software implementation of the same thing?

The fpga is a much more controlled environment. It's just a piece of hardware, and once you set it right, you will never experience issues and differences related to operating systems, running processes, drivers, playback software and so on. Plus, the fpga inherent parallellism makes them quite suitable for the task. Just my 2 cents.

 

[Lupulroz]

I'm a skeptical person so I think ideal approaches don't exist.
Point me to an off the shelf FPGA/DSP DF board __not complete DAC product__ which implements these apodizing or minimum phase filters and will be happy to try it. So compared to off the shelf DFs this approach might be better - will see.
Agree that 384k would be better but with SPDIF I'm tied to 192k and a fifth-sixth order LPF on the analog side.

Of course , nothing is ideal, we were talking about alternatives.
A far as I remember Anagram was offering something like that in the past.
Maybe we should start such a DF board that will do minimum phase, apodising or whatever type of filter - it's been too much time since we are the prisoners of some off-the-shelf chips.

 

[vzs]

...Maybe we should start such a DF board that will do minimum phase, apodising or whatever type of filter - it's been too much time since we are the prisoners of some off-the-shelf chips.

I cannot agree more... it's a very good idea

 

[Lupulroz]

Sounds fun... you can count on me on this one. However let's not hijack Ian's thread. Maybe open a new one.

 

[iancanada]

The FPGA architecture is much suitable for implementing the hardware based digital filter though the software based DF is more flexible. To develop a soft one, e.g for foobar2000, you need to develop a plugin, but for a fpag design, the R&D task would be more focus on the DF itself.

Ian

 

[qusp]

now you just need to maintain Ians interest and there'll be a board design ready for prototype within the month =)

 

[regal]

You guys are really getting it. I am I agree with your as*sment fully, thankyou for your support on this. We are talking about an new way to look at a DAC. Let's face it if it weren't for PC's we wouldn't even be talking about DAC's 15 years after they basically went exinct (or Ian's FIFO.)

And yes the argument of pure math, hardware vs a PC (toy) doing the math is an issue. But an FPGA isn't the answer unless you reclock after words and then we might as well start over the whole project. I don't run any process off a PC at work, there is a move toward doing that, however I won't go there yet.

But since this is about music I am more open minded toward the usefullness of the convenience to put together filter algorthms from the PC which can compete with the handful of experts who actually pull of decent oversampling code. The PC can help the creative side of things because it isn't pigeon holed to a small group who know AD Sharc/Blackfin or others.

So what we have presented is an NOS DAC if you want, but this is step in a direction for the potential to evolve the DAC as a further integration to the PC.

The best part is it allows the hobbiest to build the DAC whith the chip one wishes and focus on what we diyaudio freaks are good at - the analog section.

Ian, Thankyou for presenting this.

 

[qusp]

The fpga is a much more controlled environment. It's just a piece of hardware, and once you set it right, you will never experience issues and differences related to operating systems, running processes, drivers, playback software and so on. Plus, the fpga inherent parallellism makes them quite suitable for the task. Just my 2 cents.

hmm I guess I havent had as many troubles, as I see it the PC has more than enough processing power, is more flexible and allows the crossover, volume control and OSF to be part of one and the same process. hardware is nice and I understand what you mean, but the issues you speak of are with certain software designers and the users susceptibility to black magic claims, nothing to do with the PC/MAC itself.

write the code to utilize the vector processor in the i5/7 or a suitable graphics card

 

[regal]

duplicate