Pc -> Dac, How ?

[Wavelength]

Gang,

I agree, Firewire is dead... Apple introduced it and they are taking it away. The problem is they moved too slowly and they lost.

Peufeu forgot too mention that USB requires 2.0 as high speed would be required for 24/192. OSX is the only OS supporting Audio Class 2.0 drivers. Windows and Linux do not support them.

Though EMU has posted it's source code for the 0202/0404 for OSX up on sourceforge and this code could easily be adapted for linux since OSX is really a unix based system.

Or you could do a Bulk Mode USB DAC.

Thanks
Gordon

[schro20]

Originally posted by peufeu
Ethernet.
Someone posted the Ethernut link... OK, it's nice. Is it better and/or cheaper than a $50 intel atom mini-itx board ? No, and no. OK, you could use it for stereo 44.1k...

Point taken.

The other thing that worries me in general is the overall software. One of the reasons I like my current setup (MaxtorII with FireflyMediaServer running on it talking to my ethernet having Rokus in different rooms talking to good outboard DACs) is the software. Browsing, the database management, playlists, etc. etc. Plus I like the fact that I don't have to have a computer running all the time (meaning: no keyboard, no monitor, and certainly not huge electricity suck; though this is changing). Just a web interface for occasional maintenance (low at that!). Each device does only one thing and does it really well. (I know, the Roku will only do 44.1kHz, so I gotta find something better.) Just having all the programming to run a decent VFD display like they have on the Roku... Yeay, it's doable, but who will do it at a professional level?

That would be some of my concerns regarding a device that fits what I am looking for. (Different folks want different strokes.)

peter

[rfbrw]

Originally posted by peufeu
Let's stop polluting the ESS thread, shall we ?

OK so :

- CD is dead
- DVD is dead
- SACD is dead
- Physical formats are dead anyway

Yes and I work in a paperless office and commute in a flying car.
Dude, stop blowing smoke up our collective jacksie with the illusion of choice. You've obviously made your choice so get on with it.

[Pjotr]

Originally posted by Wavelength

Peufeu forgot too mention that USB requires 2.0 as high speed would be required for 24/192. OSX is the only OS supporting Audio Class 2.0 drivers.

True, but as far as I understand only up to 24/96 on a MAC.

Though EMU has posted it's source code for the 0202/0404 for OSX up on sourceforge and this code could easily be adapted for linux since OSX is really a unix based system.

And that is what I use with ASIO drivers, driven by J.Rivers Media Centre on a Eee PC. For 99 bucks for an E-MU 0202, I wouldn’t go through the hassle of making it myself.

Cheers

[philpoole]

Damn, I didn't want to get involved...

ST appears to be a single channel, so it either has several carriers for the individual channels required (at least clock, data, ws) which would need to be demodulated, or it is multiplexed digital data which is probably self clocking, which will need demultiplexing.
Either scenario can't be ideal and will introduce jitter, unlike I2S.

I think you'd be better off using I2S over RS423 or LVDS.

[wakibaki]

Originally posted by peufeu

Right whaddawegot here.

A DAC. And a clock. Wired or? Taking the result thru an inverter, a resistor (and something that looks like it might be the PSTN) and feeding it to a PC. Wut?

Not only do we got textual drivel, we got graphical drivel too.

You MIGHT have something useful or interesting to say, but you're doing a pretty good job of hiding it.

w

Yep...

[Telstar]

Originally posted by philpoole
Damn, I didn't want to get involved...

ST appears to be a single channel, so it either has several carriers for the individual channels required (at least clock, data, ws) which would need to be demodulated, or it is multiplexed digital data which is probably self clocking, which will need demultiplexing.
Either scenario can't be ideal and will introduce jitter, unlike I2S.

I think you'd be better off using I2S over RS423 or LVDS.

audio synthesis used two ST channels:
http://www.audiosynthesis.co.uk/dax_discrete5.htm

Anyway, i dont think i2s is a bad interface, if implemented well.

[Cauhtemoc]

Originally posted by Telstar
It's a glass optical standard introduced long ago by AT&T and used on a few transports-dacs combo in the past (i.e. audio synthesis dax, muse) and IMO still unsurpassed.

While it is better than optical SPDIF, ST glass is still optical. I will not go into details, but any optical method of transmission will have more jitter than a pure electrical one.

[marziom]

some things like that?

[peufeu]

Originally posted by dw8083
The thinking is to leverage a Blackfin running ucLinux, which is already supported, to connect to ethernet and process and decode the packets onto the I2S outputs.
-David

