Building a DIY Music Server

[dminches]

In your examples Roon is still running and that (negatively) affects sound quality.

 

[c-w]

37 minutes ago, drjimwillie said:

In the same way that Roon & Euphony hand the file over to HQplayer, why can’t it just hand the file over to Stylus or TAS.

 

You can. Use option Roon + StylusEP in Euphony or if Roon is not on Euphony you can still connect from Roon over network to StylusEP running on Euphony machine either via Squeezebox protocol or HQPlayer protocol.

[drjimwillie]

1 hour ago, dminches said:

In your examples Roon is still running and that (negatively) affects sound quality.

 

In my example, Roon is playing in a separate place, on the network. Not on any of the audio dedicated computers, server or endpoint.

 

(in my instance the computer running Roon is a NAS with no solid-state drive‘s and a LPS. I also have an optical module separating the NAS and the server.)

 

for it to affect the sound it would have to do some sort of processing of the file. how would it affect the sound if it is not really touching the file.  I am suggesting Roon just point to the file.

[drjimwillie]

43 minutes ago, c-w said:

You can. Use option Roon + StylusEP in Euphony or if Roon is not on Euphony you can still connect from Roon over network to StylusEP running on Euphony machine either via Squeezebox protocol or HQPlayer protocol.

I did try that, thank you.

 

I found that Stylus sending to stylusEP, to sound better than Roon or HQplayer or anything else sending to stylusEP or NAA. 

 

So why can’t I use Roon to curate the files. Just point to it and Stylus picks it up and plays it.

 

Roon, or whatever player you like tells your server, for example playing stylus, this is the next file you were going to play.

Stylus on your server, waiting for that information, says thank you, and it plays the file that is presented to it.

They are all dealing in ethernet URLs anyway. Unless it’s on your local drive and that’s an easy address to point to also.

[c-w]

15 minutes ago, drjimwillie said:

So why can’t I use Roon to curate the files. Just point to it and Stylus picks it up and plays it.

 

 

You can't because Roon never gives its endpoints path to the file, it serves the http stream containing the song. In addition to that it concatenates the next song... This is all mentioned in Euphony article about playing from RAM: https://euphony-audio.com/hesk/knowledgebase.php?article=18

 

If Roon would just send song path then essentially there would be very little difference between Stylus playback and Roon + StylusEP playback (Roon incessant chattering would still give off some noise).

[Dev]

2 minutes ago, c-w said:

 

You can't because Roon never gives its endpoints path to the file, it serves the http stream containing the song. In addition to that it concatenates the next song... This is all mentioned in Euphony article about playing from RAM: https://euphony-audio.com/hesk/knowledgebase.php?article=18

 

If Roon would just send song path then essentially there would be very little difference between Stylus playback and Roon + StylusEP playback (Roon incestant chattering  would still give off some noise).

 

This is correct. With Roon, whether the file is stored locally or in the network, it constantly fiddles with the I/O. You can test this with a simple USB hard drive which has an activity led or monitor the network activity - either way, they are constantly accessed during playback.   

[drjimwillie]

Is Roon sending a stream when HQplayer is processing the file? Is HQplayer handling the whole processing of the file?

 

Is it that Roon doesn’t serve up the URLs or that they will not give the URL out of principle?
If the song you choose is on Qobuz, all it would have to do is point to that Qobuz file.

 

and, I’m not talking about Roon talking to the endpoint it is communicating with the server.

 With Roon on my Nas and HQplayer on my server, HQplayer processes a file served up by Roon.  Or do I have it wrong?  

Are  you saying that my Roon on my Nas is streaming a file it has processed and sending that to HQplayer on my server to process again?

[Nenon]

6 hours ago, drjimwillie said:

Is Roon sending a stream when HQplayer is processing the file? Is HQplayer handling the whole processing of the file?

 

