Massively improve the SQ of computer audio streaming?

[diecaster]

The purpose of these thread is to allow free and open discussion about some the ideas and solutions floated and used in the "A novel way to massively improve the SQ of computer audio streaming" thread. In that thread, you aren't allowed to make posts that question the validity of what is being done there. You aren't allowed to suggest that expectation bias may be the cause of the improvement being heard. You aren't even allowed to make observations that would cause people to think about why what they are doing makes or does not make sense. 

 

That thread has spent a lot of time and money on the idea that clocks are incredibly important as is low noise on Ethernet and USB connections and that quality USB was critical to improving sound quality. A recent idea is that lowering the latency of the server makes a difference in sound quality. An even newer idea is that using a NUC with AudioLinux in RAM as an endpoint (NAA and ?) is better than an SOtM ultra or an ultraRendu. When I read that, I posted this:

 

Quote

You see, this is where I start to question the groups ability to not be affected by expectation bias. Let's assume for a moment that low latency indeed factors in to improving sound quality. The NUCs you folks are using are much noisier devices over USB than the SOtM ultra and ultraRendu. I don't know about the SOtM ultra, but the ultraRendu runs most of its OS from RAM so it to is a low latency device....not that it is being asked to do much anyway...especially when used as an NAA. Remember, the SOtM ultra and ultraRendu are single board computers specifically designed for low noise and quality USB output. Their clocks are significantly better than the NUC's clock as well.

 

That got deleted because I had the gall to suggest that expectation bias might be at play and ask questions they can't possibly answer. I responded with this:

 

Quote

 

I didn't ask anyone a question. I made an observation that should generate questions in your minds. We know that clocks are important. Hell, you guys lived on that premise since the beginning. We also know that noise is important. You all lived on that premise from the beginning too. Now, the premise that low latency is important has come to the forefront. By using a big powerful noisy NUC with the OS all in RAM as an endpoint, you are saying that low latency is WAY more significant than noise or clocks. Read that again:

 

By using a big powerful noisy NUC with the OS all in RAM as an endpoint, you are saying that low latency is WAY more significant than noise or clocks.

 

If that doesn't generate questions in your minds about what you are doing and what you are really hearing, you guys have lost all sense of reality. You get all pissy at me because I am a more of an objectivist on this than the people active in this thread. But that does not make my observations any less valid.

 

My points are that we know that noise and clocks make a difference. I won't say that word clocks make a difference but quality clocks in the endpoint just before the DAC certainly matter. Clock phase noise causes problems as does noise on the USB bus. Both pollute the DAC and affect the DACs output. Well, we don't have measurements showing that clock phase noise is a problem (that should soon change) but we do know that noise on the USB bus is a problem and that can be measured. It's harder to understand how low latency OS's would be important in and endpoint or server considering that both Ethernet and USB are full capable of overrunning the buffers in the endpoint/DAC so the endpoint/DAC throttles the sender.  You would think that ANY throttling would instantly negate any improvement in latency of the sending device.

 

Now, if you guys read all of that and say "So?", well, more power to you........

 

 

This post was deleted too.

 

So, let's assume for a moment that the observations are correct. Why would latency make a difference in sound quality? Why would a NUC with crappy clocks that makes a lot of noise on its USB ports running AudioLinux in RAM be a better endpoint than the SOtM Ultra with a super duper external clock and low noise purpose built motherboard with ultra quiet power and a fantastic USB implementation? Factor in that the DAC throttles the USB on the endpoint to keep its buffer from overfilling as their are no retransmissions in USB which should negate any latency advantages of the OS running in RAM.

 

Anyone care to discuss this?

 

[diecaster]

I have reached out to AudioLinux and asked them why their software is supposed to improve sound quality and specifically how low latency factors in to this. I tried to look on their forum but most of the posts are in a language I don't read.

[diecaster]

I think you may be right.

[diecaster]

Well, the AudioLinux guy has no answers as to why his Linux sounds better:

 

“It is the low processor latency? It is the linux audio driver? Is the direct connection without mixer to output? Is loading the system to ram? Do I have a full explanation for that? No, maybe a deep study (with measures) of what's happening in the connection with DAC could give more light to the problem.”

 

No wonder you can’t ask real questions in that other thread where all the claims are made. 

[diecaster]

5 hours ago, LTG2010 said:

