Why does the computer matter?

[Miska]

What we probably don't agree on is about where this kind of interference should be fixed.

 

My opinion is that any differences in analogue conversion of the same digital data should be fixed in that part where it happens, ie. in the conversion hardware. So from my perspective, this is purely a hardware problem.

 

 

 

[ziggyzack]

As Peter said, 'We start playback, and whether it takes 1ms or 2 seconds, after playback started it is continuous.'

 

Indeed, and I'll draw a distinction between how long it takes playback takes to start, and how long data 'waits' in the buffer once a track has been playing for a short while, in the case of the 2 second buffer of the DS.

 

First of all, the buffer can be written to much faster than realtime. 2 seconds of buffer, even at 24/192, can be filled in about 1/5 of a second at 100Mbps rates. Secondly, the size of the buffer does not determine how quickly data can be read out, once it's been written in. Once the first sample of a track is in the buffer, it can be read out straight away (well, relative to 2 seconds). More data will be written in until the buffer is perhaps half full. When the buffer is depleted, say less than half full, it requests more data and has room to accommodate it.

 

The interval between hitting play and music playing is therefore much smaller than two seconds. Similarly, hitting stop will stop the music much sooner than in two seconds. Soon after playback of a track has commenced, the buffer will settle down into a pattern, with data being read from the buffer in realtime, and small bursts of data being written to the buffer to keep it topped up. The average duration between data entering and leaving the buffer may be around 1 second, and by design there will be great variation in the time spent in the buffer by individual samples (jitter if you must, but it's a needless use of the term). When you hit play, the first sample will go out almost as soon as it came in. When you hit stop, some samples in the buffer won't be played at all. The buffer is absorbing the varied burstiness of the input data stream and allows the data to be read from it in a much more even manner - that is its main purpose.

 

I should add that I am certainly not qualified to describe the real detail of the innards of DS players. There is a 2 second buffer, as explained to me, which buffers between the network and the dac chip(s). But this may well have been a simplified explanation, and there may be multiple buffers, including a large one to buffer the input stream, and a smaller one just before the dac(s). However it's implemented, conceptually it can be thought of as a single buffer.

 

ZZ

 

[PeterSt]

So from my perspective, this is purely a hardware problem.

 

Of course it is. But I don't think you or anyone will be able to fix it, already because it works out so similar for everyone (not by means of this measuring, but about far too many similar reports on the nature of SQ to ignore).

Besides, there's nothing much to fix in everybody's present DACs.

Add to it that I especially created a DAC to eliminate these differences, and that I hopelessly failed. I must say that I created an all new design DAC when I saw these results at first and which merely is based on speed than on a decent PSU design (which it has too, but is not seen as the problem anymore), and that I never measured again. I just don't want to know, hearing that the differences are still there as always.

 

In the end I now see it as an advantage, because the computer does matter and there's so much to do. The sound is outrageously good for a long time, but still improves per couple of months just because of these kind of influences. Here too, whatever it is I change, it is generally perceived by everybody the same way.

I only want to say : suppose the influence wouldn't be there, would we have the best sound of all ?

 

Peter

 

[ziggyzack]

From the second link here: http://esoteric.teac.com/technology/

 

ESOTERIC® disc players use proprietary disc transport systems, each designed to reduce noise, vibration, tracking errors and error correction.

 

In addition to these designs, Esoteric players utilize a "read until right" (RUR), advanced stage memory buffer. Typically a RUR system is active only when errors are present. Esoteric implements this process for all data. Data is buffered into a much larger SDRAM memory than is typically used, providing higher accuracy for RUR retrieval while also adding power to required digital processing. This helps to eliminate a much higher level of jitter (errors). The "simplicity" of the Esoteric digital signal processor (DSP), as compared to a computer driven device, is ideal. The signal path is very short, there are dedicated digital signal processors with built-in memory controllers and SDRAM memory chips being less than an inch away. Add Esoteric's precise clocking and power supply, plus the massive VRDS-Neo transport that spins a CD at 4 times the normal rate, without any sign of mechanical vibration, and you have the best possible solution. Furthermore, Esoteric's designs do not allow any off axis data tracking so no off axis error correction is ever required. This also provides a higher level of accuracy for data retrieval.

 

[Miska]

If we first acknowledge following:

- Esoteric is Teac's high-end brand

- Tascam is Teac's pro-audio brand

 

What I find interesting is that many audiophiles consider pro-audio equipment generally "bad". Yet lot of the music is in any case recorded and produced with exactly this pro-audio gear.

 

So are Tascam computer interfaces and converters considered "bad" while Esoteric considered "good"? Why would Teac produce bad equipment for professionals but good ones for consumers? Naturally there are some weighting differences, like high-end consumer products having nice sleek beautiful casings, etc. While professional products are more utilitarian look-and-feel. Consumer products not necessarily incorporating inputs but just outputs.

 

 

[Miska]

Yes, you really should do that, because it *is* a sport. Usecase ? YMMV, but if you can perceive the difference, it's useful at the same time.

 

OK, I just tested on my ancient single-core Pentium 4 machine with Vista32. I don't think there would be any big trouble going to 1 ms (or even below), at least on a newer machine.

 

With ASIO the minimum allowed buffer size by the driver was 2 ms, 192 samples at 96/24. Works flawlessly.

 

With WASAPI Exclusive the minimum allowed buffer size by the driver is 3 ms, 576 samples at 192/32. Works flawlessly too.

 

I don't know what kind of PSUs people are using in their computers, but for the record this is close to the set I use (a bit older equivalent models):

http://www.antec.com/Believe_it/product.php?id=MTc1OA==

http://www.antec.com/Believe_it/product.php?id=NzA0MzM4

http://www.zalman.com/ENG/product/Product_Read.asp?idx=357

 

[Windows X]

And I don't reckon suggesting people to remove buffer out of their equipments. Most of D/A and Pre has buffer stage for input and/or output depending on design. And poor buffering sucks at great deal.

 

For latency, I don't think modern high power machine will have issue with it. However, those aren't suitable because high ripple from swiching PSU and high heat, EMI/RFI and noise. Not to mention a lot of unknown disturbance that aren't known in community.

 

As most of people have a hard time to realize why they need something like clock at few ppm or even below ppm, I don' think my vaguely explanation can elaborate this topic.

 

If you think latency has no effect of audio output then stick with it. They're also tons of people feeling you don't need to pay 10-100 times more to get better sound like snake-oil analogy.

 

At this point, all I can hope for is those who call music server can beat real hiend CD transport will at least try studying about resonance control, power conditioning and perfect clock synchronizing and timing.

 

[Miska]

For latency, I don't think modern high power machine will have issue with it. However, those aren't suitable because high ripple from swiching PSU and high heat, EMI/RFI and noise. Not to mention a lot of unknown disturbance that aren't known in community.

 

As long as the data is not clocked and it remains in digital domain it doesn't matter. Clocking can be elsewhere. And as I said, computers also contain sensitive analog electronics like read/write head electronics in harddisk drives. As well as video RAMDACs for analog VGA output. EMI/RFI can be dealt with.

 

But in any case, the benefits outweight the downsides. Computers make it possible to apply all kinds of DSP processing not previously possible or very expensive.

 

And pretty much all CDs, SACDs and Blurays are recorded, mixed/edited and mastered with computers these days anyway...

 

 

[ziggyzack]

X. You have said things like:

 

You have to get your data out of your crappy machine asap for best sound..

 

And you've also said:

 

I'm looking for music server to act as transport feeding Esoteric D-05 and the problem is I can't find any good ones that can totally make Esoteric P-05 looks inferior but opposite. I'm not looking for all-in-one solution like CD Player replacement but computer audio transport -> hiend DAC.

 

So far I've heard none to out-class $10k CD Transport via RCA, optical, AES/EBU or dual AES/EBU. Price is no objective if something like Mykerinos can shine better than Esoteric P-05 (or P-03 if possible).

 

But it turns out your P-05 transport has an extra-large buffer, which Esoteric actually boast about! From their website:

 

Data is buffered into a much larger SDRAM memory than is typically used...

 

I and many others care a great deal about how to achieve sound quality. Should I follow your advice on how to get there? I'm sorry, I don't think so. I think you're talking out of your buffer.

 

ZZ

 

[Windows X]

Good. Now you're talking those can't affact anything at all for sound card inside a computer.....(or usb/firewire/etc interface). Do you believe that firewire and usb cable won't affact sound quality as long as they meet industry standards?

 

[The Computer Audiophile]

At this point, all I can hope for is those who call music server can beat real hiend CD transport will at least try studying about resonance control, power conditioning and perfect clock synchronizing and timing.

 

Hi Windows X - No need to preach to computer audiophiles like we don't know about the concepts you mention. Remember as CG said, you are using high-end components designed by people commenting on this site.

 

[Miska]

Now you're talking those can't affact anything at all for sound card inside a computer...

 

If the sound card is clocked externally, no.

 

Do you believe that firewire and usb cable won't affact sound quality as long as they meet industry standards?

 

I prefer optical fibres. If the cables work without errors for external harddrive they are good enough for audio too.

 

[Windows X]

Dude. Large buffer size and large buffering time is completely different story. Are you sure what you and I are talking about is the same story?

 

Adding buffer introduced induced jitter from buffer and way to minimize this problem is making system perform closing to 0ms latency as much as possible. Having large buffer size has nothing to do with latency at all.

 

But I must admit most people don't treat latency as big issue for normal playback system since they aren't really into hiend stuff. Back then I couldn't even tell if making different buffer length will affact how I perceive the sound and matter what golden ears say for foobar, I believed they're paranoid in hiend equipments to listen to something that doesn't even exist in there.

 

[Windows X]

To sum this up, can you conclude whether buffering time (latency) affact audio output in playback system? I tried explaining and giving few reliable information about it but I don't feel like they conclude anything about it and jump to other random topics endlessly.

 

To be honest, I feel a bit tired.

 

[1audio]

"As most of people have a hard time to realize why they need something like clock at few ppm or even below ppm, I don' think my vaguely explanation can elaborate this topic." Clock accuracy has little to do with anything beyond pitch. You will not hear even 500 ppm, the literature indicates the sensitivity is .003 or .3% or 3000 ppm. However jitter or phase noise is important and low phase noise is hard to achieve without a stable clock. The lowest noise crystals are SC cut crystals that must be ovenized to work properly.

 

"And I don't reckon suggesting people to remove buffer out of their equipments. Most of D/A and Pre has buffer stage for input and/or output depending on design. And poor buffering sucks at great deal." I'm not sure what I am reading here. Analog buffering has nothing to do with digital buffering in any sense.

 

No spinning optical device has the rotational stability of a magnetic hard disk, it cannot be done. The moment you remove the disk and replace it the rotational accuracy will be massively degraded. thats why any CD/SACD/BluRay drive has a large buffer to re-syncronize the extracted data. Getting decent audio out of a optical data system is a very impressive feat. I had a problem with my CEC TL-2 at one point where the disk was rubbing on the "tray", it did not degrade the sound at all, the squeak was annoying however. The instantaneous jitter must have been enormous.

 

I think that using computer audio strictly as a replacement for the CD is shortsighted. The benefits go way beyond better sound for CD content. The opportunities for new distribution models for less mainstream music and the possibility of new formats without the massive infrastructure costs of SACD for example will prove to be the long term gains of the new way to manage recorded music

 

 

 

 

[1audio]

Peter

 

I'm having trouble understanding your graphs. I need more details on how they were created and what software you were using for them.

 

As for periodic perturbations due to refilling of buffers there is a direct way to measure them. They would be evident in a frequency shift at the refill instant. Starting with a long digital sine wave recording (preferably created not recorded) playing back and looking at the FFT or using a time interval analyzer the periodic changes should be visible. I have done similar with jitter measurements and saw nothing that obviously related to the buffer refresh interval (frequency would be the inverse of the time). In fact most of the intervals described would be visible in a typical jitter measurement.

 

However when I get the test systems together I'll look for evidence of the issue.

 

[1audio]

"Demian. I will be very interested to hear the results of your experimentations."

 

Thanks for the encouragement. I have figured out a way to make a pretty good double blind test of this at least in the context of the Auraliti PK100. I can set two of them up with different buffer settings (totally invisible from the outside or user perspective) and effectively randomize which is which. Then spring them upon a (un)willing victim to hear differences. If there is a difference that is reasonably repeatable then at least we have a starting point. I'll figure out which is which after the testing.

 

However I will be the first to admit that if its not detectable with the Auraliti platform that does not mean its never an issue. We have the same issue with FLAC vs. Wave not being audible on the Auraliti players.

 

[ziggyzack]

However I will be the first to admit that if its not detectable with the Auraliti platform that does not mean its never an issue. We have the same issue with FLAC vs. Wave not being audible on the Auraliti players.

 

Deftly played Mr Martin!

 

 

 

[PeterSt]

As for periodic perturbations due to refilling of buffers there is a direct way to measure them. They would be evident in a frequency shift at the refill instant. Starting with a long digital sine wave recording (preferably created not recorded) playing back and looking at the FFT or using a time interval analyzer the periodic changes should be visible.

 

Demian, no, no way this is visble in any means of normal measurement. Not because I think so, but because there's just no way I can show this anywhere with my own analyser. This is why spend quite some time on this software, which is my own (writing). It actually emerged from a "challenge" right on this forum that these things were perceiveable, but not measureable. So I set myself to it.

 

Anyway, A/D back the played files at using the same clock for the playback or otherwise it's misery. Next arrange for the (auto) alignment (the toughest job ever), align volume (also tough), and lastly some math and all the way zoomable graphics (no analysis without that).

 

That's all. :-)

Peter

 

PS: But also see this : http://www.computeraudiophile.com/content/Really-Good-Way-Test-Equip

You never know ...

 

 

 

 

[1audio]

Peter:

 

There are several items to address here-

1) I don't know the measurement floor of your instruments but I can measure down to really insignificant intervals (20 pS). Its pretty unlikely that a frequency variation of less than 20 pS in an audio tone will be audible. I also have FFT capability to measure with very high resolution (milliHertz).

