Why does the computer matter?

[1audio]

"CD Transport: laser reading -> transcoding to PCM bitstream/DSD/etc -> encoding to SPDIF/AES -> fetch to output transmitter"

 

If it were so easy. The whole process has been reduced to ASIC's so it looks really easy but its not. The original Sony CDP 101 had a ton of electronics in it to do the necessary buffering, error correction, seeking, bit rearranging, UI support, etc. to make the audio happen. None of that has been dispensed with, in fact there is more now, just all buried in a chip. Many DVD players use computer drives connected to a ASIC and then to some connectors on the back of the box. Looks very like your CD player model. Hidden is an astonishing amount of complexity and an architecture that is very computer like.

 

[Windows X]

And WAY MORE work in CPU/integrated chipset/storage/graphic/network...making CD looks like simpleton. And please do reference to respected CD Transport like Esoteric/DCS/Emm Labs/Spectral design. I still have no idea why I can't get away from not dry or rich sound.....pure flat and tasteless for audiophile who love hearing sound like they're next to his ears lol.

 

[Windows X]

After lengthy listening from 1ms buffer size sound. Music Server has potential to out-class CD for more linear and well controlled sound. 2-3ms sounds like CD transport level where it couldn't control very low frequency and impact making bass and punching overwhelmed. 1ms make a new definition of potential better sound from CD.

 

Now I think I have to findout how to make problems less troublesome for interferences. It's almost a year since I built this machine (about 6 months before you write C.A.P.S and it's really well written article).

 

[dallasjustice]

I know the Mykerinos uses a daughter card with different digital output options. What kind of connection are you using to output from the daughter card? Is the Mykerinos the master clock to whatever DAC you are connecting?

 

It goes without saying that I would love to see a full review of the Mykerinos/Pyramix setup.

 

Thanks,

Michael

 

 

 

 

 

[The Computer Audiophile]

Hi Michael - I'm not at liberty to talk about the exact card I'm using but I am using the AES2 Doughter card sending AES to my DAC. The best sound is using a DAC that can send word clock back to the Mykerinos.

 

[dallasjustice]

I won't tell anybody. :-)

 

I am enjoying this thread.

 

[PeterSt]

X, ... I don't know what you are up to with your "2ms" etc., and also I am not sure what you think the real merits are of live musicians and larger than 5ms etc., but latency does matter.

 

If we want to debate the live musicians and *why* the 5ms (etc.) matters ... fine. But in my book this has nothing to do with poor or good sound quality. On a stage ? come on (keep in mind, my book and my book may be wrong :-).

However, it has all to do with the responsiveness of everything and all, and when I play a MIDI instrument on my own, I already can't "play" as such when the latency is above 20ms. The reaction of the sound just doesn't allow me myself to react in time to my own played notes.

Let alone a band who needs to play together.

 

At this stage you may think "another one who doesn't get it", but I'm afraid I may be the only one in this thread who just does get it. Also, maybe my mood looks a bit strange, but this is no wonder after reading the last 40 posts ...

haha

 

Of course latency matters to the sound quality from an audio system, and the first thing you need to do is get rid some of the Pro gear which just isn't suitable for that job. The story is too long to tell, but also too obvious to tell. I mean, the world is full of forums talking about this, and you could start at my own over at Phasure if you want.

 

In between lines : So X, you are correct that it matters, but I'm not sure if you connect that knowledge to the proper merits.

 

There's driver buffer sizes and software buffer sizes. Both imply latency and both influence SQ in their own way;

 

The lowest latency I know from a driver (hence soundcard etc.) is 32 samples. This is not to be confused with the various "ms" or even "us" certain drivers show, because these are base upon a certain Firewire chip, and just don't do their promised job. Think RME here for a decently working example, and we can communicate about this. So this is defined in samples, and now we can talk.

 

When a soundcard offers latency as low as 32 samples, you now must think about "what samples". Why ? well, because a 16/44.1 sample is quite some smaller than a 32/352.8 sample, and the latter needs to push through 16 times more bytes than the former. I only want to say, if you can actually "use" the 32 sample buffer of a device at this high rate, it would equal 2 samples when remapped to 16/44.1 again.

 

Now, the next thing to do, is try whether you can play 16/44.1 through that 32 sample buffer size, but let's make that 48 because you won't have that 32 sample device coincidentally.

Well, can you ? if all is right you can, but it will depend a bit on the software. Foobar should do it.

Now try 24/96.

