Difference in digital sources

Page 5 - Seeking answers? Join the What HiFi community: the world's leading independent guide to buying and owning hi-fi and home entertainment products.

manicm

Well-known member
one off:

cant believe im reading this thelc you are totally correct in everything you say

cant be bothered commenting any more yes the world is flat, the creationists are right and i believe everything the belt man says

If the engineers in this thread concede some possibilities, and even one Linn engineer (goto Linn DS forums), then perhaps they too are of the flat-earth society.

Now, personally, I don't think the storage medium makes a difference under normal circumstances, but in extreme cases they may.

I will leave open any possibilities however, as I believe in the digital audio world, there should be, but not always is there a so-called bit-perfect sound.

With the exception of master recordings like Linn's downloads I will always use the original CD as the reference.
 
A

Anonymous

Guest
manicm:

If the engineers in this thread concede some possibilities, and even one Linn engineer (goto Linn DS forums), then perhaps they too are of the flat-earth society.

Now, personally, I don't think the storage medium makes a difference under normal circumstances, but in extreme cases they may.

I will leave open any possibilities however, as I believe in the digital audio world, there should be, but not always is there a so-called bit-perfect sound.

With the exception of master recordings like Linn's downloads I will always use the original CD as the reference.

im an engineer so will you believe me know

sorry some of the posts have been more about smoke and mirrors rather than computer science
 

idc

Well-known member
So far, out of all the 'engineers' storsvante has been the only one to put forward a well reasoned argument that digital sources cannot make a difference. Other 'engineers' who 'cannot be bothered' to develop their argument achieve nothing.

For me the answer is; there is no difference between digital sources (the reason being error checking). But the only way to listen to a digital source is with analogue equipment. The differences lie with the analogue equipment used. If the same analogue equipment is used with different digital sources, the differences are there (or not as the case may be) from psychoaccoustical reasons.

I also think that the language used in such discussions plays a major part in fuelling the debate. The words used often suggest major differences in sound, but IMHO the differences are minor and many cannot 'tune into' and hear them.
 
A

Anonymous

Guest
I agree with the general conclusion that it is unlikely or for some parts of the chain even unthinkable that there are differences. But you need to study the actual design to see where the weak points are or could be. That could be a very reasonable discussion as the OP has shown. In parts of the pc chain datatransfer is either error corrected (data is retransmitted if there is an error) or with a very wide margin of error that is possible thanks to the fact that the signal is digitally encoded, so that the chance that a signal on/off is missed (the block waves mentioned earlier) in the transmission is avoided completely. In analogy: computer tweakers are able to overclock processors beyond their spec's, and this goes well up to a certain threshold after which complete crashes occur. Under normal conditions however this is no problem and everything is 'bit perfect'. Another analogy: this week I discussed the connection of a multipanel lcd display to a computer system, using dvi-d. This is an extremely high bandwidth connection for uncompressed hires video data (compared to this audio streams are nothing), but despite that this is 'digital' dvi-d cables longer than 5m or so caused clear artefacts, This is probably another example of a datastream (like USB-audio) in which there is no error correction, just a transfer mode that functions flawless but only up to the level of the spec's.

So if we want this to become a reasonable discussion let's focus on the question: what are the weak points? And what can be ignored? And what can we do about the weak points? Several have been mentioned already, based on sound insights, but it depends on 'us' as the forum users if this will lead to education or abuse.
 

idc

Well-known member
one off:

this is now a pointless discussion shame it started so well

Sorry one off but you are wrong. I am very glad Tony_R has come back to make more contributions to this thread and the latest contributions from KeithAR and Pete10 have been very good. They may well be wrong (as I), but they are polite, reasoned and part of the debate. I made a subtle comment directed at you one off about friends before, which has not worked. So now the unsubtle approach. If your attitude was friendly, reasoned and more detailed then you and everyone else would enjoy the benefits of your contributions. At the moment you are just an annoyance.
 
A

Anonymous

Guest
sorry idc im a techie and dont wear fool gladly discuss to your hearts content but its an empty discussion since you cant avoid the reality

you can argue as much as you like about the earth being flat but theres an established breality in the end you cant ignore

anyway carry on to your hearts content it passes a sundy afternoon i suppoose im off to clean up the shed now oh orders
 

daveh75

Well-known member
one off:
sorry idc im a techie and dont wear fool gladlyIn which case, why not enlighten us with your knowledge with some reasoned and explanatory responses?Rather than your usual one liner/throw away comment's that add nothing to the discussions.....
 