2) When you capture with he same clock that you render the clock errors will cancel except for the noise components. This is why I try not to depend solely on sampled data analysis. slow and medium frequency changes (wander) will cancel out and become invisible. Part of the magic behind Bill Waslow's software is working out a way to remove those issues so you can see what is left.

3) Comparing DA to AD against the original data file is very problematic since the low pass of the output and the low pass of the input also create a complex all pass function. Its possible to figure out those errors and calculate an inverse all pass function and frequency correction but far from easy.

4) Verification of your measurement chain is both difficult and important. I created an audio frequency source with very low phase noise and jitter (less than 100 pS) to test my setup. Its the only way to know what the measurement floor is.

 

Several remarks on this forum and elsewhere got me to researching this low frequency "wander" issue early this year. I did a number of measurements at the time. The measurements I have done in the past didn't show any issues like you mention but they did show some interesting sidelobes on DAC's with sample rate converters. I'll try to post some of the measurements I have made once I find them.

 

 

 

[PeterSt]

Demian, thank you.

 

The "problem" at investigating the theoretical problems you mention is that each take is 100% repeatable (except for that decimal-1 noise value). Further, all which is "pretty unlikely to be audible" generally is. And even very much. But it depends what your reference and experience is. I think I'm operating on the highest level, which of course does not say you don't, but let's say it was me who started this all in the first place (and not in this thread, but quite some years back).

 