You can ask him directly, there's a forum link on his webpage and although in Italian, people have posed questions in English and have had them replied.

 

I did ask him directly. Who do you think that quote is from????

[diecaster]

23 minutes ago, Superdad said:

 

Well given that much of this hobby is wringing out the final 10% or less of musicality, these things do matter.  I reported years ago that in slimming Mac OS X (Mavericks), I could hear a subtle but worthwhile improvement with every 10 active background processes I was able to kill.  And once done (down to 78 active processes), I could boot that from the SD card versus a stock OS (about 350 processes) from the HD, and even visiting non audiophiles could immediately hear the difference.

 

Fine. But when you are using a server to feed an endpoint via Ethernet, that shouldn’t matter. Don’t forget that these guys are trying to say that a low latency OS general computer (NUC) with noisy USB and lousy clocks sounds better than a purpose built computer with quiet USB and excellent clocks (ultraRendu).

 

That would suggest that USB noise and clocks don’t matter. Are willing to promote that? Because your products would become useless if that were the case. 

[diecaster]

@beerandmusic

 

Keep this thread on topic....and you don’t need to dominate this thread with your long winded posts that don’t really add to the conversation. 

[diecaster]

19 minutes ago, beerandmusic said:

think about the "other" thread...they were all salivating over SOTM for what seemed years, now all of a sudden a $30 stripped down linux os beats it....What exactly was running on SOny bluray players allowing DSD streaming over dlna?  I bought and used a used one for $40 for years   I am not sure what is different between a $30 stripped down linux solution (that beats a $1000 SOTM), but my guess is it is not much different than what is running on those 8 year old sony bluray players that supported DSD and DLNA?.....oh yea, now i remember the differnce...an interface dedicated to a  paid subscription to roon.

 

hoopla around dacs, and now hoopla around streamers....

 

More to be gained listening to MISKA inre upsampling and buying a good high-current amp.

 

What are you talking about? Please don’t ruin this thread. 

[diecaster]

All I asked was that beer and music stay on topic and not ruin the thread. I still wish he would do both. Actually, I wish he would post someplace else because is a thread killer. 

[diecaster]

The purpose of this thread is to objectively discuss the ideas presented in that other thread as that other thread does not allow that. If you are not fawning over the ideas presented there, you will be censored and asked to stop posting.

 

New ideas could be floated in this thread but that is not its purpose. 

[diecaster]

Peter,

 

Your premise is just plain wrong about this thread and what is being said here.

 

If the computer is directly connected to the DAC via USB, of course changes at the computer can make a significant difference in sound quality. If the computer is feeding something like an ultraRendu over Ethernet, changes at the computer are going to make little to no difference assuming the computer has enough power to  get the audio data to the DAC and keep its buffer filled.

 

The idea that a general purpose computer, like a NUC, with iffy clocks and noisy power and USB ports running a low latency OS from RAM is going to make a better endpoint than a custom special purpose computer with great clocks, quiet power, great USB, and a customized OS is hard to reconcile. 

 

So, you come on now!

 

 

[diecaster]

17 minutes ago, PeterSt said:

For some counter weight :

 

This has coincidentally been the only thing with sense I read in this whole thread. Otherwise this thread aims for us to abandon computer audio.

Comments on that ?

 

If only that poster’s comment were all like that.....

 

Abandon computer audio? What are you reading? Because no where in this thread has there been a suggestion to abandon computer audio. In fact, my setup is sounding so good I have no desire to go back to analog. 

[diecaster]

15 minutes ago, Em2016 said:

Agreed! So let's discuss.

 

Keep in mind that Peter has a vested interest in his PC and software and that his ideas and products do not mesh with the server/endpoint model.

[diecaster]

@Em2016 @Jud I am just pointing out that Peter has a set of products and to expect him to be biased toward them. Peter is never wrong and is the only person with valid answers. 

 

@PeterSt I am not try to stop any on point conversation. You style is to come in and invalidate threads with your idea of what they are about. You are wrong here about that but I am sure you will tell me how you are right. Do your products support endpoints or do they expect a direct connection to the DAC?

[diecaster]

1 minute ago, PeterSt said:

 

Ah, you are still into that one, right ? Get over it ...

 

Why should I? It is how you operate. 

[diecaster]

 

1 minute ago, PeterSt said:

 