Is it that Roon doesn’t serve up the URLs or that they will not give the URL out of principle?
If the song you choose is on Qobuz, all it would have to do is point to that Qobuz file.

 

and, I’m not talking about Roon talking to the endpoint it is communicating with the server.

 With Roon on my Nas and HQplayer on my server, HQplayer processes a file served up by Roon.  Or do I have it wrong?  

Are  you saying that my Roon on my Nas is streaming a file it has processed and sending that to HQplayer on my server to process again?

 

Roon does not just serve the URL to an external program. It does a lot more than that that deteriorates the sound quality no matter where you run it or how you isolate it. 

Your idea to have Roon just handle the URL and shutdown any other activity is great. Unfortunately Roon has no desire to make such changes... or any changes that significantly improve the SQ. They have different priorities. Many of us have tried to convince them to do things to improve the sound quality but they have been ignorant and arrogant for the most part. That's their loss. New and much better software is coming up and replacing Roon in many high-end systems. The interface will slowly catch up over time.

 

[genvirt]

8 hours ago, Nenon said:

New and much better software is coming up

And it’s name is...:)

[Nenon]

13 minutes ago, genvirt said:

And it’s name is...:)

TAS is the leading one but not available yet. 

Euphony / Stylus.

HQP sounds much better than Roon eden if you don't upsample. 

[AME]

What about Audirvana?

 

I'm using this at the moment and it sounds definitly better then Roon.

It also has integration with Tidal and Qobuz.

 

It can also handle VST plugins.

 

 

 

[MarcelNL]

great info Nenon!

 

I'm hoping for TAS, even if that may impose using W LTSC, as I have grown into liking how Taiko is doing what they are doing a LOT reading about their efforts at WBF!

 

I have not read as much detail from any operation on design evolving around listening to various options before implementation as from them!

Would High-End Munich happen in 2021 I'd likely attend a session should their equipment be around, could drive over to pay them a visit at some point, but for that darned COVID thing...
 

 

[drjimwillie]

8 hours ago, Nenon said:

 

Roon does not just serve the URL to an external program. It does a lot more than that that deteriorates the sound quality no matter where you run it or how you isolate it. 

Your idea to have Roon just handle the URL and shutdown any other activity is great. Unfortunately Roon has no desire to make such changes... or any changes that significantly improve the SQ. They have different priorities. Many of us have tried to convince them to do things to improve the sound quality but they have been ignorant and arrogant for the most part. That's their loss. New and much better software is coming up and replacing Roon in many high-end systems. The interface will slowly catch up over time.

 

Thank you for the response. 

I have seen some of the interactions over there, and it is surprising and sad.

 

putting that aside;

you say that it will not serve URLs to exterior programs, it considers HQplayer and interior program.  How does it handle the data flow to HQplayer?

 

In the same Spirit that we are doing a “hack“ that uses HQP protocol for streaming to the NAA, to get around some limitations, couldn’t the receiving software like Euphony do some sort of hack that picks up the data intended for HQplayer and substitute Stylus?

 

Perhaps, and I know this is a longshot, Roon just curating the file, serving up the URL, could be looked at as a different business model rather than a sound quality enhancement. So that they don’t reduce their market share.  Part of my intent is to discussed this process with like minded individuals here, so that I can flush out the idea to something simple and workable and then I will be willing to go over there and present it.😎

[AME]

@Nenon,

 

Any news on the Taiko DIY?

 

I just filled in the Pre order form for the DC DC ATX:)

 

Do you have some more info about the unregulated PSU?

 

Availability of parts?

 

 

 

[amolan]

28 minutes ago, Nenon said:

TAS is the leading one but not available yet. 

Euphony / Stylus.

HQP sounds much better than Roon eden if you don't upsample. 

Hi Nenon, do you know if TAS will be available outside the extreme package ?

[Tatomek7]

3 minutes ago, amolan said:

TAS will be available outside the extreme package ?