Sharc & Blackfin are excellent products. Blackfin is a bit underpowered for audio though (if you want high precision, it gets slow). However it will be powerful enough for what you want to do. You could run Linux on it, and simply install net-jack, to make a remote soundcard. I considered this, it is an elegant solution, but in the end I preferred USB, because adding a $50 Atom mini-PC will turn it into an Ethernet DAC (with a big LCD to display Amarok...)

Originally posted by tritosine
Peufeu , exactly why an ASRC is considered bad? Esp, since the best measuring audio dac ever has it right inside the package.

ASRC... why would you use it when you can get rid of jitter by slaving the source ?... Basically the way the ESS Sabre does it is good (ASRC while oversampling massively), but the way the standard ASRC chips do it, between two closely related frequencies, is extremely complex, too complex for a cheap chip like this... which is why they sound better when using some unrelated clocks. Better no ASRC at all.

Originally posted by Russ White
I have often wondered why one could not simply utilize existing I/O on a little Atom (some similar cpu) mobo to spit out I2S.

Actually, yeah. Do we have mobos with some 24-192 signals ? Probably not I²S though, not a problem, solder a few wires, add isolators and FPGA to convert format, add master clock... doable with a $50 FPGA board from Digilent and a bunch of wires... IF THE THING HAS A CLOCK INPUT. Who wants to check this ?

Originally posted by Wavelength
Gang,

I agree, Firewire is dead... Apple introduced it and they are taking it away. (...)

Peufeu forgot too mention that USB requires 2.0 as high speed would be required for 24/192. OSX is the only OS supporting Audio Class 2.0 drivers. Windows and Linux do not support them.

Yeah, Apple... They are good, but sometimes... argh.

Anyway yes, USB 2.0. The FX2LP chip maxes out the USB 2 bandwidth (tested : 45 MB/s) provided whatever you put after it is fast enough.

There is USB Audio Device Class V2 which is a driver model that allows clock-in-dac schemes, which is what I need. Unfortunately it is a bit early (Mac only as you say). So, when it's ready, I'll probably update the firmware in my chip to make it look like a standard device (but clock master). In the meantime, a custom bulk driver should be good. Those are not mutually exclusive btw.

Originally posted by schro20
The other thing that worries me in general is the overall software.

Exactly, I don't like recreating stuff that already exists... a SILENT small PC with Amarok and a 15" LCD beats any 3" LCD for the user-friendliness, and it can also play movies and run BruteFIR...

Originally posted by rfbrw
Yes and I work in a paperless office and commute in a flying car. Dude, stop blowing smoke up our collective jacksie with the illusion of choice. You've obviously made your choice so get on with it.

Ah, rfbrw, always so cheerful no topic would be complete without your snide remarks.

Look at CD sales, look at SACD sales, look at pirate downloads, it is not the audiophiles that are making the market, it is the mass, and the mass wants MP3 without DRM to play on their cellphones, and the mass wants playlists and reasonable sound quality on their super plastic (TM) home theater. Fortunately I see emerging labels which start to offer FLAC @ 24-96 or 24-192 for a reasonable price... this is the future !

Originally posted by wakibaki


Right whaddawegot here.

A DAC. And a clock. Wired or? Taking the result thru an inverter, a resistor (and something that looks like it might be the PSTN) and feeding it to a PC. Wut?

Not only do we got textual drivel, we got graphical drivel too.

You MIGHT have something useful or interesting to say, but you're doing a pretty good job of hiding it.

LOL.
Obviously,
- the part of the drawing that you removed meant that you can place the clock in a noisy place, then run it through a big bunch of stuff, then waste your time cleaning it (or not)
- and the part that you quoted means that if you put the clock close to the DAC, and send a buffered copy to the source, the problem goes away as long as the digital transmission is error-free.

Originally posted by Cauhtemoc
While it is better than optical SPDIF, ST glass is still optical. I will not go into details, but any optical method of transmission will have more jitter than a pure electrical one.

True, but it only matters if the clock you transmit to it will be used for DAC. If it is only a data transport, it is good.

Originally posted by marziom
some things like that?

Well, you drew the bulk USB protocol... simple isn't it ? The FX2 and the PC chipset do all this in hardware.

Several ways to do this :

- Use a small buffer in the DAC (like, 32-64 kB) then the PC always sends data. When the buffer is full, automatic USB bulk flow control takes care of things like ACKs, error checking, retransmission... FX2LP does all this in hardware, you just have to set AUTOOUT=1

- If you have an ADC, and I will, you can do it different : the PC waits to receive a block of ADC samples, then it sends back to the device as many DAC samples. So, it is always playing as many samples as it is recording. Preload the buffer on startup with a number of samples corresponding to your desired latency.

I'll use the second method because it is usable with isochronous asynchronous and also bulk, and you don't need to change the FIFO sizes, just decide how much stuff you put in them at the beginning.