Pc -> Dac, How ?

[peufeu]

Isolating USB is hard because the isolator must understand the protocol (a problem with all half-duplex protocols).

It is much simpler to stick some isolators in the I²S and control lines between the FPGA and DACs. It is also better, since the FPGA ground and the audio ground become separate.

So we wll have this :

DAC board has master clock. DAC (sigma-delta) or reclocker (multibit) uses clock directly. Buffered copy of clock is sent through isolator to FPGA. FPGA doesn't care about jitter, only DAC does. Everything where jitter is unimportant (FIR, SPDIF IO etc) is on the FPGA side ; the only digital part on the Analog/DAC side is the DAC and eventual reclocker for multibit DACs.

Thus FPGA is not isolated from PC, there is no need.

> My other misunderstanding was the amount of
> processing you were contemplating

Depends on what you want to do. I want to try oversampling filters, so I looked at a known-good one which is libsamplerate (Secret Rabbit Code). When working at 4x (48->192) it uses 4k coeffs, that is 1K MACs per output sample, or 200 MMAC/s per channel.

I will use 768 MACs per output sample (to save mults and bram) so using 4 FPGA mults per channel, total 8 for stereo. I don't know if symmetric coeffs will sound better than asymmetric, so I'll allow both.

> I imagined a lot since you mentioned the potential of
> using CUDA. But if you're still using nothing more than
> the FPGA on the digilent board, that's hardly in the
> same ballpark as CUDA.

Certainly a GPU is more powerful but this FPGA can make a gigaMAC/s (with 36 bit x 36 bit => 80 bit accumulator). Not too shabby... and very important, for a miserably low power consumption and without a fan.

> Oversampling along the lines that's built into some
> DAC chips is only a few tens of MMACs so presumably
> is well suited to a Spartan III.

Well what interests me is mostly to use a way-overkill amount of precision and also a custom impulse response. Some people report some digital filters sound much better than others, so there must be good sound waiting to be found !

> Sure, yet CUDA running double precision is a far cry
> from fixed point on a cheap FPGA.

Sure, a GPU with 500 GFlops is 500x more powerful (and noisy unless you get rid of the fan) and is the only way to realize REAL FIR crossover (not FFT). I'm waiting for a fanless double precision GPU, should be available when the next gen comes and GTX is demoted to entry-level.

As for precision, no problem in the FPGA. I put 36 bit coeffs and 80 bit accumulator in the FIR. It's just a few extra slices... I've already paid for all the silicon after all

> My hardware engineering curiosity is piqued though
> as to how something that's successfully implemented
> on an NPC digital filter in late 1980s CMOS technology
> results in serious slowing down of a current-day PC...
> What software were you running?

Well, the digital filters datasheets don't tell you about the accumulator size, the FIR filter size, the quantization errors, how the stuff is rounded, truncated, maybe some shaped dither is applied, etc. You can make a very fast or very slow oversampler depending on all those factors. I suspect cheapness on the digital filters... like using too few bits... or a multistage filter with truncation between each stage...

If you want to do it like like libsamplerate, 48k -> 192k needs 384 MMac/s for stereo. Not a problem for any desktop CPU...

However my Core 2 oversamples 44.1 to 176.4 a little bit faster than realtime. Really slow.

That's because libsamplerate is extremely slow, it is not optimized for integer sample rates (so 4x more work) and CPU cache coherency is extremely bad (coeffs are not stored in a cache friendly way), and it is not multithreaded. So yes the FPGA will beat it...

> I'd prefer the option of doing my own board design at
> a later stage, not relying on continued availability of
> the digilent board.

Problem is big FPGAs are all in BGA 1mm pitch (6 layer 4-4 mil track/space + tiny vias -> one-off board $1K) except the Cyclone III which is available in TQFP (4 layer standard 6-6 mil board -> one-off about $150 / 3 boards at sierra protoexpress). So either Spartan-3E 500 (underpowered for FIR) or Cyclone-III (extremely powerful). It's a can of worms...

> For the prototyping stage, I can't fault your choice
> of that board, it looks superb.

Thanks, I like this board too. I'll probably use it in the final DAC.

[rfbrw]

One can only marvel, slack jawed in awe at the kind of mindset that thinks a Spartan 3E-500 is underpowered.

[peufeu]

LOL, you're right actually, I confused the numbers of mults and brams with the 250E

[greggp]

Originally posted by Eric Juaneda
Hi everyone,

Where could you find FLAC downloads or other high quality audio files?

Linn Record and ...?

Eric

Here's a list:

2L
iTrax.com
HDtracks
HDTT
Magnatune
MusicGiants
The Philadelphia Orchestra Online Music Store