What I understood, launch will start with Extremes, after EVO 2015 and as it is single CPU server, I see nothing against to make it available widely. Hi @Nenon, any news :) 

[Nenon]

2 hours ago, AME said:

Any news on the Taiko DIY?

The Taiko team has been working on the next batch of Extremes. As soon as Emile get some time he will finalize the chassis design and place an order... probably in the next week or two.

 

2 hours ago, AME said:

Do you have some more info about the unregulated PSU?

I just received a batch of new capacitors... but I am traveling... will get to test them as soon as I get back. 

 

2 hours ago, amolan said:

Hi Nenon, do you know if TAS will be available outside the extreme package ?

 

2 hours ago, Tatomek7 said:

any news :) 

I do expect that the people who follow this build would be able to get a copy of TAS at some point in the future. 

 

The plan is that Taiko would provide: chassis to passively cool the Asus SAGE, Taiko DC to DC ATX, and at some point a USB card and TAS. Of course Extreme owners get the VIP treatment, and we would have to wait for the technology to treacle down to us. 

[genvirt]

3 hours ago, Nenon said:

TAS is the leading one but not available yet. 

Euphony / Stylus.

HQP sounds much better than Roon eden if you don't upsample. 

The question is - what can be available for using with Euphony...

[ASRMichael]

1 hour ago, genvirt said:

The question is - what can be available for using with Euphony...

I’m sure it will only ever be Euphony Stylus, that’s it. 

[Foggie]

On 1/24/2021 at 11:35 PM, Nenon said:

 

Roon does not just serve the URL to an external program. It does a lot more than that that deteriorates the sound quality no matter where you run it or how you isolate it. 

Your idea to have Roon just handle the URL and shutdown any other activity is great. Unfortunately Roon has no desire to make such changes... or any changes that significantly improve the SQ. They have different priorities. Many of us have tried to convince them to do things to improve the sound quality but they have been ignorant and arrogant for the most part. That's their loss. New and much better software is coming up and replacing Roon in many high-end systems. The interface will slowly catch up over time.

 

Understanding the logic you stated, but are you indicating that the mere presence of roon is creating noise / crap on the network and ultimately degrading sound even if your using a well isolated endpoint / HQP?

 

 

[Nenon]

17 hours ago, Foggie said:

Understanding the logic you stated, but are you indicating that the mere presence of roon is creating noise / crap on the network and ultimately degrading sound even if your using a well isolated endpoint / HQP?

 

No, not at all. 

 

First, I don't really buy into the whole concept of a well isolated endpoint from the server. The idea sounds really good and logical but never worked well for me in practice. It's just like the concept that DAC manufacturers have been trying to convince us for years - the USB input is galvanically isolated and reclocked, so the quality of the server does not matter. No need to explain to the people following this thread that a well-designed source (server/endpoint/whatever you want to call it) makes a big difference. There is a really good reason servers like Innuos, Taiko, PinkFaun, Antipodes, etc. exist and cost so much. Arguably, they could make as much difference as a DAC (yes, even when connected to that same DAC with galvanically isolated USB input and reclocked signal). Anyone with a resolving enough system who has switched from a Mac MINI or a laptop to one of these well designed servers has experienced that. 

 

So, if a galvanically isolated USB input with a reclocker does not work, why do we think that we can "isolate" a server from the endpoint and make the endpoint immune to the server quality? From all my experiments, the conclusion has always been the same: "we can't". I've tried everything I could think of - fiber ethernet, fiber ethernet with state of the art clocks, fiber ethernet with state of the art clocks and state of art power supplies... and state of the art switches... and network cards.... and cables... and power conditioners... and state of the art motherboard clocks, powered by state of the art power supplies and cables... and different transceivers... and so on and so on. 

 

I don't know exactly why ethernet isolation does not work, just like I don't know exactly why a galvanically isolated and reclocked USB input on a DAC does not work as expected. But here are some examples that may give us a hint. Let's talk about an endpoint for a second - the last computer that is connected to the DAC. It may be receiving a data stream from the network (i.e. from a Roon Core) or playing music locally. 