The_Lhc

Well-known member
Oct 16, 2008
1,176
1
19,195
Visit site
KeithAR:
I have picked up on this thread this morning, as I often read through the What-Hi-Fi Forums with a lot of interest, however I thought I'd sign up for an account this morning to comment on this post.

I'd have to admit that I agree with Tony_R's opinions / observations he has stated in his post.

I myself, have conducted a lot of different experiements / tests, be it with varying different devices, different sound cards in my PC, professional audio interfaces (for music recording) - and external USB sound cards. I've also tried various different CD players with different DAC's.

One of the tests I did do, was rip an audio CD to 'lossless FLAC' - I then used a Creative Sound Blaster Audigy External Sound Card to output both an Optical Digital connection, and a Coaxial Digital connection to my hi-fi from my computer. I also installed an ASIO driver to eliminate any changes Windows might make to the sound on it's output or at an equalisation level, as I didn't want anything to get in the way of the sound so to speak.

My results were interesting, I found that even though I played music through both the optical and the coaxial outputs into a DAC plugged into my hi-fi, a CD player plugged into the same DAC playing the same CD I had ripped losslessly, still sounded better directly from a CD Transport.

I have in the past observed audible noise at high volumes from a computer sound card over Co-Ax into an external DAC. I've also observed audible differences between different sound card's Digital outputs. Excluding the cable, I personally put this down to the differences in circuitry, and the way in which the signal is sent out from the computer through the Coax output.

That's all well and good Keith, and I'm not for one minute suggesting that other components in a PC won't affect sound quality (which is why I bypass the lot and stream to an external player) but none of those factors are relevant to the question of whether or not the storage device can affect the sound.

I'd also like to put forward an example of something still working despite missing information. Take a corrupt JPEG file for example on a hard drive. You'll often find that the JPEG file will indeed load, and display a large proportion of the picture, but there will indeed be parts missing due to corruption either on the hard disk itself, or the file itself.

Exactly, it's either because the file itself was damaged before or during the process of being written to the hard disk or it's because the hard disk itself is damaged, neither case is actually useful in this instance, when we talk about the "sound" of a component we do tend to assume that everything is functioning as it should. I can't recall seeing a thread like "My CD player sounds rubbish, it IS broken mind, do you think that will have something to do with it?", so there's just as little point in making exceptions for faulty hard disks. If it's broken, replace it, don't use it a prop for a bad argument.

Whilst a simple example, the same can be said for music, obviously on a less detrimental scale, as you'd be missing out entire chunks of music. However, my point is, that as a hard disk may fail to fully render a JPEG file due to corruption, there can indeed be some information loss, in the stream through the coax output that a DAC will fill in for so to speak, with oversampling, and what not.

No DAC is going to be able to fill in for the level of corruption you're referring to.
 

The_Lhc

Well-known member
Oct 16, 2008
1,176
1
19,195
Visit site
Tony_R: one off:to be fair thelhc is right though there cant be differences readin from an hard disk or an usb if they sound different the difference is coming from some other equipment further down the chain
I was trying to suggest that perhaps something was happening to the bit stream after it had been read off the disk.

No, you weren't, this is what you said:

Tony_R: It stands to reason that differences will be
heard (although an explanation escapes me) between different sources,
whether USB, hard disk or otherwise.
This surely must be for similar reasons that differences can be heard
between different CD transports (into the same DAC).

My rather
simplistic view is that ultimately these devices are "only" rendering
0's or 1's (aka bits) off their media (whether that media be hard disk,
USB stick or CD) - and therefore the only reason that differences can
be heard, are because these bits are not being accurately read from the
media.


My emphasis there, media in this case being the hard drive or USB stick.

With disks, you also need to consider fragmentation.

It doesn't matter, fragmentation hasn't been a serious issue in computers for years, besides, in most cases music libraries consist of large files being written sequentially to largely empty disks. Those files are then left in situ, invariably they won't get moved, or copied somewhere (and frankly it makes little difference to fragmentation if they are), they'll just stay there, occasionally being read, which also, will not cause fragmentation. If anything I should think that a music library hard disk will be LESS fragmented than a normal system disk, for example. The data is much more static and it's deletions and re-writes that cause fragmentation.

If a particular file is badly fragmented, will the allocated buffer be
able to hold enough data to allow the disk to complete the read from
the fragmented file?

