Pc -> Dac, How ?

Status
This old topic is closed. If you want to reopen this topic, contact a moderator using the "Report Post" button.
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...
 
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 DAC PF 081217.pdf
 
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?
 
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
 
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
 
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.
 
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...).
 
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
 
This XMOS thing is great news! We could now more easily develop audio interconnection. The remaining thing would be to develop a low latency audio network for pro uses (it has Ethernet, Audiorail skipped the MAC and TDM audio data... Straightforward, cheap, works...).
When I see the code for an i2s receiver (given as sample code), I can't stop thinking: just setting the registers of a TC Dice or stuff like that is more complicated.

Plus you can do anything you want with that thing!!!!
 
<snip> I like this thingy :)

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

I hold my opinion until i hear how they sound, compared to firewire. The real bandwith is a little lower in usb 2.0 (theoretically higher), but in practice the sharing common to all usb devices can cause issues for critical tasks as realtime audio. In the worst case a dedicated pc is using at least another usb device (mouse or keyboard), usually two or three (VFD, IR).

When USB audio class 2.0 drivers will be available for all OS you can use these kind of device without proprietary drivers

Do you know when that'll be? I have Windows7, but I dont think it supports usb 2.0 audio yet. Maybe even linux will move sooner.
 
I hold my opinion until i hear how they sound, compared to firewire. The real bandwith is a little lower in usb 2.0 (theoretically higher), but in practice the sharing common to all usb devices can cause issues for critical tasks as realtime audio. In the worst case a dedicated pc is using at least another usb device (mouse or keyboard), usually two or three (VFD, IR).
FYI, I am encountering no issues with my EeePC (1.6 Gig Atom CPU) running XP-Home, over USB 2.0 with my Musiland USB converter. Also connected are an USB mouse and USB IRC. Even playing a CD from a hooked up external Plextor USB DVD drive performs flawless. But ok, playing a CD doesn’t take the USB to its limits.
 
FYI, I am encountering no issues with my EeePC (1.6 Gig Atom CPU) running XP-Home, over USB 2.0 with my Musiland USB converter. Also connected are an USB mouse and USB IRC. Even playing a CD from a hooked up external Plextor USB DVD drive performs flawless. But ok, playing a CD doesn’t take the USB to its limits.

Good to know :)
But you are not using 8 channels with ASIO, which are for me requirements for my crossover. I think some proprietary (or good opensource) asio drivers are needed, I dont consider asio4all up to the task.
 
I hold my opinion until i hear how they sound, compared to firewire. The real bandwith is a little lower in usb 2.0 (theoretically higher), but in practice the sharing common to all usb devices can cause issues for critical tasks as realtime audio. In the worst case a dedicated pc is using at least another usb device (mouse or keyboard), usually two or three (VFD, IR).
I'am not an USB expert but on ICH8 datasheet (an example of what you could have as I/O controller Hub on your PC) i read:

"The ICH8 contains five USB full/low-speed host controllers that support the standard Universal Host Controller Interface (UHCI), Revision 1.1"

"The ICH8 contains two Enhanced Host Controller Interface (EHCI) host controllers which support up to ten USB 2.0 high-speed root ports. USB 2.0 allows data transfers up to 480 Mb/s using the same pins as the ten USB full-speed/low-speed ports. The ICH8 contains port-routing logic that determines whether a USB port is controlled by one of the UHCI controllers or by one of the EHCI controllers"

I Think this implies that if you have up to 2 high-speed devices and 5 full/low-speed devices there is no sharing of bandwidth and each devices talk to his UHCI or EHCI.

Example:
1 USB audio 2.0 device <--> EHCI1
2 USB 2.0 external HD <--> EHCI2
3 USB 1.1 mouse <--> UHCI1
3 USB 1.1 [other device] <--> UHCI2
...
Do you know when that'll be? I have Windows7, but I dont think it supports usb 2.0 audio yet. Maybe even linux will move sooner.
I don't know when but i think that if there will be enough device of this kind microsoft will develop the driver and so will do some linux developers (i hope so)

Ciao
Andrea
 
That xmos USB2 kit does look very interesting. More of a general purpose cpu environment rather than an FPGA which might make it a bit more accessable. If the price on the USB2 kit is low enough, it definitely seems to be worth a look. Maybe time to research the status of USB2 audio drivers in Linux.
 
Status
This old topic is closed. If you want to reopen this topic, contact a moderator using the "Report Post" button.