1. In many cases, my experience with local music playback has been that disconnecting the network cable leads to a sound quality improvement shortly after the disconnect. That suggests that some noise is getting into the server from the network.

2. I have noticed that unnecessary network activity while playing music deteriorates the sound quality.

  2a. Euphony / Stylus caches the track you are playing and minimizes the network activity to a minimum. During some of my tests I noticed that opening multiple web browsers pointing to the Euphony page would degrade the sound quality. That was a very interesting experiment. The more web browser windows you open (pointing to Euphony), the easier it is to hear that. At some point I remember opening 50 windows on multiple computers. It turned out Euphony was using Ajax to update the time lapse interval display every second or so. That extra network traffic was enough to cause some sound quality degradation. BTW, I reported this to Euphony and they added an option to disable that traffic. 

  2b. When I isolated my endpoint to its own VLAN, I heard an improvement. Isolating to its own VLAN means that any broadcast traffic from my home network would not make it to my endpoint. I have a very small home network and have used a sniffer to see how much broadcast there is. It's very little, but yet enough to have an impact. 

  2c. I have tweaked how the NIC interacts with the CPU. You can configure the CPU interrupts and resources the NIC driver is utilizing, essentially how the NIC interacts with the OS. It's an interesting test. You configure it to use more resources and you get lower latency, but that comes with some side effects (i.e. your server becomes even more sensitive to any extra network traffic, thus making the network chatty Roon even worse). You make it use less resources, and you are more immune to all the network activity going on, but you increase the latency and that has other side effects. i will be writing more about this in the Windows LTSC guide later this year.

All that tells me that that network activity on the endpoint impacts the sound quality. Even if you have the perfect server streaming the perfect stream over the perfect network to your endpoint, the fact that the endpoint is receiving and processing network packets (while playing) is not ideal and degrades the sound quality of the stream going to your DAC. 

 

The ideal endpoint would be one that does not have a network connection at all. And this is where attention to detail in software that is designed with sound quality as top priority matters. I do expect to see some breakthrough innovations in the software in the near future. 

But if that is the case, why so many people buy into the server/streamer concept and after trying many solutions including a single server/endpoint device, they prefer it (in many cases by a big margin)? I think the answer is twofold. One part has to do with upsampling and the other with the quality of the server. Let's cover those two:

 

Upsampling:

Many DACs work better when they are fed by an upsampled signal. Those are typically DACs that upsample internally. By feeding them with an upsampled signal they have to do less processing. That results in less processing inside the DAC, which results in less noise, which ultimately means better sound quality. Sparing the noise that tha DAC is producing during its internal upsampling in some cases is much bigger improvement than upgrading servers/endpoints upstream of the DAC. That is of course DAC-dependant and not always the case. But for these DACs it makes perfect sense to use software like HQPlayer that does the heavy lifting and offloads the DACs extra processing (and noise).

What happens when you start doing heavy upsampling on your server that is directly connected to the DAC? Well, I mentioned above what the impact of the network/ethernet processing is, but that is nothing compared to the impact of the heavy processing that HQPlayer does. The noise generated from the upsampling process on the server is in orders of magnitude bigger than the negative effect of the network/ethernet processing. It's much better to isolate the upsampling noise from the endpoint and accept the network/ethernet noise / sound quality degradation. The net result is a big improvement in this case. And this is why many people prefer a two box solution - a server and a streamer. Sounds like a good compromise... but there are people like me who just can't settle with such a big compromise and kept looking. More on that later. 

 

Quality of the server (in a single box solution):

This is another aspect that we should not forget. When you have a single device that handles the server and the streamer part, it is directly connected to the DAC and its quality is crucial. Computers are noisy devices that were not designed for audio. But with a careful implementation and the right choice of software, hardware, power supply, etc. you can make a single box solution work better than anything else. You cache the tracks before playing, minimize the network activity, and take care of every detail, and you would be rewarded. 

 