There's probably more out there, but those are the only ones I'm aware of now. The MusicGiants site has the largest selection of popular music, but they use WMA lossless instead of FLAC (no big deal, but some of it is DRM'd). MusicGiants is still worth checking out because a lot of their high res music is DRM free.

[Wavelength]

Peufeu,

Two things... I have been pouring over driver code.

I think your best bet is implement Class 2.0 USB then do the driver that way. I talked to allot of people who say bulk since it has the lowest priority will not stand up to constant 24/192 output. But since ISO is the highest priority then it maybe the best shot.

~~~~~~~

Isolation does have to be at I2S. I built a kinda of header to put I2S isolators between my DAC module and my TAS1020 motherboard.

The real problem is the timing get's all screwed up. If you do this you must take the MCLK and reclock SCLK, WCLK and DATA or the amount of jitter the isolators inject will overcome their resulted improvement by a 2 to 1 factor.

You would also want to play around with termination as the over shoot on some of the signals is killer and will effect any dac chip they are attached to.

Thanks
Gordon

[peufeu]

> You would also want to play around with termination
> as the over shoot on some of the signals is killer

Yes, datasheet says min 1 ns rise time, this is really fast, so I'd expect these chips to be a nuisance wrt radiated noise without source termination...

> The real problem is the timing get's all screwed up.

Max skew is 4-6 ns that's kinda large too... Thanks for making me have a second look at the datasheet. I'll have to be careful on the timings. Since the clock is on the dac side, the roundtrip delay clock -> iso -> fpga -> i2s -> iso -> dac could be more than one clock period !... a good occasion to try xilinx DCM clock phase adjustment feature it seems.

> If you do this you must take the MCLK and reclock SCLK, WCLK and DATA or
> the amount of jitter the isolators inject will overcome their resulted
> improvement by a 2 to 1 factor.

Which side of the isolator is your clock ?
So from what you say, even if a reclocker is not supposed to be useful on delta-sigma dacs, if there is some overshoot, the reclocker will eat it instead of the DAC, which is good, right ?

[wakibaki]

Originally posted by peufeu
You could have asked instead of being insulting.

Generally I tailor the level of insult to the degree of the injury.

If you don't want to be taken for a snob, then next time don't lard your posts with asides about the resolution at which you intend to digitize your vinyl. Try to imagine how little I care.

If you really wanna do something useful build a well-documented open-source battery-driven reference source running from a generic CF or SD card with a TCXO clock. A super-lo-noise-lo-jitter uncompressed linear PCM iPod. Record the tracks from the PC to the card and transfer to the player by sneakernet. This could acually settle (or obviate) a lot of arguments.

Instead you're pandering to the worst greedy instincts of the more-mips, more-power, more-money, more-complicated paranoid techno-junkies. Virtually the whole of your last post is just a catalogue of excess. What do you think you are? A director of GM or Chrysler? Just got out of your G IV? Those kind of attitudes have got quite a lot less popular with most of us recently...

All you're doing here is whipping up a load of techno-froth, and bringing out every worm in the woodwork. Don't you know you can always find uncritical support out there on the web for ANY hare-brained scheme? 18 months down the road these same or other similar 'enthusiasts' will have found something to b1tch about in USB2, regardless.

DACs, like amplifiers, just aren't that interesting anyway, except to a bunch of flakes who imagine that audio reproduction can carry on getting better and better ad infinitum.

At the very least your scheme will involve you in a lot of work that will be replicated in a COTS device in a few months anyway. If it isn't then it won't be worth doing. Why not take a step back, calm down, and try to get things in perspective.

w

[abraxalito]

No probs with your remarks about isolation. Just don't think that optos are the only way to do isolation - consider a pulse-transformer for isolating the clock for example. Optos are only essential for signals with DC components but their relatively slack timings and pulse distortion make designs more difficult.

>> My other misunderstanding was the amount of
>> processing you were contemplating

>Depends on what you want to do. I want to try oversampling
>filters, so I looked at a known-good one which is libsamplerate
>(Secret Rabbit Code). When working at 4x (48->192) it uses 4k
>coeffs, that is 1K MACs per output sample, or 200 MMAC/s per
>channel.

This SRC is a 'known good' oversampling filter? That's news to me hehe. Firstly its massively inefficient at doing something with a straightforward integer ratio (as it looks designed to handle variable sample rates and non-integer ratios) and secondly it claims its 'best' implementation gives -97dB SNR. That's just 16bit performance - ok to be sending to your TDA1545 but nothing more recent. There's no need at all to be basing a fixed ratio, fixed frequency oversampler on this example.

>Certainly a GPU is more powerful but this FPGA can make a
>gigaMAC/s (with 36 bit x 36 bit => 80 bit accumulator). Not too
>shabby... and very important, for a miserably low power
>consumption and without a fan.

I agree, its not at all shabby and probably even massive overkill. But that's cool - its already on the board!

>> Oversampling along the lines that's built into some
>> DAC chips is only a few tens of MMACs so presumably
>> is well suited to a Spartan III.

>Well what interests me is mostly to use a way-overkill amount of
>precision and also a custom impulse response. Some people
>report some digital filters sound much better than others, so
>there must be good sound waiting to be found !

Yep, yep. I'm equally curious as to the audibility of digital filters. I heard one anecdotal story from a famous designer in a well-known hifi company in UK that said he was able to hear a difference down at the 24th bit in a DSP...

>> Sure, yet CUDA running double precision is a far cry
>> from fixed point on a cheap FPGA.

>Sure, a GPU with 500 GFlops is 500x more powerful (and noisy
>unless you get rid of the fan) and is the only way to realize REAL
>FIR crossover (not FFT).

I don't follow you. I agree that FFT approaches aren't so well suited to audio but why is 500GFlops needed for real FIR? Are you planning to do room correction and noise cancellation on 64channels?

>> My hardware engineering curiosity is piqued though
>> as to how something that's successfully implemented
>> on an NPC digital filter in late 1980s CMOS technology
>> results in serious slowing down of a current-day PC...
>> What software were you running?

>Well, the digital filters datasheets don't tell you about the
>accumulator size, the FIR filter size, the quantization errors, how
>the stuff is rounded, truncated, maybe some shaped dither is
>applied, etc.

I guess we don't read the same datasheets then. Since NPC was my first introduction to IC digital filters, I skipped over to their site and pulled off the DS for the NPC5847AF. This gives enough details to answer many questions about how they implemented it.

First, they adopt a multi-rate structure, they don't try to upsample in one go. This allows a worthwhile saving in complexity. For the 4X output, there are two filters in series, the first is 169 taps (running at 2fs) and the second is 29 taps (at 4fs). The coefficients look to be 26bits and the accumulator is 32bits. They do apply TPF dither but this is switchable.

Assuming that the filters do have symmetrical coeffs, then the computational complement of the oversampler in this chip is of the order of 20MMACs.

>If you want to do it like like libsamplerate, 48k -> 192k needs 384
>MMac/s for stereo. Not a problem for any desktop CPU...

Doing this comparison (20 vs 384) shows just how crazy a solution libsamplerate is for this particular application!

>However my Core 2 oversamples 44.1 to 176.4 a little bit faster
>than realtime. Really slow.

>That's because libsamplerate is extremely slow, it is not
>optimized for integer sample rates (so 4x more work) and CPU
>cache coherency is extremely bad (coeffs are not stored in a
>cache friendly way), and it is not multithreaded. So yes the FPGA
>will beat it...

But if a solution specific to this application were implemented, then even my $15 Sempron 1.9GHz would do a sterling job of this oversampling task.

>> I'd prefer the option of doing my own board design at
>> a later stage, not relying on continued availability of
>> the digilent board.

>Problem is big FPGAs are all in BGA 1mm pitch

I see that the Spartan 3E500 is available in upto 144 pins before it goes into BGA. So let's keep the number of IOs down!

R

[jcarr]

Originally posted by wakibaki

If you really wanna do something useful build a well-documented open-source battery-driven reference source running from a generic CF or SD card with a TCXO clock. A super-lo-noise-lo-jitter uncompressed linear PCM iPod. Record the tracks from the PC to the card and transfer to the player by sneakernet.
w

FWIW, no need to roll your own to accomplish this. You can use a solid-state memory recorder from the likes of Edirol, Marantz, Fostex, Teac and others. Some of these are equipped with digital output as well as analog, so you can use a separate DAC. I have been using a variety of such devices for maybe 5 years now, and they work quite well. A device like the Edirol R-1 or R-9 should be available for perhaps 400 dollars, but the price of entry has dropped significantly recently. The Western Digital WD TV (which will work with USB thumbdrives) will also allow you to accomplish such, and you can buy it for around 100 dollars US.

>This could acually settle (or obviate) a lot of arguments.<

Like how well a DAC is designed. If the given DAC shows a change in sound with a solid-state drive as opposed to a PC or optical-mechanical transport, I regard the design of the DAC as being lacking.

regards and hth, jonathan carr

[Wavelength]

Originally posted by peufeu
Which side of the isolator is your clock ?
So from what you say, even if a reclocker is not supposed to be useful on delta-sigma dacs, if there is some overshoot, the reclocker will eat it instead of the DAC, which is good, right ? [/B]

Peufeu,

I used this on my Numerator DAC module. This has the MCLK with regulation on the board. The MCLK goes to the Wolfson dac which then divides this by 2 and sends it too the TAS1020B MCLKin. The TAS1020 then generates the SCLK, WCLK and clocks out the data via this signal.

So I basically isolated the MCLK/2 into the TAS1020, SCLK and DATA with higher speed and WCLK with a lower speed. I was told this was the best way too do this.

The jitter was allot higher at that point. So I added reclockers to SCLK, DATA and WCLK and things got better.

Transformers work really well for the high speed stuff but for WCLK it does not do such a good job.

But the big deal was no so big a deal. The isolation really did not do anything to the sound.

I think one of the big things is if you don't pull any current from VBUS then there is no current through VGND and therefore allot of the computer noise does not come nearly as much.

I did not try allot of computers for this it was my typical setup. superMini OSX 10.5.5

Thanks
Gordon