Seriously? Do you know the read speed from a hard drive? It's vanishingly unlikely that this will ever happen.

What would happen if the buffer were too small? Would bits be lost, meaning that error correction would have to interpolate the missing bit(s), thereby affecting the sound?

No, if transmission to the buffer isn't quick enough, causing the buffer to empty, playback will simply stop. It has to, there's nothing there to play back. You can see this when you watch videos from YouTube over a connection that's too slow, everything stops until the buffer has re-filled. As for the buffer being too small, it's never going to happen, these aren't user-definable parameters (thank god!), the buffer is designed in the hardware to be the right size, if it isn't the device hasn't been designed properly.

Also - when any PC is reading data from media, whether it be USB / Hard disk / CDROM - if a read is unsuccessful it will be retried until it is either successful or fails (within limits set by the operating system).This is what gives the operating system the ability to cope with disk corruption.

Again - this would mean that any data buffer would need to be large enough to cache the datastream whilst these (re)reads are attempted. Please note: I am aware that this all takes place at a VERY high speed - however I'm playing 'devils advocate' here...

But again, you're talking about a situation where something is faulty, if you're going to go down that route then this is a pointless discussion, what would you say to someone who said "one of my speaker cables has a nick in it, do you think it's affecting the sound?", you'd say, might well be, best replace it for a good one, you wouldn't sit there discussing in what way it might affect the sound, or going and making a nick in your own speaker cable to see what happens would you?

We also need to consider the PC motherboard bus itself - i.e. the memory bus, PCI bus and associated interface cards.

No we don't, not in a conversation about whether or not digital media affect the sound, because none of those components above are media. Beside none of those components, including the media, are transferring audio, they're transferring data. Are you seriously suggesting that a computer of any kind is not capable of transferring data around its architecture without "losing" bits here and there? Can you not see that that would make functionality impossible?

In the average PC, there will be a lot of data being moved about on the various buses - could potential interuptions in data flow give rise to the changes heard in music streams? After all, there are only a limited number of IRQs (interrupts) available on PC hardware - and in a PC with many peripherals - in some cases with shared IRQs - is it possible that the datastream is being interupted, even momentarily?

That's why you have buffers. We're only dealing with audio here, the data rate for playback at the noisy end (ie the bit turning digital into analogue) is trivially slow compared to the speed that even a basic PC will be shifting data around internally, if there is an interruption it'll be so brief that the buffer probably won't even empty by 10%, the DAC itself sure as hell won't notice. I'm sorry but you're speculating based on almost zero knowledge now, you're not even close to clutching at straws at the moment. That's not an insult incidentally, it's just a fact.
 

Tony_R

Well-known member
Oct 20, 2008
17
0
18,520
Visit site
the_lhc:Tony_R: one off:to be fair thelhc is right though there cant be differences readin from an hard disk or an usb if they sound different the difference is coming from some other equipment further down the chain

I was trying to suggest that perhaps something was happening to the bit stream after it had been read off the disk.

No, you weren't, this is what you said:

Tony_R: It stands to reason that differences will be
heard (although an explanation escapes me) between different sources,
whether USB, hard disk or otherwise.
This surely must be for similar reasons that differences can be heard
between different CD transports (into the same DAC).

My rather
simplistic view is that ultimately these devices are "only" rendering
0's or 1's (aka bits) off their media (whether that media be hard disk,
USB stick or CD) - and therefore the only reason that differences can
be heard, are because these bits are not being accurately read from the
media.


I think the key words in that paragraph were "my rather simplistic view" is that.... - in other words I was summising, rightly or wrongly.

My emphasis there, media in this case being the hard drive or USB stick.

With disks, you also need to consider fragmentation.

It doesn't matter, fragmentation hasn't been a serious issue in computers for years, besides, in most cases music libraries consist of large files being written sequentially to largely empty disks. Those files are then left in situ, invariably they won't get moved, or copied somewhere (and frankly it makes little difference to fragmentation if they are), they'll just stay there, occasionally being read, which also, will not cause fragmentation. If anything I should think that a music library hard disk will be LESS fragmented than a normal system disk, for example. The data is much more static and it's deletions and re-writes that cause fragmentation.

This holds well for those people who create a one off copy of their library and that's that. But I'm sure there are many, many people who delete tracks (or entire albums) from their library, or even resample their music to a different bit rate etc. etc. All of which will without a doubt result in fragmentation, the scale of which depends on how much deleting / moving / resampling is being done. Is there a possibility that even re-writing the ID3 tag could result in a file being relocated to another portion of the disk?