There is a saying that your system is only as good as the weakest link in the system. The same applies to the digital source. I look at it as a complex chain of components that interact in a very complex way.  There are different solutions for different people. For some people the benefit of the upsampling is so big, that they can live with the negatives of a server and a streamer solution. Other people have DACs that don't benefit from upsampling and settle for the best single box solution they can get. There are also people who like the small / low powered endpoints and can't understand why we do all that instead of buying a *Rendu for example - from my experience those are people with small systems, typically with bookshelf speakers who don't need the massive scale, dynamics, and everything else a server like the Taiko Extreme can do but like the low noise, dark background, small but holographic soundstage of these devices (and I completely understand their point of view as well). There is no universal solution that works best for everyone. 

Here is what I do:

I currently use the Chord DAVE DAC powered by a Sean Jacobs DC4 LPS. This DAC benefits from upsampling. It specifically benefits from being fed by 705.6/768kHz PCM. It also benefits from more taps, but that's outside of the scope of this post. As mentioned above a two server solution does not work for me. So I upsample my local music offline and store it locally. There are programs like HQP Pro and some others that can do that. I store the music locally on my NVME storage. Then I use HQP and NAA on the same server. I assign affinities for those processes on different physical CPUs (which also means they use different RAM modules). I have a CPU that is only responsible for the music processes (i.e. NAA in this case). The USB output is directly attached to that CPU. The other CPU handles all the network activity, OS activity, HQP part, etc. In a way, I get the best of both worlds and the net result is amazing. 

 

Going back to the question about Roon. Roon does a lot of things that harm the sound quality. It performs constant network activity while you are playing, it has constant disk I/O activity, it does some processing that swings the CPU utilization, which causes noise that is audible in a resolving system. And the list goes on... Depending on whether you use a two box (a server and a streamer) solution or a single box solution like me it has different impact. But in any case, it would not be my choice for critical listening. Having said that Roon/Qobuz is the best tool for discovering new music for me. I so use it for that. 

 

P.S. A note to myself - learn what a short reply means! 

[MarcelNL]

great read! Makes lots of sense to me, in my setup I'm not particularly fond of upsampling and there will be more people like me but that should make the job at hand easier.

[MarcelNL]

Just wondering, thinking out loud, when designing a music player app it should be possible to take care of caching to a memory location of choice (Optane, RAM etc) and shut off unwanted not needed network...when playing headless that may get us to the point where a track cannot be interrupted until it's finished and the network is activated, likely ease of use is the trade off but if doable it may well be an option users can select, sort of a 'full paranoia options on for selected tracks' tick box. For serious listening I'd be sure to use it as I'm currently playing from RAM and then disengaging the network for serious listening whcih often leads to a reboot of Daphile once network is restored.

 

[Foggie]

3 hours ago, Nenon said:

 

No, not at all. 

 

First, I don't really buy into the whole concept of a well isolated endpoint from the server. The idea sounds really good and logical but never worked well for me in practice. It's just like the concept that DAC manufacturers have been trying to convince us for years - the USB input is galvanically isolated and reclocked, so the quality of the server does not matter. No need to explain to the people following this thread that a well-designed source (server/endpoint/whatever you want to call it) makes a big difference. There is a really good reason servers like Innuos, Taiko, PinkFaun, Antipodes, etc. exist and cost so much. Arguably, they could make as much difference as a DAC (yes, even when connected to that same DAC with galvanically isolated USB input and reclocked signal). Anyone with a resolving enough system who has switched from a Mac MINI or a laptop to one of these well designed servers has experienced that. 

 