If all is right the DAC I use has an overall jitter figure of less than 0.5ps (go find that), which I can't measure. And as you said or at least implied, this is not about ppm stuff only but merely about phase noise. What I use is better than 120dBc/Hz at 100Hz and better than 115dBc/Hz at 50Hz. Just for your reference, but I guess this is quite ok for some base.

 

Its pretty unlikely that a frequency variation of less than 20 pS in an audio tone will be audible.

 

Yes, looking at the reports all over, you must be right. But a. I never participated in such a test and b. I never heard anything anywhere what's coming from my system.

b. may not say all because I sure didn't hear all, but let's say it tells something at least. I may sound like X now, but I'm pretty sure (from what he tells) he never heard what I have here. Is that important ? by itself not, but I guess once you are at this level, something like 20ps of jitter may start to be audible as well, and the statistical science is moot per that situation. Remember, it's not real science and derived from listening to a nice milk pack Bose system on my part ...

 

But still I don't know.

 

2) When you capture with he same clock that you render the clock errors will cancel except for the noise components. This is why I try not to depend solely on sampled data analysis.

 

Yes, but you hopefully can imagine that this is exactly why I do it like this, beause otherwise you'd be having differences in the first place just because of that (not equally running (and *starting* !!) clocks).

 

3) Comparing DA to AD against the original data file is very problematic since the low pass of the output and the low pass of the input also create a complex all pass function.

 