If a particular file is badly fragmented, will the allocated buffer be
able to hold enough data to allow the disk to complete the read from
the fragmented file?

Seriously? Do you know the read speed from a hard drive? It's vanishingly unlikely that this will ever happen.

Of course I know the read speed of a hard drive - however even your own statement suggests this is a possibilty not to be discounted, however unlikely.

What would happen if the buffer were too small? Would bits be lost, meaning that error correction would have to interpolate the missing bit(s), thereby affecting the sound?

No, if transmission to the buffer isn't quick enough, causing the buffer to empty, playback will simply stop. It has to, there's nothing there to play back. You can see this when you watch videos from YouTube over a connection that's too slow, everything stops until the buffer has re-filled. As for the buffer being too small, it's never going to happen, these aren't user-definable parameters (thank god!), the buffer is designed in the hardware to be the right size, if it isn't the device hasn't been designed properly.

I was referring to very brief losses rather than a complete stop. Therefore it's feasible that if the buffer empties, even for a fraction of a second, that a single bit could be lost, and no bit (i.e. no data = 0) and hence incorrect data.

Also - when any PC is reading data from media, whether it be USB / Hard disk / CDROM - if a read is unsuccessful it will be retried until it is either successful or fails (within limits set by the operating system).This is what gives the operating system the ability to cope with disk corruption.

Again - this would mean that any data buffer would need to be large enough to cache the datastream whilst these (re)reads are attempted. Please note: I am aware that this all takes place at a VERY high speed - however I'm playing 'devils advocate' here...

But again, you're talking about a situation where something is faulty, if you're going to go down that route then this is a pointless discussion, what would you say to someone who said "one of my speaker cables has a nick in it, do you think it's affecting the sound?", you'd say, might well be, best replace it for a good one, you wouldn't sit there discussing in what way it might affect the sound, or going and making a nick in your own speaker cable to see what happens would you?

We also need to consider the PC motherboard bus itself - i.e. the memory bus, PCI bus and associated interface cards.

No we don't, not in a conversation about whether or not digital media affect the sound, because none of those components above are media. Beside none of those components, including the media, are transferring audio, they're transferring data. Are you seriously suggesting that a computer of any kind is not capable of transferring data around its architecture without "losing" bits here and there? Can you not see that that would make functionality impossible?

What I am trying to suggest is, that in a busy computer providing a constant stream of data to some playback device, interruptions in this data stream could feasibly happen. With software this isn't an issue, as a brief interuption whilst Word is loading results in perhaps a slight delay - but with a data stream? What happens if this stream is interupted? Even for a very brief period? Even considering your buffer comment below - if this data is so well buffered, why does Word hesitate during loading?

In the average PC, there will be a lot of data being moved about on the various buses - could potential interuptions in data flow give rise to the changes heard in music streams? After all, there are only a limited number of IRQs (interrupts) available on PC hardware - and in a PC with many peripherals - in some cases with shared IRQs - is it possible that the datastream is being interupted, even momentarily?

That's why you have buffers. We're only dealing with audio here, the data rate for playback at the noisy end (ie the bit turning digital into analogue) is trivially slow compared to the speed that even a basic PC will be shifting data around internally, if there is an interruption it'll be so brief that the buffer probably won't even empty by 10%, the DAC itself sure as hell won't notice. I'm sorry but you're speculating based on almost zero knowledge now, you're not even close to clutching at straws at the moment. That's not an insult incidentally, it's just a fact.

I'm not trying to prove or disprove anything. I'm not taking an engineering view to this. Hence there is no clutching at straws - whether I'm right or wrong here matters not to me, I'm just trying to express my views based on my own experience.

Finally - I have highlighted my answers in italic for clarity as without some HTML tweaking there doesn't appear to be any way of easily colouring the text (perhaps a hint for the forum deisgners?).

oops, italics don't seem to have worked either (apart from within the editor!)

Tony.
 
A

Anonymous

Guest
daveh75:one off:
sorry idc im a techie and dont wear fool gladlyIn which case, why not enlighten us with your knowledge with some reasoned and explanatory responses?Rather than your usual one liner/throw away comment's that add nothing to the discussions.....

dont usually contribute to empty discussions however i agree thoroughly with what the hlc says only he says it better than i could and has more patience

