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.
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.
One can only marvel, slack jawed in awe at the kind of mindset that thinks a Spartan 3E-500 is underpowered.
Re: Where to find FLAC files
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.
Eric Juaneda said:
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.
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
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
> 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 ?
> 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 ?
peufeu said:
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
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
>> 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
wakibaki said:
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
peufeu said:
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
I've been meaning to respond to this for a while, but with holidays and travel, haven't been able to. There are two separate pieces to this.
First, "what's the point?" For those saying "use an existing soundcard" or expressing similar ideas, I think there are two aspects that are missing:
1) multichannel. I'm not aware of any multichannel solution that uses a "good" clock architecture. No doubt some PCI/e cards probably use good design, but run into the problem of the PC power delivery system. I use an Emu 1820M which is pretty much state of the art in terms of 'affordable' multichannel rigs and yet it still uses noisy PC power for the clock etc. (although at least the DAC's can be separately powered)
2) Linux. This may be a secondary desire for peufeu, but it still seems important. There is a real dearth of good USB solutions that work under Linux. The Transit more or less works, and the 0404 USB can be cajoled into working at 16 bit, but it's a bit dicey. *IF* linux support is a goal, then IMHO rolling something from the ground up like peufeu is proposing isn't necessarily a bad approach.
Certainly, for many folks that just want a 2-channel solution under Windows, there may be easier/quicker ways to get there via a modified commercial card and/or by slaving via spdif. For multichannel it's probably not that easy.
The second aspect of this is really "should we care?". By that I mean is this actually going to be a group participation project in any meaningful sense, or is this simply going to be a showcase for peufeu's private system? I admit I have some concerns along these lines, as peufeu seems ready to charge down the path of FIR xovers and digital filters before there is really a solid playback approach in place. If this is going to be more than a one-off, the barrier to entry for interested participants/contributers has to be kept reasonably low, and it has to do something they're interested in. This means several things, I think:
- hardware resources. Boards or at least easily reproduced layouts for the isolation module, the clock/reclock module etc. Also good parts lists from common vendors to make ordering connectors, clocks, chips etc straightforward. Without this, everyone will have to do their own custom work, which means there really is very little underlying commonality.
- software. It needs to be relatively easy to configure the board to do what folks want (specifically 2-channel unfiltered playback has to be easy) If they don't want FIR/digital filters, they shouldn't have to hack verilog to get rid of it. Similarly, playback from the host shouldn't require an advanced degree to get working, and should if possible work with garden-variety distros (at least at first - I actually think a custom thumb-drive distro down the road might make sense).
- compatibility (to a degree). The TP guys have a fair number of I2S compatible modules out there, and I suspect a lot of folks that might be interested in this USB project would use the TP boards as a starting point. This of course shouldn't be a problem, but stranger things have happened.
Obviously, not all of this falls on the shoulders of one person, but without some organization of this type, this may never be more than a curiosoty for most people.
IMHO starting *really* *really* simple and getting folks on-board would be the best way to build a community of users, but unfortunately that is also likely to be the most boring for peufeu. Getting half-a-dozen folks all running a command-line user-space playback chain on common hardware would probably be enough to start generating some momentum, but that might mean defering the more advanced aspects for a while.
Since I'm a Linux guy and multichannel is embedded at the core of what I'm trying to do with my system, I'm very interested in this project. I'd be quite interested in being an early adopter if the situation is right.
First, "what's the point?" For those saying "use an existing soundcard" or expressing similar ideas, I think there are two aspects that are missing:
1) multichannel. I'm not aware of any multichannel solution that uses a "good" clock architecture. No doubt some PCI/e cards probably use good design, but run into the problem of the PC power delivery system. I use an Emu 1820M which is pretty much state of the art in terms of 'affordable' multichannel rigs and yet it still uses noisy PC power for the clock etc. (although at least the DAC's can be separately powered)
2) Linux. This may be a secondary desire for peufeu, but it still seems important. There is a real dearth of good USB solutions that work under Linux. The Transit more or less works, and the 0404 USB can be cajoled into working at 16 bit, but it's a bit dicey. *IF* linux support is a goal, then IMHO rolling something from the ground up like peufeu is proposing isn't necessarily a bad approach.
Certainly, for many folks that just want a 2-channel solution under Windows, there may be easier/quicker ways to get there via a modified commercial card and/or by slaving via spdif. For multichannel it's probably not that easy.
The second aspect of this is really "should we care?". By that I mean is this actually going to be a group participation project in any meaningful sense, or is this simply going to be a showcase for peufeu's private system? I admit I have some concerns along these lines, as peufeu seems ready to charge down the path of FIR xovers and digital filters before there is really a solid playback approach in place. If this is going to be more than a one-off, the barrier to entry for interested participants/contributers has to be kept reasonably low, and it has to do something they're interested in. This means several things, I think:
- hardware resources. Boards or at least easily reproduced layouts for the isolation module, the clock/reclock module etc. Also good parts lists from common vendors to make ordering connectors, clocks, chips etc straightforward. Without this, everyone will have to do their own custom work, which means there really is very little underlying commonality.
- software. It needs to be relatively easy to configure the board to do what folks want (specifically 2-channel unfiltered playback has to be easy) If they don't want FIR/digital filters, they shouldn't have to hack verilog to get rid of it. Similarly, playback from the host shouldn't require an advanced degree to get working, and should if possible work with garden-variety distros (at least at first - I actually think a custom thumb-drive distro down the road might make sense).
- compatibility (to a degree). The TP guys have a fair number of I2S compatible modules out there, and I suspect a lot of folks that might be interested in this USB project would use the TP boards as a starting point. This of course shouldn't be a problem, but stranger things have happened.
Obviously, not all of this falls on the shoulders of one person, but without some organization of this type, this may never be more than a curiosoty for most people.
IMHO starting *really* *really* simple and getting folks on-board would be the best way to build a community of users, but unfortunately that is also likely to be the most boring for peufeu. Getting half-a-dozen folks all running a command-line user-space playback chain on common hardware would probably be enough to start generating some momentum, but that might mean defering the more advanced aspects for a while.
Since I'm a Linux guy and multichannel is embedded at the core of what I'm trying to do with my system, I'm very interested in this project. I'd be quite interested in being an early adopter if the situation is right.
dwk123,
Not wishing to anticipate Peufeu's reply but:
- this isn't a showcase for Peufeu's home system - far from it - it is a truly open source/hardware system that is intended to act as a platform for open experimenting on various DAC modules/ PS modules, etc and by given a standard platform to operate from can bring the DIY community closer to being able to really evaluate different DAC, filtering schemes, etc without all the variables that so often hamper doing this in any scientific way - so I think "we should care" in seeing this fully materialise. I believe Peufeu stated why he was started this thread
- This project is already more developed than you seem to believe with a lot of research gone into selecting the most suitable FGPA board, currently the NEXYS2. This is communicating with PC via bulk USB.
Have to go!
Not wishing to anticipate Peufeu's reply but:
- this isn't a showcase for Peufeu's home system - far from it - it is a truly open source/hardware system that is intended to act as a platform for open experimenting on various DAC modules/ PS modules, etc and by given a standard platform to operate from can bring the DIY community closer to being able to really evaluate different DAC, filtering schemes, etc without all the variables that so often hamper doing this in any scientific way - so I think "we should care" in seeing this fully materialise. I believe Peufeu stated why he was started this thread
- This project is already more developed than you seem to believe with a lot of research gone into selecting the most suitable FGPA board, currently the NEXYS2. This is communicating with PC via bulk USB.
Have to go!
jkeny said:
I think you misunderstand the point of my post. I agree that "we should care" about the basic idea of what peufeu is doing. My point is that a project will have to be approached rather differently if the goal is to build a wide user base than it would if the goal is simply to get one or two systems working doing cool stuff. So far, there is every reason to believe that peufeu will get a system up and running, but I'm not sure about all of the "other stuff" needed to make something that is usable by a larger audience. The goal of my post is to get some discussion going surrounding this type of issue.
As an example, if the only way you can use peufeu's fpga code is to roll-your-own reclocking circuit and hack the verilog to disable direct digital filtering, then 'few' other folks are likely to bother with the project. On the other hand, if someone is offering boards for the reclocker and there is a quick/easy order basket for it, then it's far more approachable. It's not reasonable for peufeu to do all this himself, but since he's providing the impetus for the project he will have to provide the primary support/organization for it.
I think I'm pretty well aware of the state of the project, as I've been following this since the Ethernet version a year or two back. I actually almost ordered a board from digilent before xmas, but figured holding off until things were a bit more clear might be wise.
dwk123:
I pretty much agree with all of what you've said - I'm also in this to make it more 'accessible' to the average punter than having to hack verilog and figure out how to attach 1mm pitch BGAs to boards...
I don't though agree that peufeu needs to provide the impetus to make this available to a wider audience - he's clearly motivated by getting something working, the day to day work of preparing parts lists and checking out availability is probably not going to appeal. I figure there are probably enough of the rest of us here to work out those aspects. We'll just have to drive peufeu to get the answers we need.
R
I pretty much agree with all of what you've said - I'm also in this to make it more 'accessible' to the average punter than having to hack verilog and figure out how to attach 1mm pitch BGAs to boards...
I don't though agree that peufeu needs to provide the impetus to make this available to a wider audience - he's clearly motivated by getting something working, the day to day work of preparing parts lists and checking out availability is probably not going to appeal. I figure there are probably enough of the rest of us here to work out those aspects. We'll just have to drive peufeu to get the answers we need.
R
Gang,
Basically if we go with the Cypress USB 2.0 controller, it would require some kind of FPGA to have complement I2S outputs. The flow is simple and would work pretty much like this:
USB2.0<===>Cypress[DATA]->FPGA---->I2S--->DAC(s).
The MCLK at the DAC would be fed into the FPGA and that would determine the rate and so forth. The Cypress would receive Endpoint 0 setup information as to the changes in the Fs rate and output those via GPIO ports. The GPIO output would go to the FPGA and also aid in the selection of MCLK's to support various Fs rates (i.e. 44.1, 48, 88.2, 96, 176.4, 192).
The only really other alternative to the Cypress would be the new Atmel AVR32 parts which should be released soon. It does have both USB 2.0 and PHY and DMA SSC port that is capable of 24/192. I am under NDA and can't really say anything more on that till it is released.
What??? Buy a lynx card and do some software buddy. There is a ton of FFT on the web, learn it understand it write it. Or buy something like the Dr. Jordan stuff.
But really you will never come close to what the Prism has. The SN ratio on that ADC is incredible.
Thanks
Gordon
Basically if we go with the Cypress USB 2.0 controller, it would require some kind of FPGA to have complement I2S outputs. The flow is simple and would work pretty much like this:
USB2.0<===>Cypress[DATA]->FPGA---->I2S--->DAC(s).
The MCLK at the DAC would be fed into the FPGA and that would determine the rate and so forth. The Cypress would receive Endpoint 0 setup information as to the changes in the Fs rate and output those via GPIO ports. The GPIO output would go to the FPGA and also aid in the selection of MCLK's to support various Fs rates (i.e. 44.1, 48, 88.2, 96, 176.4, 192).
The only really other alternative to the Cypress would be the new Atmel AVR32 parts which should be released soon. It does have both USB 2.0 and PHY and DMA SSC port that is capable of 24/192. I am under NDA and can't really say anything more on that till it is released.
What??? Buy a lynx card and do some software buddy. There is a ton of FFT on the web, learn it understand it write it. Or buy something like the Dr. Jordan stuff.
But really you will never come close to what the Prism has. The SN ratio on that ADC is incredible.
Thanks
Gordon
Wavelength said:
i do have a lynx card but no adc to feed its digital ins, thanks to some hack who talked EVERYONE into buying that pcm4222 evkit with his clever marketing strategy , making it sorta out of stock
oh & what do i see in the AP1 service manual are these digitally controlled analog generators and notch filter,and since AP made this available for everyone these are sorta out in the wilderness now . Happy NY gang
Has anybody looked at this product?
http://beagleboard.org/hardware
It seems to be a mini computer that could be used for a PC and spits out I2S directly. This could then be fed to a DAC chip easily.
http://beagleboard.org/hardware
It seems to be a mini computer that could be used for a PC and spits out I2S directly. This could then be fed to a DAC chip easily.
davidallancole said:
Yes, I have used it.
I have it decoding flac (from SD card) out to I2S. Even at 192/24. I have not tried to use for USB yet.
This is actually very easy to do since it runs Linux.
Cheers!
Russ
Hi Russ,
Which DACs have you ran with this beagleboard?
It seems like a clean solution because a lot of DACs I have seen have I2S inputs and generally need USB or SPDIF converter chips in front of them.
Which DACs have you ran with this beagleboard?
It seems like a clean solution because a lot of DACs I have seen have I2S inputs and generally need USB or SPDIF converter chips in front of them.
- Status
- Not open for further replies.