Can you ? most probably not. It's too much for any random software I know of, but also keep in mind it is the driver playing a large role here. So, you'd have to switch to 96 samples which still will be on the critical side, and thus you will be setting 128. And in the mean time that 128 will provide you glitchless 24/192 as well.

 

Ok, where are we ?

We have a buffer size of 128 samples, and from the software point of view they are to be seen as 32/192 samples which play. That is 0.000005 seconds per sample and this times 128 is 0.0007 seconds. So, here we have 7ms of latency enforced by the hardware side of things (read : the device driver).

But is it really ?

 

Whether you want or not, next thing you do is download XXHighEnd. You may run into some install problems at the start, but in the end you will manage, because everybody does (shut off UAC already before downloading is key here).

Yes, I told you, my mood is strange.

 

What you will see now, is that suddenly you are able to play your 24.192 at 48 samples of device buffer latency. Hmm ...

And for arguments sake, let's say you do have that device which allows for 32 samples. Now you suddenly are at 1.7ms latency.

 

But wait ... nobody said 24/192 was the base of the discussion, right ? Ok, I said that. So actually this base is 16/44.1, and since the 24/192 physically (for most devices) is 32/196, your normal latency is over 16 times smaller. That's calculating nicely into a 0.1ms of physical latency. "Physical" because that is what really would be happening.

 

So, at the physical side of things you can play with a sort of steps of 0.1ms now, and when the 32 sample buffer size is increased to 64, you'll know you have 0.2ms. And so on.

 

As I told earlier on, there's also the software buffers which are not to be confused with "memory playback" (I know, most think it is the same, but it really is not). Now, your next dimension on this subject is that software buffer (hence latency). Now, what do you want ? less than 1 sample is not possible, so may you be able to reach that you're done forever. But let me tell you that I have at least one user who really is able to reach that with 32/192 !! (and he uses it all the time). So, this would be a plain 0.02ms of software latency when it were 44.1 KHz samples, but sadly it is over 4 times worse and calculate the ms becomes useless.

 

"Yea, as useless as the whole story regarding SQ" you may say.

Well, try it. Try it, and learn that there's a world beyond Bill Gates who only states 20ms as the best achieveable latency for audio. Even ASIO is obviously blown to Mars.

I guess this world exists on my forum, and might you not believe (in) it, dive into it a bit because it really works, it really contributes to SQ (for better or for worse), and it does to degrees you (X) apparently only dreamt of.

I myself can sustain glitchless playback with a latency of 16 samples 32/352.8 (or 384) and I don't say this is also with the lowest device buffer size (IIRC this is 256 in my case). So it is also about the combination of both type of buffers.

However, while I can sustain that, I don't use it, because it's over the top. For me it is. My sweet spot is at 2048 for both buffer sizes and 32/352.8 (384).

 

So, now you know all.

Almost all.

Because there's also that dimension of the "memory playback buffer size" (SFS (Split File Size) in XXHighEnd terms) and which appears to be even more important for SQ. At this moment only God knows why. So, a whole track, 2 minutes of it, 20MB, 1MB, less, it all matters and it currently is the most important "SQ" parameter. Here too, people find sweet spots.

 

This must be enough to get you going a bit. This is also why computers matter, although I think I said that earlier in the thread with some smaller text than this one.

 

Best regards,

Peter (good mood, but no mood to check for typos)

 

[Miska]

I myself can sustain glitchless playback with a latency of 16 samples 32/352.8 (or 384) and I don't say this is also with the lowest device buffer size (IIRC this is 256 in my case).

 

For how many 16 sample buffers?

 

Just for the fun, at the moment I'm reliably playing with 0.5 ms (96 samples) with just two buffers on a Linux box at 192/24 to an E-MU 0404 USB. As a sports excercise I could try how low I can go on Windows with various hardware components, and allow such settings. But I don't see much point in it, since it doesn't affect sound quality. Or if it does, the hardware or software is broken.

 

 

 

[ziggyzack]

I also don't understand this at all (just as you predicted, Peter )

 

X, you are really focused on latency - please explain why?

 

Why not measure the latency between recording and playback? People quite like the SQ of the Beatles, and they were recorded ages ago...

 

ZZ

 

[Miska]

And despite the seemingly massive data throughput of ethernet, only properly sorted systems of this type are capable of consistently playing 24/192 files

 

At the moment I'm reliably playing back a DXD file over gigabit ethernet using NFS mount from my file server. And browsing the web (and writing this) at the same time.

 