tonys answers are speculation at best or simply inaccurate and arent worthy of discussion at least to me he dosent even seem to understand fragmentation what causes it

your welcome to refute his ideas but for me life's too short sorry i hate discussing for discussings sake it reminds me of all the endless committee meetings i have to attend and i hate them too
 

Tony_R

Well-known member
Oct 20, 2008
17
0
18,520
Visit site
one off:daveh75:one off:

sorry idc im a techie and dont wear fool gladlyIn which case, why not enlighten us with your knowledge with some reasoned and explanatory responses?Rather than your usual one liner/throw away comment's that add nothing to the discussions.....

....... least to me he dosent even seem to understand fragmentation what causes it .....

Fragmentation is caused when data is written to disk, but a single stream (file if you like) cannot be written in a contigous fashion.

As files are "deleted" from the disk, the resulting "empty" spaces are flagged as available to the operating system, which will then try to use the next available empty space in which to create new data. This new data (file) can be written across multiple "empty" spaces, resulting in fragmentation of said file. What's not to understand?

Incidentally, I use the terms "deleted" and "empty" as I'm sure you know that data is not actually removed when a file is deleted, the space it occupies is simply flagged as available for use in the FAT.

The severity of this fragmentation depends on the type of file system, sector sizes etc, etc.

But then I'm sure you know this...

Tony.
 

The_Lhc

Well-known member
Oct 16, 2008
1,176
1
19,195
Visit site
one off: dont usually contribute to empty discussions however i agree thoroughly with what the hlc says only he says it better than i could and has more patience

Heh heh! Now THAT'S funny! I've been sitting here screaming at my screen!
emotion-2.gif
 

idc

Well-known member
Tony_R, keep your questions/speculations/ruminations on the subject coming
emotion-21.gif
. You are asking the kind of questions I would if I had more knowledge and I have learned a lot from this discussion so far.

The_lhc, can you clarify something for me. I have read the argument that data either works or it does not work before ( but for the first time with your responses I have read a proper explanation of why that is) but is that what you are arguing? Thanks.

One off, go away!
 

The_Lhc

Well-known member
Oct 16, 2008
1,176
1
19,195
Visit site
idc: The_lhc, can you clarify something for me. I have read the argument that data either works or it does not work before ( but for the first time with your responses I have read a proper explanation of why that is) but is that what you are arguing? Thanks.

err, I'm not sure, as in I'm not entirely sure what you're asking exactly.

I've been referring to the very specific situation of a computer (or NAS device or whatever) reading data from a Hard Drive or USB memory stick or any kind of solid state memory (such as SD card, or those new Solid State HDDs).

One thing I have been meaning to make clear is that this is not the same as an audio CD Player reading an audio CD in order to play it back. In that real-time situation you will certainly get missing data, which is where the interpolation (fancy word for guessing) skill of the CD player in question comes into play and could quite likely account for differences in sound between different CD players (even just transports).

Picking up on a comment in the Oppo-831 thread (sorry about that!) I would have imagined the same (the difficulty of real-time reading and reproduction of data on an optical disc) would be true for DVD and BD players, which may explain why different DVD/BD transports may sound/look different. None of that has any bearing on the question of how accurately the data can be read from magnetic storage device however, it was just a by-the-by sort of comment.
 

The_Lhc

Well-known member
Oct 16, 2008
1,176
1
19,195
Visit site
Hmmm, seem to have messed up the quotations here, I'll try to unpick it to make it more easier to follow:

Tony_R:the_lhc:Tony_R:

I was trying to suggest that perhaps something was happening to the bit stream after it had been read off the disk.

No, you weren't, this is what you said:

Tony_R: It stands to reason that differences will be
heard (although an explanation escapes me) between different sources,
whether USB, hard disk or otherwise.
This surely must be for similar reasons that differences can be heard
between different CD transports (into the same DAC).

My rather
simplistic view is that ultimately these devices are "only" rendering
0's or 1's (aka bits) off their media (whether that media be hard disk,
USB stick or CD) - and therefore the only reason that differences can
be heard, are because these bits are not being accurately read from the
media.


My emphasis there, media in this case being the hard drive or USB stick.

I think the key words in that paragraph were "my rather simplistic view" is that.... - in other words I was summising, rightly or wrongly.

Err, yes, and I've been trying to tell you that in this case you're wrong, however you don't seem to be prepared to accept that?

Tony_R:the_lhc:Tony_R: With disks, you also need to consider fragmentation.