So, if a galvanically isolated USB input with a reclocker does not work, why do we think that we can "isolate" a server from the endpoint and make the endpoint immune to the server quality? From all my experiments, the conclusion has always been the same: "we can't". I've tried everything I could think of - fiber ethernet, fiber ethernet with state of the art clocks, fiber ethernet with state of the art clocks and state of art power supplies... and state of the art switches... and network cards.... and cables... and power conditioners... and state of the art motherboard clocks, powered by state of the art power supplies and cables... and different transceivers... and so on and so on. 

 

I don't know exactly why ethernet isolation does not work, just like I don't know exactly why a galvanically isolated and reclocked USB input on a DAC does not work as expected. But here are some examples that may give us a hint. Let's talk about an endpoint for a second - the last computer that is connected to the DAC. It may be receiving a data stream from the network (i.e. from a Roon Core) or playing music locally. 

1. In many cases, my experience with local music playback has been that disconnecting the network cable leads to a sound quality improvement shortly after the disconnect. That suggests that some noise is getting into the server from the network.

2. I have noticed that unnecessary network activity while playing music deteriorates the sound quality.

  2a. Euphony / Stylus caches the track you are playing and minimizes the network activity to a minimum. During some of my tests I noticed that opening multiple web browsers pointing to the Euphony page would degrade the sound quality. That was a very interesting experiment. The more web browser windows you open (pointing to Euphony), the easier it is to hear that. At some point I remember opening 50 windows on multiple computers. It turned out Euphony was using Ajax to update the time lapse interval display every second or so. That extra network traffic was enough to cause some sound quality degradation. BTW, I reported this to Euphony and they added an option to disable that traffic. 

  2b. When I isolated my endpoint to its own VLAN, I heard an improvement. Isolating to its own VLAN means that any broadcast traffic from my home network would not make it to my endpoint. I have a very small home network and have used a sniffer to see how much broadcast there is. It's very little, but yet enough to have an impact. 

  2c. I have tweaked how the NIC interacts with the CPU. You can configure the CPU interrupts and resources the NIC driver is utilizing, essentially how the NIC interacts with the OS. It's an interesting test. You configure it to use more resources and you get lower latency, but that comes with some side effects (i.e. your server becomes even more sensitive to any extra network traffic, thus making the network chatty Roon even worse). You make it use less resources, and you are more immune to all the network activity going on, but you increase the latency and that has other side effects. i will be writing more about this in the Windows LTSC guide later this year.

All that tells me that that network activity on the endpoint impacts the sound quality. Even if you have the perfect server streaming the perfect stream over the perfect network to your endpoint, the fact that the endpoint is receiving and processing network packets (while playing) is not ideal and degrades the sound quality of the stream going to your DAC. 

 

The ideal endpoint would be one that does not have a network connection at all. And this is where attention to detail in software that is designed with sound quality as top priority matters. I do expect to see some breakthrough innovations in the software in the near future. 

But if that is the case, why so many people buy into the server/streamer concept and after trying many solutions including a single server/endpoint device, they prefer it (in many cases by a big margin)? I think the answer is twofold. One part has to do with upsampling and the other with the quality of the server. Let's cover those two:

 

Upsampling:

Many DACs work better when they are fed by an upsampled signal. Those are typically DACs that upsample internally. By feeding them with an upsampled signal they have to do less processing. That results in less processing inside the DAC, which results in less noise, which ultimately means better sound quality. Sparing the noise that tha DAC is producing during its internal upsampling in some cases is much bigger improvement than upgrading servers/endpoints upstream of the DAC. That is of course DAC-dependant and not always the case. But for these DACs it makes perfect sense to use software like HQPlayer that does the heavy lifting and offloads the DACs extra processing (and noise).

What happens when you start doing heavy upsampling on your server that is directly connected to the DAC? Well, I mentioned above what the impact of the network/ethernet processing is, but that is nothing compared to the impact of the heavy processing that HQPlayer does. The noise generated from the upsampling process on the server is in orders of magnitude bigger than the negative effect of the network/ethernet processing. It's much better to isolate the upsampling noise from the endpoint and accept the network/ethernet noise / sound quality degradation. The net result is a big improvement in this case. And this is why many people prefer a two box solution - a server and a streamer. Sounds like a good compromise... but there are people like me who just can't settle with such a big compromise and kept looking. More on that later. 

 