No, it isn't. But that's why I stated the conditions where this can work. NOS. And filterless of course. Not that you you'll receive the best sound of that, but at least it allows to capture the differences without any means of filtering in the way. Ok ?

 

4) Verification of your measurement chain is both difficult and important.

 

100% agreed. That is why I actually don't trust the comparisons on file and resulting analogue stream. But only that, because in my opinion the comparison of two resulting analogue streams is harmless here. *If* you can proove the result is repeatable, and it is. On the other hand, and never mind I don't trust it myself (e.g. what is the A/D contributing to it), look at that left channel example, and how it deviates from the right channel (the very first picture). It still can be the A/D, but not likely because of the 2000+ components in the DAC concerned, all was soldered by me myself. Still no guarantee, and still agreeing with you here.

 

Several remarks on this forum and elsewhere got me to researching this low frequency "wander" issue early this year.

 

Just for your interest, and maybe because I don't know what to do with it myself ... :

What I see from normal FFT analysis, is a "wander" with a frequency of well into 50 seconds, which changes THD+N from 0.00200 % to 0.00240%. You could say it's marginal, but it is clearly there and completely repeatable from the start of the test signal. Clock frequency unrelated, buffer size unrelated. Looking at it, the refresh rate of the analyser being some 20 times per second (on estimate), on the peaks and dips of this, there is rest in the figure. Like a bit wobbling on the least siginificant digit only. But in between it is far more wild. I'm sure this is real, and it sure looks like resonance. And regarding the latter, what about the analyser's clock and my own, right ? Resonance. Not sure, just a guess.

