Computer audio and choosing a good DAC

Joemamma · « **on:** 9 Jun 2016, 11:05 pm »

Greetings,
I have a pair of wedgies and I am working on getting the best sound out of them (within reason). I recently have been moving towards more computer based audio. Just started using ROON (its amazing) Just so darn convenient. I currently have a Music Streamer II+ (DAC). It seems like a good product and I have had it some time. The reviews seem to be strong on it. However, I have been looking at the Schiit Bifrost and the Peachtree DactItx. Would I notice a postitive difference in sound or would it be a total waste of money. I would just be using it for the usb connection. I will not be using it with any headphones (the DAC that is). I posted this in another circle and didn't get much. Just wanted to see if the GR folk have any good recommendations. Thanks for helping.

Danny Richie · « **Reply #1 on:** 10 Jun 2016, 01:27 am »

Borrow one or work out a try before you buy deal and compare.

Joemamma · « **Reply #2 on:** 10 Jun 2016, 01:47 am »

Definately considering the Schiit DAC and giving it a try. You get 15 days to try it out.

mlundy57 · « **Reply #3 on:** 10 Jun 2016, 01:57 am »

You can't lose more than the cost is shipping, if that so it would be worth a try

audio.bill · « **Reply #4 on:** 10 Jun 2016, 02:20 am »

If you're considering purchasing a Schiit DAC for audition, you have 15 days to return it but they do charge a 5% transaction fee on returns.

studley · « **Reply #5 on:** 10 Jun 2016, 12:37 pm »

Let me make it clear that my only connection with what I am about to refer you to is that I am buying one and so am one of the people who has been effectively crowd funding its development.

John Westlake is one of the world's leading DAC designers (some would say the pre-eminent designer and you'd get no argument from me). In recent years he has designed DACs for Audiolab, Creek and Peachtree amongst others. For several years he has been developing a state of the art DAC that will be as good as he knows how to make it. It will certainly be a contender for the best DAC in the world. It's called the FDAC and it should go into production in the next few months. It will not just be a DAC and will feature on- board DSP capability as well as ARM processors so that you will be able to also use it as a Squeezebox replacement. The feature list is massive:

http://www.lakewestaudio.com

If the FDAC subsequently goes into proper commercial production it's retail price will be a multiple of what we as crowd funders will be paying. That is not hyperbole. It's not too late to join the crowd funding arrangement.

If you want to read more there is a thread on the Pink Fish forum that has been running for years called, for historic reasons, MDAC first listen . . .

I reiterate I have no affiliation. It's evident that John is an outstanding and straight up guy and I just want to see this product get the recognition it will deserve.

Coldfusion · « **Reply #6 on:** 12 Jun 2016, 01:43 am »

Quote from: studley on 10 Jun 2016, 12:37 pm

Let me make it clear that my only connection with what I am about to refer you to is that I am buying one and so am one of the people who has been effectively crowd funding its development.

John Westlake is one of the world's leading DAC designers (some would say the pre-eminent designer and you'd get no argument from me). In recent years he has designed DACs for Audiolab, Creek and Peachtree amongst others. For several years he has been developing a state of the art DAC that will be as good as he knows how to make it. It will certainly be a contender for the best DAC in the world. It's called the FDAC and it should go into production in the next few months. It will not just be a DAC and will feature on- board DSP capability as well as ARM processors so that you will be able to also use it as a Squeezebox replacement. The feature list is massive:

http://www.lakewestaudio.com

If the FDAC subsequently goes into proper commercial production it's retail price will be a multiple of what we as crowd funders will be paying. That is not hyperbole. It's not too late to join the crowd funding arrangement.

If you want to read more there is a thread on the Pink Fish forum that has been running for years called, for historic reasons, MDAC first listen . . .

I reiterate I have no affiliation. It's evident that John is an outstanding and straight up guy and I just want to see this product get the recognition it will deserve.

The price is massive too. Starting at $1500?

mlundy57 · « **Reply #7 on:** 12 Jun 2016, 02:43 am »

Quote from: Coldfusion on 12 Jun 2016, 01:43 am

The price is massive too. Starting at $1500?

Maybe I missed something but the way the chart it looked like that was the price for the top of the line with the phono stage

Jonathon Janusz · « **Reply #8 on:** 12 Jun 2016, 04:00 am »

Note the prices on that site are all in pounds sterling. The entry level dac is 400gbp (about $500usd-ish) payment times four total payments ($2000) plus the cost of the pcb when it is made (estimated at another $500) making the total cost of the entry level version about $2500 plus shipping. Prices go up from there.