It doesn't matter, fragmentation hasn't been a serious issue in computers for years, besides, in most cases music libraries consist of large files being written sequentially to largely empty disks. Those files are then left in situ, invariably they won't get moved, or copied somewhere (and frankly it makes little difference to fragmentation if they are), they'll just stay there, occasionally being read, which also, will not cause fragmentation. If anything I should think that a music library hard disk will be LESS fragmented than a normal system disk, for example. The data is much more static and it's deletions and re-writes that cause fragmentation.

This holds well for those people who create a one off copy of their library and that's that. But I'm sure there are many, many people who delete tracks (or entire albums) from their library, or even resample their music to a different bit rate etc. etc. All of which will without a doubt result in fragmentation, the scale of which depends on how much deleting / moving / resampling is being done. Is there a possibility that even re-writing the ID3 tag could result in a file being relocated to another portion of the disk?

Yes that's possible, but it STILL doesn't matter, and the reason is to do with the difference between the speed that the DAC needs to be fed data and the speed with which the file can be read from the disk, even a badly fragmented one. I'll pick this up a bit further down because you make another comment which can actually be answered at the same time.

What would happen if the buffer were too small? Would bits be lost, meaning that error correction would have to interpolate the missing bit(s), thereby affecting the sound?

No, if transmission to the buffer isn't quick enough, causing the buffer to empty, playback will simply stop. It has to, there's nothing there to play back. You can see this when you watch videos from YouTube over a connection that's too slow, everything stops until the buffer has re-filled. As for the buffer being too small, it's never going to happen, these aren't user-definable parameters (thank god!), the buffer is designed in the hardware to be the right size, if it isn't the device hasn't been designed properly.

I was referring to very brief losses rather than a complete stop. Therefore it's feasible that if the buffer empties, even for a fraction of a second, that a single bit could be lost, and no bit (i.e. no data = 0) and hence incorrect data.

But you're missing the point that a very brief interruption to the reading of data from the disk or storage wouldn't even be noticed, precisely because the DAC reads from its buffer and the buffer will never empty.

I'll come back here to the point about the relative speed that a DAC reads in audio data and the speed the PC can pump it out:

The data rate of Audio CD is 1411.2 kbit/s, or 0.1764MBytes/s (not a lot is it?), that's the rate the DAC will need to receive the digital audio at in order to replay it at normal speed.