I only want to say : proper measurement and proper interpretation of it is the most difficult. For me it is.

 

But this is exactly why it is so important that there's also real life judgement, which in my case is not only me, but a whole community which all hear the same when I change something (in the software). This is Gold.

 

Jus trying the best I can, and always hope to learn again.

Peter

 

PS: Looking forward to your findings. Or responses otherwise.

 

 

 

 

[1audio]

"3) Comparing DA to AD against the original data file is very problematic since the low pass of the output and the low pass of the input also create a complex all pass function.

 

No, it isn't. But that's why I stated the conditions where this can work. NOS. And filterless of course. Not that you you'll receive the best sound of that, but at least it allows to capture the differences without any means of filtering in the way. Ok ?"

 

Filterless NOS dacs will have aliases (guaranteed by design) that can really mess up an AD converter that does not have an input filter. And if the AD converter does have an input filter you will have the phase and group delay issues with the received data. Further the DAC may have phase/group delay issues even without a filter. Life is never simple. Praxis for example has a routine for capturing those effects and correcting for them.

 

If you are interested you can calculate the RMS jitter of an oscillator from its phase noise http://www.maxim-ic.com/app-notes/index.mvp/id/3359 There is an online calculator somewhere as well. The low frequency component has a huge impact on the total jitter number. The AES crowd is not interested in Jitter below something like 100 Hz. I'm not convinced yet.

 