Totally unrelated to that DAC project, but on the subject of computer audio. I asked this thread in the middle of one discussing the Salk Streamer, but thought the question might see more people with experience to share in Danny's circle too.

It seems lately streamed computer-based audio (often times on a dedicated, purpose built box for the streaming) is becoming the hot thing in audiophile music servers, specifically those systems that stream over a local area network. With an understanding of how TCP/IP networking works and the way in which data gets from one place to another on a network, does anyone have any thoughts comparing sound quality between these network streaming devices and a computer streamer/"renderer" serving files from a local storage device?

Considering the lengths people go through to "clean up" even a USB signal path from an external source drive to a playback device, it seems to me that trying to push audio data along the same pipes as general data network traffic would create a significantly audible difference in the output (my supposition at this point is that this difference is a negative one) as compared to, say feeding a mac mini from a local external SSD attached to an oxford chipset firewire controller (a commonly recommended setup). I also speculated on the other thread that there might be ways to mitigate this issue and improve performance through various data network optimizations.

Any thoughts on this from the crowd? Thanks!

jseipp · « **Reply #9 on:** 12 Jun 2016, 05:17 am »

I've also wondered about the networking, too. It seems, though, that the key is at the end point cleaning up/rendering the signal in a device with the most pristine environment possible, electrically, vibrationally.... That seems to be why so many operations are offloaded to the network.

I am probably the last person who should be attempting an answer to this question, but since I am very interested as well I'll stick my neck out and probably learn a lot in the process.

jcotner · « **Reply #10 on:** 12 Jun 2016, 06:30 am »

Well I'm not a USB expert, but in a TCP/IP network audio files, which are broken down into a series of TCP/IP packets are moved across the network with various checking and possibly retransmission. So if the network is fast enough you'll never notice that packets have to be retransmitted in the event of an error. So they are lossless when they are moved in that environment. I think one of the big problems in USB has to do with clock jitter and better cables help with that. If the clock coming into the DAC from a computer is not clean then you run the risk of data errors because the clock edges have to happen in the middle of a data bit. Otherwise you run the risk of clocking something in at the wrong time.
I used to do a lot of T1 work in telephone networks and we had this type of problem also. Now if someone were to incorporate full packet error checking and retransmission in the USB environment and had sufficient buffer (elastic store) then the problem would be somewhat negated in the USB world. Although the DAC would need a very precise clock as well. So good clock recovery and data bit sampling seem like the main issue in USB links. You want good clean clock edges and clean data edges. Someone may well have a better or more simple answer, but that's the way I understand it.

studley · « **Reply #11 on:** 12 Jun 2016, 12:23 pm »

Quote from: Jonathon Janusz on 12 Jun 2016, 04:00 am

Note the prices on that site are all in pounds sterling. The entry level dac is 400gbp (about $500usd-ish) payment times four total payments ($2000) plus the cost of the pcb when it is made (estimated at another $500) making the total cost of the entry level version about $2500 plus shipping. Prices go up from there

No that's not right. The explanation of the pricing is confusing. The banded section that is headed "FDAC Cost" shows the total prices without shipping - so the price for the L2 is £1080 or about $1540. If you think these prices are high then all I can say is that you have not taken on board what you are getting for your money.

Jonathon Janusz · « **Reply #12 on:** 12 Jun 2016, 01:33 pm »

Quote from: studley on 12 Jun 2016, 12:23 pm

No that's not right. The explanation of the pricing is confusing. The banded section that is headed "FDAC Cost" shows the total prices without shipping - so the price for the L2 is £1080 or about $1540.

Sorry. I didn't scroll down far enough and missed the chart when I was reading the text when looking at the prices; the initial confusion here I think was missing the gbp to usd conversion.

Quote from: jcotner on 12 Jun 2016, 06:30 am

Well I'm not a USB expert, but in a TCP/IP network audio files, which are broken down into a series of TCP/IP packets are moved across the network with various checking and possibly retransmission. . .

I hadn't at first thought considered the buffering of the data locally coming in from the network. My thought process originated from folks discussing differences in sound among transmitting data across various local storage sources, even to go so far as to say there were differences to be heard when moving data from one local storage drive to another depending on how the data was moved. I interpreted that as what the actual 'bits' of the data are being equally important to how those 'bits' got to the final destination device for rendering.