The lowest latency I know from a driver (hence soundcard etc.) is 32 samples.

 

At least the ice1712 Linux driver for my M-Audio Audiophile 24/96 supports down to 2 samples. On my development machine 8 samples (83 µs) at 96/24 was the lowest value still working reliably, this without special tunings.

 

Expressing buffer sizes in milliseconds is much more convenient, since the length in time doesn't depend on sampling rate. Sizes are then calculated based on sampling rate, thus doubling sampling rate also doubles the size of the buffer in number of samples. For a computer system, the size in time is what matters from handling latency point of view. On some hardware, the allowed sizes in samples may vary depending on sampling rate due to driver design decisions.

 

 

[PeterSt]

Miska,

 

Expressing buffer sizes in milliseconds is much more convenient, since the length in time doesn't depend on sampling rate. Sizes are then calculated based on sampling rate, thus doubling sampling rate also doubles the size of the buffer in number of samples. For a computer system, the size in time is what matters from handling latency point of view. On some hardware, the allowed sizes in samples may vary depending on sampling rate due to driver design decisions

 

While inherently right, this is functionally not useful. That is, if you first believe in the change of SQ at varying these parameters. You don't hear that, ok. But it doesn't mean it isn't so. The other way around : I hear that, and thus it is so (and don't throw the placebo thing at me please). So :

 

It will be obvious to you too that this won't be about the ms of latency hence latency expressed in time, but about the number of interactions per time unit. Of course, we can remap the ms expression into "amount per", and just the same this will be needed with the samples I suggest to express this in. There's a difference though - and this work out the exact other way around from what you said : the number of samples is first dependend on the size of them, and that varies all around. So, the larger the sample (or the higher the bit depth) the less interactions per time unit your system allows. Well, theoretically and up to some point really true (but you will know that the overhead of the interactions themselves weigh in much more).

Additionally, and I think you said that too, the driver is important all over in this, especially for those which allow the choice of 24 vs 32 bit depth (HiFace comes to mind) vs plain 16. Then we're still not finished, because at the other end al may end up in 32 bit i2s and that too must be sufficiently capable (but it will, generally).

 

Peter

 

PS: 2 buffers. But I don't know why you asked the question. Unless you meant "channels" (obvious from earlier posts). Answer to that : 2.

 

[PeterSt]

Miska again,

 

As a sports excercise I could try how low I can go on Windows with various hardware components, and allow such settings.

 

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.

 

As I told on my own forum the other day, with the ultra low latency I achieve there's really no reason to look for any real time system like Linux is supposed to be, and like Windows is *not* suppose to be at all. So, once you are "capable" of achieving one sample of (software) latency, what more real time can real time be (while at the same time this is complete non-sense already, although as said, I have at least one user who prefers this (at 32/176.4 software output) over any higher setting).

 

I can tell you, I started this as a sport myself, and it is not much different from obtaining the fastest time in getting prime numbers up to 100,000 or whatever. I suppose you once did that too within some group ...

 

Peter

 

 

 

[PeterSt]

Why not measure the latency between recording and playback? People quite like the SQ of the Beatles, and they were recorded ages ago...

 

LOL ZZ.

 

Add to that, that some people like resampling (highers latency) and some like remasters (highers volume);

No matter lower latency will bring better SQ up to some point, I'll prefer the higher latency always over the higher volume.

:-)

 

Peter

 

PS and OffTopic : It is only one year ago I really thought they did a good job with those Beatles remasters. Today ? it is as flawed as any "remaster". Just a matter of progressing on other things, and the Ultra Low Latency is part of just that (introduced some 11 months back).

 

 

 

 

 

[ziggyzack]

So latency is the new lossless.

 

ARGGGGGH!!!

 

 

I suppose I'd better mention that DSs have a gargantuan 2 second buffer...

 

ZZ

 

(serious aside - presumably the buffer on the dac side of an asynchronous interface needs to be much larger than needed inside a PC. That async interface is a latency machine, after all...)

 

[PeterSt]

So latency is the new lossless.

 

Haha. But to be clear (and sure) : because I don't have all the time in the world to check for these things myself (and also can't because this highly depends on the actual system itself), I always ask my users to check out the sustainment of "bit perfect" at these crazy low rates, because it is obvious that samples may be lost at some stage.

 

presumably the buffer on the dac side of an asynchronous interface needs to be much larger than needed inside a PC

 