"4) Verification of your measurement chain is both difficult and important."

If you have a low jitter source like your oscillators you could build a divider circuit to get low jitter audio signals. There is no substitute for checking you AD chain. A really deep FFT (I use 5M points or more) will show every wart.

 

"What I see from normal FFT analysis, is a "wander" with a frequency of well into 50 seconds, which changes THD+N from 0.00200 % to 0.00240%. You could say it's marginal, but it is clearly there and completely repeatable from the start of the test signal. Clock frequency unrelated, buffer size unrelated. Looking at it, the refresh rate of the analyser being some 20 times per second (on estimate), on the peaks and dips of this, there is rest in the figure. Like a bit wobbling on the least siginificant digit only. But in between it is far more wild. I'm sure this is real, and it sure looks like resonance. And regarding the latter, what about the analyser's clock and my own, right ? Resonance. Not sure, just a guess."

 

An FFT time to frequency conversion will show any instability if its repetitive. Random instability will show as noise. You must capture enough of the original signal with enough resolution for the FFT to be able to see low level stuff. My files are anywhere from 8 to 64 MB. The sidebands I found on Asynchronous Sample Rate Converters (ASRC's) were very subtle and "close-in" meaning low frequency and pretty low level. However its hard to tell if the effect on the sound was audible since there is no research to tap into.

 

Once I learn how to post graphics and reformat the images I have captured I'll post them which, with commentary, may help explain some of these issues.

 

 

 

[1audio]

 

Sorry-

While I was not looking the current inventory of PK100's got sold. When more are available I'll try to hijack a couple for a few days to do some testing.

 

[PeterSt]

Hi again Demian,

 

You can post graphics by clicking on the "File attachments" link near the bottom (when making a post).

 

3) Comparing DA to AD against the original data file is very problematic since the low pass of the output and the low pass of the input also create a complex all pass function.

 

Better would be : impossible. But I hope I sufficiently emphasized that the "example" of the first picture was no example content wise. Also, it is here where the volume part jumps in and which is the first to mess up things.

But FYI and further clarification : The filtering I use for NOS is "outboard" hence in the playback software. The filtered file can be caught and next is a low passed etc. file. *That* file can be fed in the comparison (this time played without any filtering) and compared with its analogue counterpart.

This is not what I said before, nor did I do that, but I can do that and should do that. :-)

 

If you have a low jitter source like your oscillators you could build a divider circuit to get low jitter audio signals.

 

I think I know what you mean, but then again perhaps not;

I'd say : whatever I have the oscillators for, and however I use them for the audio signals, it already has been arranged for, or otherwise I'd have no sound. But maybe you talk about some sneaky application especially for measurement ?

 

256K FFT here. No sidelobes anywhere. Psychologically good. :-)

 

Again, thanks.

Peter

 

 

 

[PeterSt]

If you are interested you can calculate the RMS jitter of an oscillator from its phase noise http://www.maxim-ic.com/app-notes/index.mvp/id/3359

 

At first I thought I knew that one, but I don't. Ok ... looks great. Now :

 

Demian, would you by accident know how to setup fc such that the analyser is not directly connected to the clock output, but merely catches a test signal played by the player while next those same calculations can be used ? (the spreadsheet is linked on that page you referred to)

 

Might it be of use or help, attach (below) is a small screenshot of normal JTest, the 11025 in the middle. Original output is -0dBFS (the 11025 at -3dBFS). The peaks on the left are at (the) 229 distance and the fact that they are lower at the right side is typicle for the non-ringing filtering I apply (which is my own conclusion from unanswered questions at Stereophile about the same phenomenon :-).

Anyways ... I don't see much "application" in L(f-fc) in my case, not even at making the FFT window smaller (like 8K etc.). Or widening the zoom (2nd attachment which is still 256K).

 

Summarized : If it would be possible that I'm knowing a bit what I'm doing to show this to myself as should, I could next try to squeeze out those (latency) differences.

 

Regards,

Peter