This is 708 times SLOWER than Gigabit ethernet, 70.8 times slower than normal 100Mbit/s (about 12.5MBytes/s) Ethernet (surprisingly enough!), or 38 times slower than "g" standard WiFi transmission (54Mbit/s, 6.75MBytes/s, assuming a perfect signal obviously), so even over wireless you could theoretically stream 38 CDs AT CD QUALITY AT THE SAME TIME from the same source computer (You couldn't in reality but reality has had very little to do with this thread so far...).

Now, according to http://en.wikipedia.org/wiki/Hard_disk_drive (very interesting, read it, lots of stuff about the inbuilt error correction on HDDs), "as of 2008, a typical 7200rpm desktop hard drive has a sustained "disk-to-buffer" (that's the HDDs own internal buffer, not any other buffer we've been talking about) data transfer rate of about 70 megabytes per second", compared to the SATA bus which can transfer at 300Mbytes/s (so no bottleneck there),

Now, let's assume we're using something like Sonos, so the data is being passed from the PC to the Sonos via network (lets call it 100Mb network), the network card in your PC is connected via PCI bus (worse case scenario, much slower than PCI-X or PCIe), that has a transfer rate of 133MBytes/s from SATA bus to network card, so:

Disk-to-Buffer: 70MBytes/s,
Buffer-SATA bus-PCI Bus: 300Mbytes/s,
PCI Bus-Network Card: 133Mbytes/s,
Network Card to Sonos Zoneplayer: 12.5Mbytes/s.

Required input rate of DAC: 0.1764MBytes/s

The biggest bottleneck BEFORE the DAC in this situation is the network, assuming everything is running at perfect speed the PC can supply data to the DAC's buffer more than 70 times faster than the DAC can cope with it. So let's assume there are problems and everything's only working at 50%, you still have breathing room to the tune of 35 times what is required by the DAC.

Taking it even further, let's take the example of someone passing the data, not over the network, but to their sound card which just pumps it out its digital output straight into the DAC, now it's:

Disk-to-Buffer: 70MBytes/s,

Buffer-SATA bus-PCI Bus: 300Mbytes/s,

PCI Bus-Sound Card: 133Mbytes/s,

The disk is now the bottleneck, but you've now got a supply rate nearly 400 times what the DAC requires, so under what sort of circumstances would you expect the buffer to ever get empty? Your PC would have to be on its knees before it couldn't supply the DAC with data fast enough to cause an interruption and you'd have far bigger problems than not being able to listen to music.

Also - when any PC is reading data from media, whether it be USB / Hard disk / CDROM - if a read is unsuccessful it will be retried until it is either successful or fails (within limits set by the operating system).This is what gives the operating system the ability to cope with disk corruption.

Read that wiki page, the disk itself will deal with corruption, once it gets to a point where it can no longer do that the disk will have failed.

What I am trying to suggest is, that in a busy computer providing a constant stream of data to some playback device, interruptions in this data stream could feasibly happen.

And they probably do, all the time, it just doesn't matter as the required data rate of the playback device is so slow it requires virtually no effort on the part of the computer. I mean hell, an iPod can manage it, how much work can it possible require? Very little is the answer.

I'm not trying to prove or disprove anything. I'm not taking an engineering view to this. Hence there is no clutching at straws - whether I'm right or wrong here matters not to me, I'm just trying to express my views based on my own experience.

This has to be one of the most bizarre things I've ever heard! "whether I'm right or wrong matters not to me", why do you keep disagreeing with the facts that are being presented to you then and coming up with nonsense arguments against them? Are you actually saying you don't care that I've proved the data to the DAC can't be lost but you're going to carry on believing that it matters anyway? Why am I wasting my time then?
 
A

Anonymous

Guest
absolutely spot on and excellently put

lays this to rest i think
 

Tony_R

Well-known member
Oct 20, 2008
17
0
18,520
Visit site
the_lhc:
one off: lays this to rest i think

Not a chance!
emotion-2.gif


And so ends the "one off" and "the_lhc" show..

Be sure to tune in for next weeks episode!

emotion-4.gif
 

idc

Well-known member
Brilliant post the_lhc and you have answered my clumsy attempt at clarification. This bit really made me think

'And they probably do, all the time, it just doesn't matter as the required data rate of the playback device is so slow it requires virtually no effort on the part of the computer. I mean hell, an iPod can manage it, how much work can it possible require? Very little is the answer.'

That makes a lot of sense.
 
A

Anonymous

Guest
Hi all,

I read these forums quite regularly but this is the first time i have really felt i needed to make an input to a discussion. I am fairly interested in audio/home cinema stuff but am primarily a computer guy, I studied computer science and work in the industry on some pretty interesting things.

There seems to be some confusion about how a computer works, the main issue is people seem to be talking about playing an audio file in a computer as though it were some sort of streaming, and real time serial processing of data. This is how a CD player works or a DAC, they contain ASICs designed for very specific purposes and they way they process data is very different from how a general purpose processor does such as the one in your pc/mac.

It's quite hard to explain how a computer reads a file in a forum post and with my somewhat limited linguistic abilities due to being a computer science graduate :) but I will give it a go.

Firstly I will make a couple of statements

- The computer itself doesn't not know what the data is, nor is it concerned, the software and you the user are the only stakeholders in this process who have any conception of a file, audio, etc.

- The data held in RAM is not necessarily 100% correct as people have incorrectly stated previously, this is why mission critical systems use ECC RAM, however errors are extremely rare and generally only relevant to commands and addresses rather than data, switching a bit in a command or address will lead to a different function being performed than was intended, or performed on the wrong data; this is what causes hard crashes :)

- Computers are all about 0's and 1's

- the processor cannot perform functions on data held on a hard drive, ram or anything other than its internal registers everything must be transferred into the core logic of the processor (this includes from cache) before any math can be performed.

- I will be using some fairly in depth terminology, main memory is DRAM and is the stuff you buy in sticks, cache is fast SRAM on the processor die and a register is an internal location inside the core logic of the processor from where commands are stored, current working data is stored along with results.

- The clock (i.e 3.2ghz processor, 1600mhz fsb etc) is completly different to the clock that people talk about with audio, each tick of the clock on a processor indicates all transistors have finnished switching and data is now ready, on an fsb its when the voltages on the lines are correct and should be acted upon.

Please note that this explanation will be extremely abstracted and simplified, there is simply not the space to do a full explanation on a forum post. Also please understand that I am not a sound engineer nor do I have anything technical to do with sounds cards, so not everything may be entirely what happens in real life.