Although not 100% sure, I think you won't notice that "difference" because it will be denoted (and enforced) by the driver. But for example, the buffer you mean for a HiFace is 1024 samples only - quite some less than I imagined.

I don't know about the other devices, but I'm sure Gordon can tell something about that, if he likes to.

 

Peter

 

(what are DSs assuming you didn't mean dCSs?)

 

[Miska]

PS: 2 buffers. But I don't know why you asked the question. Unless you meant "channels" (obvious from earlier posts). Answer to that : 2.

 

I asked because it has impact on the total output latency which is:

= buffer_size * buffer_count + hardware_latency

 

hardware_latency is sum of all the buffers included in the hardware playback chain, including the ones inside DAC chip (typically some tens of samples)

 

The expression in ms is useful, since given computer is generally capable of delivering a buffer within N ms. Thus the buffer time L has to be higher than N. This operating system latency value N is dependent of lot of other things but not on sampling rate.

 

Number of channels is irrelevant, especially for RME due to it's non-interlaced memory layout.

 

And the buffer size doesn't matter for the sound quality because this is how it works:

 

Sound card driver allocates memory block of size (buffer_size * buffer_count). Then it programs the audio interface to generate interrupt every buffer_size. When the audio interface is started, it reads data from the memory based on it's word clock in a loop at constant rate and every time it has done buffer_size samples, it generates interrupt to tell the software that "I'm done with this buffer, now you can fill it with fresh data".

 

So it's completely asynchronous process and not dependent on the software. While software writes samples to the buffer the hardware continues to play samples from the other buffer. If the hardware is not broken, CPU writing to the memory buffer doesn't have impact on the audio card meanwhile reading the buffer elsewhere.

 

The only requirement is that computer is able to deliver new set of samples within the time audio interface is playing back buffer_size samples, otherwise it misses the deadline and there will be buffer underrun. Making the buffer larger of course reduces the likelyhood for this, but increases latency (which matters only from player interactivity point of view and thus can be quite large).

 

[Audio_ELF]

Peter, just to put this in context, your comments about lower latency improving SQ, is this something you can show mathematically / objectively, or just that the sound quality you perceive at the output improves?

 

Eloise

 

[PeterSt]

And the buffer size doesn't matter for the sound quality because this is how it works:

 

Haha, I'm fairly sure you know you don't need to tell me how it works. So I guess you try to impress others with it, or otherwise try to proove that my ears (and those from thousands of others) are broken in one or the other way.

 

Miska, you are as consistent in telling that an OS won't matter to the sound (quality). I know, you add to that "if all is right and correctly setup and all". Please go ahead with that if you want, but you won't gain anything with it because apparently nobody is able to set it all up correctly, nobody uses an M0404 (before you say it is key) and you are just alone in your practice.

In the end it doesn't matter much what we all do wrong, as long as you are not able to tell how to do it right. Ok ?

If you are right in the first place, which you are not, and from which you may benefit if you give it some open mind.

 

In the end I don't care much what your observations are, but I do care about people saying there can't be a difference because they don't perceive it. Also, there's sufficient debate by now on *how* these things happen, never mind they often spring or sprung from my own ideas about it.

 

"Software doesn't matter" is what you imply, but you must notice that you are quite alone on that these days;

Earlier I implied that maybe your software is so good that in there it doesn't matter indeed. Who knows. But you know, the funny thing is that software thus still matters. Yours is better than mine in that case. No problem.

But now proove that mine is not bit perfect. ... Or whatever it takes to convince you of something you just don't want to hear. And again, I don't care, but please don't imply that others who do perceive the difference within ONE second, are deaf or fools. I know you didn't say that (at all !), but it's what's implied.

 

Best regards,

Peter

 

[ziggyzack]

Peter, I was referring to Linn's DS players (it stands for digital stream).

 

[PeterSt]

Eloise ... I think you are asking for the known answers. You know I can do that ... if "graphically" is still allright with you. And if this isn't a satisfactory answer, just ask any random (developing) person, and you know the question isn't even legit (because nobody can).

 

What about just listen like anybody else in my environment can do it. Or ask the question there, and see what happens (I'll stay out).

 

Sorry ...

Peter

 

[Miska]

nobody uses an M0404 (before you say it is key) and you are just alone in your practice

 

It's just one of my ~10 different audio interfaces. And I'd guess they have sold quite many units. I know people using it and I find it nice for making room acoustics measurements for the purpose of digital room correction.

 

Another is hardware based on ice1712/ice1724 variants which are used by tons of different audio interfaces (ESI Juli@ etc). And then there's of course RME.

 

But now proove that mine is not bit perfect.

 

This is quite uninteresting from my perspective, so I don't even bother checking. Even though it would be trivial task to loop back S/PDIF output and compare it to file contents.

 

If someone believes tweaking driver parameters makes audible difference, then there are probably software for that. On Linux one could also freely start tweaking all the hardware device drivers and the operating system, since all the source code is available.

 

My emphasis is on having best possible DSP algorithms for various purposes and multichannel playback. Others may have different emphasis, and that's good, there's something to choose from.

 

[Miska]

I suppose I'd better mention that DSs have a gargantuan 2 second buffer...

 

Yep, network streaming, especially internet streaming requires large buffers. No problem with that.

 

And so far the discussion was just about the audio device ring buffer size. There are naturally other buffers too. And some which are more or less outside of application's control, like disk caches inside harddisk and operating system.

 

Modern HDDs have already 64 MB caches...

 

 

[manisandher]

Miska said, "... the buffer size doesn't matter for the sound quality..."

 

I beg to differ. Changing the buffer size on either my RME AES-32 or Weiss AFI1 DOES change the sound! And yes, my system is indeed set up properly.

 

Miska, I really like HQPlayer, especially its simplicity of use. The DSP algorithms may well be state of the art, but you know what, HQPlayer sounds different when installed into RAMDisk rather than an SSD. It's actually quite a lot better from RAMDisk.

 

Mani.

 

[PeterSt]

Hi Miska,

 

I think it is great what you said in the end because it is really there we you (or we for that matter) differentiate.

I think this is not even a matter of the fameous "agree to disagree", but just agree as how I would like to feel it from a professional perspective.

 

On the subject of this thread, I'd like to emphasize (as if it wasn't done before) that here the computer at least *really* matters, and understandably matters (use DSP for the best possible sound quality). That I live on that other side is just nice for living next to eachother, and it can well be said that I can't what you can. Period.

 

In any case, thank you for your politeness, which can't always be said from me.

Peter

 

[PeterSt]

Peter, just to put this in context, your comments about lower latency improving SQ

 

Eliose,

 

I had to rush during my previous answer, so I guess it sounded (pun :-) like that.

 

But let's be careful on the proper interpretation of this all. I mean, I don't think I said lower latency is better, but anyway I do say it matters for SQ in general.

 

Also, it is a kind of tough to "explain" this, before assuming this was just a generally known fact for years (and years). This is why I said my mood got strange from reading those last 40 posts this morning. Also, this *is* on every forum (for those years), and sometimes I wonder how "we" here can miss it all. And, of course, this is not only about the general idea, but also about listening capabilities, of which I won't say "you" are deaf, but in the mean time I wonder what you guys think you are doing at setting the buffer size of e.g. a Weiss. So *if* you do, I expect you to perceive the difference automatically, instead of someone needing to tell you it is so. Still it doesn't happen, and sometimes it makes communication difficult. That's why my suggestion of asking it elsewhere (with my own forum as an example), with the underlaying suggestion you will be a kind of shot when doing that on e.g. AA. It's just too much known, and instead you will receive the question to proove it the other way around (that bad it is).

 

The intrigueing part of course (well, for me) is what is is what Windows X meant by it, because it doesn't seem to fit what he wants, or why. No problem, just intrigueing, and that's why my initial response today in the first place.

 

In the far end ... who cares about this all while we are adult enough to hear the difference on this subject - or not (I mean, you don't need to be told or nursed on this). As long as others claiming the difference are respected as well, instead of the suggestions that his Esoteric etc. can be replaced by a random mac book or anything. This is NOT true (at all), and next we must be careful that we're on par with our own ears when someone with better (which we will never know) suggests things we can't get.

 

That was the long answer.

 

Shall we now proceed with the necessity of burning in downloads ?

Now THAT is a laugh (for those who read it). It still can be true though. Do you think I heard differences because of such a thing ? do you think I tried ? No, because I can't believe it hence reason out why. But I'd NEVER say it's not possible because *I* don't perceive it, or just "know" it can't be so; too many times in the past years things turned out to matter afterall (and were as unbelieveable).

 

What's left (as a good thing to do), is "just listen" and try to perceive it, or do not when you don't want to spend the time, think it is foolish to begin with, or whatever other reason you respectfully have to not know.

That's why the more brieef "just listen" in the earlier post.

 

Peter (who actually doesn't want to express Eliose doesn't believe in this all)