First Steps into Computer Audio



Hi

I have shifted from traditional rig (first Vandy HT system w/ Arcam receiver, to Acoustat 2+2 with Belles 400 amp), to computer audio.

My main system is a desktop Dell Dimension P4 system, that has a SB Audigy 2 card. Will be listening to lots of classical, jazz, etc, as well as movies. Room is a very small 8 by 5 or 8 by 6 room

I just bought Audioengine A5's with the 25% off coupon, and likely will also buy some Quad 11L's to compare and sell the one I don't like as much.

So chain will be P4 w/ SB audigy 2 to A5 or Quad 11L (I assume the Quad 11L will be way better but will review and let folks know).

Now the question is what next to improve sound (and I will of course wait to do my next upgrade but already planning as most everyone says Audigy 2 is not very good.

I don't need a headphone amp (ok if it comes with) as 95% or more of listening will be done with speakers so I guess I could

1. Buy a better soundcard to output analog to speakers (say Chaintech low end, or 1212M higher end, or Xonar STX not sure my mobo is PCI E)

2. Use a USB dac from the usb ports, and feed speakers

3. Use the CB Audigy 2 digital out (SPDIF) to a DAC, or use the better sound card's digital out to the DAC to speakers.

I think would want very good SQ, but also keep price relatively reasonable.

Thoughts? Opinions welcome

Shriram
shriramosu
Yeah, he asked that same series of questions of several (many!) digital gurus. Great stuff, and they were the right questions as far as I'm concerned.
Thanks - I didn't even notice that. EXCELLENT information from various perspectives. For Cerrot, here is the take from the initial question about interfaces posed to Steve Nugent of Empirical. This also goes directly to the question of USB vs Firewire:

The only interface of those listed that can have Async protocol, or handshake with flow-control is USB. Firewire does not support it and neither does AES/EBU or S/PDIF, coax or Toslink. Async protocol allows the master clock to be located at the designation device, either a converter, reclocker or the DAC itself, which is the optimum scenario. This establishes the master clock near the D/A conversion and then controls the source rate using a flow-control protocol.

However many USB and all Firewire interfaces do not use flow-control. The jitter characteristics with these is only as good as the circuits/chips that track the incoming stream from the computer. The master clock is established at the source, which is the computer, and then this must be maintained by all circuits up to the D/A conversion. The jitter from the computer must be dealt with by using PLL-type devices (Phase-Locked-Loop). These track the incoming datastream and synchronize to it, as the same time using filtering and other clever tricks to reduce the jitter of the original stream. Fortunately, there are a few very good chips available that deal with jitter very effectively, namely the DiceII chip for Firewire and the TAS1020 for USB. Even though these do not establish the master clock for the system and instead track the computer datastream clock, their jitter rejection is excellent. Current support for samples rates is: USB - 24/96, Firewire - 24/192 and S/PDIF - 24/192. Look for this to change in 2009.

Of the interfaces listed, an important one was omitted, and that is networked, otherwise known as LAN, Ethernet or Wi-Fi wireless network. The protocol of this network has inherent in it the flow-control and retry mechanisms that enable the optimum audio streaming scenario, as well as having the advantage of avoiding altogether the sometimes troublesome audio software stack of the computer OS. Using networked devices, either wired or wireless can be no different than sending data to a printer. The only concern is getting the data to the device intact. There is no timing information sent or implied. The data is not contiguously streamed at real-time speed as with USB, Firewire or S/PDIF interfaces. It is packetized and sent periodically in high-speed bursts over the network, whenever the network has an "opening". These packets are then collected in a buffer memory at the destination device where they can be clocked out to the D/A using a local low-jitter master clock. The fact that networked data flow incorporates flow-control and retry, and bypasses the computer audio stack makes it the superior method. The only disadvantage is that the player that interfaces to the network is currently a custom player, such as Squeezecenter or Sonos. Hopefully, in the future Microsoft and/or Apple will create more generic player software to drive a networked interface so that more player options will be available. As for bandwidth, networked interfaces can not only support the highest audio sample-rates, such as 24/192, but it can support multiple channels of this, allowing for multiple channel playback for software generated speaker crossover and even movie surround-sound.

The index of all of the interviews is here

Thanks again for pointing that out, Drubin.
Thnx - very interesting read. You've got a little of everything and a lot of no one really knows - would love the chance to read the raw responses as well.
PS - here are the individual answers

http://www.positive-feedback.com/Issue41/ca_moore.htm
Historically, Firewire was the dominant format in pro audio equipment. When pro audio went personal computer based the Apple Macintosh/Digidesign ProTools was the dominate platform, and Firewire became the interface of choice. Since pro audio applications required working with far more than 2 channels of audio at a time, Firewire's speed advantage over USB was important. The current prevalence of USB interfaces for home computers isn't a reflection of any technical advantage, but due to the fact that the overwhelming majority of home computers are non-Macintosh and don't come equipped with Firewire ports.