OK so thet's say we want to play an mp3 located on the primary hard drive, the OS will look up the physical addresses of the blocks on the hard drive which contain the file.

The OS will then make a call to the storage subsystem asking for those blocks to be copied to a specific address in main memory using DMA. simple error checking will occur to make sure the file was copied correctly, generally this is CRC, if this fails the faulty block will be re-read from the drive until it is or until a set number of retries when an error will be issued to the OS, now this may not necessarily be the whole file but that is irrelevant, the OS will have specified what to be loaded (remember the hardware has no knowledge of what the data is and has no concept of a file), as this is an mp3 we are talking about the whole file will have been loaded into main memory.

Various clever stuff happens here that I won't go into but basically the processor will be issued a load command, it will be given an address to read from and to which register to write it, a command will now be issued to the processor to perform a math function of some variety on this data, and to write the result back to a register. This data may or may not be further processed on but eventually it will be written to another location, this could be main memory, or it could be directly to a memory mapped device such as a graphics buffer. We will assume in this scenario that its written back to main memory, eventually (in reality a very short time for an mp3 on a modern computer) all/enough of the mp3 will have been decoded into main memory.

So now assuming we have an uncompressed version sitting in main memory it needs to get to the sound card, this may be through DMA directly to a memory mapped location or by other means, I'm not entirely sure as I mentioned above I don't write drivers for sound cards nor have much to do with them other than from a user standpoint. But its clear that at this stage there is no way for the initial storage device to have had any impact on audio quality

Hopefully what I have said above should give an idea of why the storage medium, controller and generally storage subsystem makes no difference to the audio quality. It should allow you to understand that jitter is not a factor at this stage, there is no 'timing' (in an audio sense) in terms of the data getting from the hard drive to the CPU in the same way as getting from a cd transport to a DAC,

Also the same applies to a USB stick, the storage controller is in the stick and commands are issued/ data sent across the USB bus, the same error correction applies here as well along with the conclusion that it doesn't matter where the data is read from in a pc as it always ends up being stored somehwhere else temporarily.

I will concede that this doesnt necesarrily apply to the reading of an audio cd on a computer as there is no error detection>retry process for playing cd audio as far as i know as standard.

Sorry for the huge post, any questions please ask
 

idc

Well-known member
Great post funkyraptor. As the forum simpleton can I sumarise what I think you are saying. A music file read from storage (USB stick, hard drive etc) goes, briefly to another part of the computers memory before being sent on to the soundcard/DAC. So the storage is not linked directly to the music file that leaves the computer, so how can it affect the sound?
 
A

Anonymous

Guest
Hi

Yes the data that makes up the file will have been stored in various different parts of the computer, and will have been processed and transfered over many different buses and devices. anything like jitter or data loss is completly removed by this process. another way to sort of explain the difference is that reading a mp3 off of a CD in a computer is a very different than playing a music cd in a cd player, in a simplified way i have tried to use a flow diagram to show how different the two processes are.

Music CD > transport > stream of binary data > audio DAC > analogue output

mp3 cd > transport > stream of binary data > serial to parallel converter > cd drive storage controller > chipset storage controller > memory controller > main memory > memory controller > front side bus> register > processor > register > processor > front side bus > memory controller > main memory > memory controller > front side bus > pci bus > audio DAC > analogue output

quite different :) all of the different buses have different speeds, a lot have different word lengths as well. and none of those bus speeds or word lengths will have even the slightest impact on the data nor the final output quality, the only parts which will are the math performed by the processor i.e the audio codec used, any extra processing done e.g. a software graphics equaliser, and the sound card itself. the rest of the process is no different to processing any other data, you dont see your photos degrading in quality as you transfer them around, nor do your word documents magically change as you copy them to and from the hard drive. If they did it would be rather annoying :)

The other thing to remember is that the data may not have necesarily been processed in order, also in a multiprocessor system differernt processors may have worked on different parts of the data at different times. Also the file will almost certainly have been spread out over multiple channels of RAM, so the file will have been split up and stored on different sticks of memory (in a similar way to RAID 0/5). another thing that just popped into mind is that the data will be switched between serial and parellel transfer methods multiple times during the process.

anyhoos i suggest anyone who has an interest in this subject have a good old peruse of wikipedia :) it can be quite interesting.
 

TRENDING THREADS