Additionally you can't digest the answers, might they be there.

Btw, this is how I operate.

 

Digest the answers? I asked the makers of the miracle OS and they had no answers. 

 

You operate by telling people you are right and they are wrong. All of your products are the best ever. You say that on your web site. 

[diecaster]

2 minutes ago, PeterSt said:

 

See ?

But oh dear, what would have happened when that guy would have had similar answers to mine. Can't be about vested interests. But you would have made up something. You can do it !

 

 

Either contribute to the discussion or go away. And I mean discussion...that does not you dictating that you have all the answers and we just can’t understand them. 

[diecaster]

3 minutes ago, lmitche said:

Hi Peter,

 

Yes. I appreciate that the DAC itself and analog backend may not have the speed to keep up. This could result in a type of moving average rather then full signal delivered to the amp. However in this case the DAC and analog backend is keeping up as the change in the streamer has produced the SQ described above. Nothing else changed but the addition of the NUC.

 

Given this, I can only explain the SQ jump by saying the DAC is getting more bits in a timely fashion. I have personally built and installed seven NUCs in seven different systems for seven different people. Within seconds, one of the first things people say is, "hold-on I have to lower the volume", usually followed by some form of OMG. Over here, my average listening volume is four db lower than before the NUC.

 

So how can the NUC deliver more bits to the DAC? Can it be that the NUC creates less electrical noise, so more bits are heard and processed by the DAC? And/or that the lower noise allows the DAC to run at a higher speed therefore more likely to handle transients and follow the detailed waveform?

 

It seems to me that with a very fast ADC one could record the output of the DAC and compare it to the pure reconstructed digital waveform and find differences. With wavelets both could be decomposed in multiple frequency ranges for deeper analysis. This is pretty simple compared to the multivariate time series analysis I've done in financial services.

 

But what do I know?

 

Larry

 

 

 

Okay, this is over the top crazy:

 

More bits to the DAC?

 

Have to lower the volume by 4 dB?

 

Lower noise so the DAC can run at higher speeds?

 

And you wonder why what you say you think you hear isn’t taken seriously by people that are a little bit objective????

[diecaster]

1 minute ago, lmitche said:

I don't wonder if people take me seriously. Actually it never occurred to me. Nor will it in the future.

 

Well, you should because what you are posting doesn’t make any technical sense. 

[diecaster]

Just now, lmitche said:

This is a judgement and highly debatable.

 

You are kidding about the voltmeter, right? Ha ha.

 

You do realize that any change in endpoint that requires lowering the volume by 4dB would mean that the signal was altered negatively. In other words, the signal was harsher in some way which would imply added distortion of some type somewhere.

[diecaster]

2 minutes ago, Johnseye said:

 

So this is where we may have a differing experience.  I've been increasing my volume up for a more positive experience with no debilitating effect.  I haven't A/B'd the db level however.  That sounds like a worthwhile effort.

 

When sound quality is improved, you can listen the music at the same sound pressure with less fatigue or at a higher sound pressure with the same fatigue. Any time I have had to lower sound pressure it because something has gone wrong with the sound quality.

[diecaster]

Just now, lmitche said:

Again highly debatable. The signal is altered for sure, but why negativey? What I hear is much more accurate, with increased clarity and more enjoyable.

 

Goodbye diecaster, sorry for posting in your thread.

 

More accurate but requires lowering the volume by 4dB? Real increases in clarity almost always results in thinking the signal is quieter, not the other way around around.

[diecaster]

1 minute ago, Johnseye said:

 

I don't think you properly read what I wrote.

 

I am not sure what you were saying. I wrote my thoughts on the subject. If they agree with what you are experiencing, great. If not, we can discuss it.

[diecaster]

6 minutes ago, Johnseye said:

I'm still interested.  I'd like to know your foundation and credibility for claims.

 

I have no specific schooling or training in audio. All I have is personalexperience. Does it matter if I am a day laborer, software engineer, or ex-CEO?

[diecaster]

Just now, Johnseye said:

 

Ok, re-read what you quoted from me and your comment.  Let me know if you need clarification.

 

I have read it a few times and I am still unsure of what you are saying. I have no idea what this really means:

 

"...this is where we may have a differing experience"

 

Who is we? Are you and I having a differing experience from each other or are you and sharing the same experience which is different from others?