Pc -> Dac, How ?

[tritosine]

look i just found these pages googling for iso150:


http://www.metzgerralf.de/elekt/dac.shtml
...
http://tinyurl.com/mpxfnc

i doubt it makes much sense using df1704 after that asrc, instead of running the SRC at 192 - 210 khz without DF afterwards. Maybe he is fond of first order filters after the DA , but I don think theres much difference between 210khz with 3rd order low pass , or maximum oversampling using df1704 with mere 6dB/oct...

[daneman]

thanks again.
i guess i don´t have to worry about this design. i´ll use the sabre32-chip. -all integrated.
sorry, this is off-topic: i think about using (softwarebased) external upsampling to 192khz instead of internal oversampling.
have an opinion to this issue? - (microcontroller needed to diasable oversampling, otherwise it would be easy to test..)

http://www.esstech.com/PDF/Sabre32%2...F%20081217.pdf

[tritosine]

you can alter sabre32 coefficients with uC and I think the 512 tap builtin upsampler is just fine , you rarely need more , eg. if you want stopband at low frequencies like the hinted digital crossover usage, that wont cut it . For simple anti aliasing role ( ~ 20khz cutoff with 44.1 khz material ) 32bit 512 taps are plenty and so far unheard of in an IC ? Im afraid there s not much to do with external upsampler in this design as its already cutting edge, btw there was that talk somewhere about this extra ordinary 1.5 mhz upsampled input with bypassed internal DF , and Im missing the point entirely, I wouldnt get into the 'bigger specs the better' game either , it makes no sense optimising for numbers at 0... -10 dB and -80dB ... -96dB range with CD material as there isnt much useful data to begin with... OFC these numbers come handy if you have no nice analog volume attenuator and you have to resort to digital bit shifting thats apparently better than your usual potmeter?

[daneman]

thanks for your hints, tritosine

i´ll post my results after i´ve proven all these options.

rg
daniel

[abraxalito]

Any news of progress on this peufeu?

Another possible route for this has emerged - I've been following XMOS for a while - they've just released (at least on their website) a board which might allow punters to get going with async mode USB at 24bits/192kHz. I'm going to try to get hold of one and have a play... Hope I don't have to buy a Mac though to get USB audio 2.0 drivers.

For those interested, the link is here

[Telstar]

Since nobody seems able to write firewire audio drivers for windows nor linux, usb 3.0 is our only hope.

I'm still very skeptical about jitter quality and real multichannel capability (at 24/192) of usb 2.0.

[anbello]

I think the XMOS solution could be a really good one, jitter wise it's good because they use asynchronous mode with two xtal (i think one for 44.1K based frequencies and one for 48K based ones).
USB 2.0 it's specified for 480Mb/s but it's known to have a sustained rate of 200 - 220 Mb/s, plenty of bandwith for 192K stereo channel (9Mb/s).
The other good thing in this solution is that (learning their free development system) it's possible to put in audio DSP algorithm (DRC, digital xover, ...).
I only hope to see USB audio 2.0 driver for Linux.

Ciao
Andrea

[Telstar]

Originally Posted by anbello

I think the XMOS solution could be a really good one, jitter wise it's good because they use asynchronous mode with two xtal (i think one for 44.1K based frequencies and one for 48K based ones).

It puzzled me why the clock(s) was in the usb receiver... so how would you design a serious DAC with a master clock CLOSE to the dac (where it shoudl be)?

USB 2.0 it's specified for 480Mb/s but it's known to have a sustained rate of 200 - 220 Mb/s

Which is about 30MB/s in the real world.

plenty of bandwith for 192K stereo channel (9Mb/s).

Fine for 2, maybe 4 channels. But I said multichannel. Do you think it can sustain 8x 24/192k channels?
I'm afraid not. But the latest RME device uses usb 2 as well.

Anyway, proprietary drivers for windows (and linux) are needed, but maybe they are easier to implemnt.

The other good thing in this solution is that (learning their free development system) it's possible to put in audio DSP algorithm (DRC, digital xover, ...).
I only hope to see USB audio 2.0 driver for Linux.

You mean software-based not an IC, right? I didnt read all the papers.

[abraxalito]

Yes, its all software based - that's one of the strengths of their approach (at least on paper). Also fairly scalable - that reference design uses the single core version of their processor. They have 4-core versions which would allow some fairly serious audio crunching to go on, as each core is 400MIPS with a single cycle 32*32 MAC. The I/O is handled in software too which allows for playing around with RTZ transmission schemes to the DAC (just a crazy thought...).

[anbello]

Originally Posted by Telstar

It puzzled me why the clock(s) was in the usb receiver... so how would you design a serious DAC with a master clock CLOSE to the dac (where it shoudl be)?

i2s and spdif out are reclocked by "Audio Master Clock Oscillator 24.576MHz and 11.2896MHz" so you can substitute these MCLKs with better ones and put it on the DAC (feeding the XMOS board with the same MCLKS)

Which is about 30MB/s in the real world.

it's better to think in terms of Mb/s (i think)

Fine for 2, maybe 4 channels. But I said multichannel. Do you think it can sustain 8x 24/192k channels?
I'm afraid not. But the latest RME device uses usb 2 as well.

USB audio class 2.0 is capable of 8 x 24/192K channels

Anyway, proprietary drivers for windows (and linux) are needed, but maybe they are easier to implemnt.

When USB audio class 2.0 drivers will be available for all OS you can use these kind of device without proprietary drivers as now we use TI pcm200x with USB audio class 1.0 drivers (supplied by the OS - not proprietary)

You mean software-based not an IC, right? I didnt read all the papers.

The "brain" of these XMOS boards is something halfway a SW programmable DSP and a programmable logic (like an FPGA)
XCore | XMOS
and tehy have a free design tool
https://www.xmos.com/technology/design-tools

Ciao
Andrea