Quality of the server (in a single box solution):

This is another aspect that we should not forget. When you have a single device that handles the server and the streamer part, it is directly connected to the DAC and its quality is crucial. Computers are noisy devices that were not designed for audio. But with a careful implementation and the right choice of software, hardware, power supply, etc. you can make a single box solution work better than anything else. You cache the tracks before playing, minimize the network activity, and take care of every detail, and you would be rewarded. 

 

There is a saying that your system is only as good as the weakest link in the system. The same applies to the digital source. I look at it as a complex chain of components that interact in a very complex way.  There are different solutions for different people. For some people the benefit of the upsampling is so big, that they can live with the negatives of a server and a streamer solution. Other people have DACs that don't benefit from upsampling and settle for the best single box solution they can get. There are also people who like the small / low powered endpoints and can't understand why we do all that instead of buying a *Rendu for example - from my experience those are people with small systems, typically with bookshelf speakers who don't need the massive scale, dynamics, and everything else a server like the Taiko Extreme can do but like the low noise, dark background, small but holographic soundstage of these devices (and I completely understand their point of view as well). There is no universal solution that works best for everyone. 

Here is what I do:

I currently use the Chord DAVE DAC powered by a Sean Jacobs DC4 LPS. This DAC benefits from upsampling. It specifically benefits from being fed by 705.6/768kHz PCM. It also benefits from more taps, but that's outside of the scope of this post. As mentioned above a two server solution does not work for me. So I upsample my local music offline and store it locally. There are programs like HQP Pro and some others that can do that. I store the music locally on my NVME storage. Then I use HQP and NAA on the same server. I assign affinities for those processes on different physical CPUs (which also means they use different RAM modules). I have a CPU that is only responsible for the music processes (i.e. NAA in this case). The USB output is directly attached to that CPU. The other CPU handles all the network activity, OS activity, HQP part, etc. In a way, I get the best of both worlds and the net result is amazing. 

 

Going back to the question about Roon. Roon does a lot of things that harm the sound quality. It performs constant network activity while you are playing, it has constant disk I/O activity, it does some processing that swings the CPU utilization, which causes noise that is audible in a resolving system. And the list goes on... Depending on whether you use a two box (a server and a streamer) solution or a single box solution like me it has different impact. But in any case, it would not be my choice for critical listening. Having said that Roon/Qobuz is the best tool for discovering new music for me. I so use it for that. 

 

P.S. A note to myself - learn what a short reply means! 

 

Wonderful response, thank you for taking the time and effort writing this.  Short reply's have a place, but a well thought out response goes a long way to clear up any confusion and is always welcome in my book.

 

Balance is key - there are what seems like unlimited settings to play with on every device in the chain and I understand this discussion isn't really geared toward the standard user "plug n play / good enough". 

 

At some point one has must find that balance and has to live within the "limitations" of their gear even after optimizing/tweaking and enjoy the system.  IOW, finding out the best source (one box optimized server, two box etc..) that works within your systems limitations/compromises is key - which you so nicely penned. 

 

Your system (your ears, your room...) might be an order of magnitude more sensitive to these source changes/optimizations then another persons system - again balance is key.  Lets also not forget about the co$t factor - if in fact that is a significant piece and or correlates to the end result. The cost factor is also sooo very relative per individual.  

 

Not knowing much about the TAS product, to your knowledge, will the TAS application only be available for taiko products?

 

[MarcelNL]

TAS is under development and being tested in a Beta version right now, it will likely be rolled out top down (Extrema , SGM 2015) if I read the signs correctly, and it MAY be made available to other platforms later...I for one sincerely hope for that last bit!