So, as long as the data ends up actually precisely identical (bit-perfect) on both ends of the signal path (in this case involving error checking and correction to insure it is so), then you are at the mercy of both the quality of the signal path of the local storage buffer to the final rendering engine, and ensuring the error correction system to the buffer is never outrun by the demand from the final rendering engine for data from the signal path entering the buffer, meaning as long as the device connecting the buffer to the originating data storage is up to the task appropriately, the IP network data management process should introduce no issue in and of itself? I guess this is why some of the higher end audio streamers have 100gb+ solid state local buffers, to ensure no matter how bad the network gets the rendering engine will never out run the buffer?

jcotner · « **Reply #13 on:** 12 Jun 2016, 04:54 pm »

Quote from: Jonathon Janusz on 12 Jun 2016, 01:33 pm

So, as long as the data ends up actually precisely identical (bit-perfect) on both ends of the signal path (in this case involving error checking and correction to insure it is so), then you are at the mercy of both the quality of the signal path of the local storage buffer to the final rendering engine, and ensuring the error correction system to the buffer is never outrun by the demand from the final rendering engine for data from the signal path entering the buffer, meaning as long as the device connecting the buffer to the originating data storage is up to the task appropriately, the IP network data management process should introduce no issue in and of itself? I guess this is why some of the higher end audio streamers have 100gb+ solid state local buffers, to ensure no matter how bad the network gets the rendering engine will never out run the buffer?

If a large enough buffer is at the DAC, then it's the quality of the DAC and output stage. And I'm assuming USB from a computer (server) to a DAC and that some sort of error detection/correction layer is in place. I haven't done the math on USB though, and don't know if a USB pipe has enough bandwidth to support the audio stream and packet retransmission. Somebody that knows the USB protocols will have to answer that.

MarvinTheMartian · « **Reply #14 on:** 12 Jun 2016, 07:23 pm »

It has nothing to do with data, its all about the clock.
For a useful description of asynchronous USB converter and dac see ....
http://hometheaterhifi.com/reviews/dac/bryston-buc-1-usb-converter
At $800 the BUC is out of your price range, but the information is still useful.

Bryston one of our own Circles.
Shawn

*Scotty* · « **Reply #15 on:** 12 Jun 2016, 07:49 pm »

There is at least one additional variable in play, the software player on the streamer. It no doubt contributes the quality of playback. An added plus would be the ability of the player software to upsample 16/44 files to 88 kHz or 176kHz as many DACs sound better if they are fed upsampled data rather than the base 16/44 data rate.
Scotty

Jonathon Janusz · « **Reply #16 on:** 12 Jun 2016, 08:45 pm »

Maybe to clarify a little, my question has to do with differences in data transmission from the originating storage medium (NAS of some kind in this case, might be a local drive attached to a computer that is then itself acting as a NAS) to the streamer/renderer (which itself would then be connected to the DAC, then volume control - amplification - speakers, as compared to the same setup without the NAS device sending data over a network (local storage - streamer/renderer - DAC - volume control - amplifier - speakers). I follow the difference changes make in clocking from the streamer to the DAC, but here I wonder about the data signal further up.

Scotty, interesting note about a DAC wanting 16/44 data upsampled, even when playing at 16/44. I wonder why, as it seems counter to the goal of data integrity (read: accuracy in sound from source to output), unless the DACs in question don't actually natively process 16/44 data, so the upconversion is there to get the data into the DAC's native bit depth and sample rate, even if the DAC's processing is intended to output a 16/44 data stream to its analog output stage?

Syrah · « **Reply #17 on:** 12 Jun 2016, 08:55 pm »

They are using ESS' cheaper new Pro series DAC and not the 9038. I need a new DAC, but I'm holding off for the 9038 to trickle down to earth. From what I've read (I'm no expert) it seems like a bit of a game changer.

studley · « **Reply #18 on:** 12 Jun 2016, 09:09 pm »

Quote from: Syrah on 12 Jun 2016, 08:55 pm

They are using ESS' cheaper new Pro series DAC and not the 9038. I need a new DAC, but I'm holding off for the 9038 to trickle down to earth. From what I've read (I'm no expert) it seems like a bit of a game changer.

JW posted this a few months ago:

For various reasons that would directly impact sound quality we will not use the 9038 on FDAC but 9028 - I'm not a liberty to say much more at this moment due to NDA with ESS - but there are sound engineering reasons behind this.

Syrah · « **Reply #19 on:** 12 Jun 2016, 09:22 pm »

Interesting. I had assumed either price or pinout compatibility with the older ESS were the reasons. Watch this space I suppose. In any event, given that we seem to have hit a bit of an innovation peak time, I'm holding off until we figure out who the winners are with implementing the new generation chips.