error401
1000+ Head-Fier
- Joined
- Oct 11, 2006
- Posts
- 1,244
- Likes
- 11
Quote:
This poster knows enough to get into trouble, but not enough to actually understand what he's talking about. First of all, there are necessarily buffers on the soundcard to deal with this. All practical buses operate in the same asynchronous fashion. No soundcard can ever expect to get data off the bus at exactly the sample rate, and therefore there must be a (small amount of) memory on the card to buffer the data coming from the CPU. Your playback happens from this buffer. Latency is something else entirely, and also has nothing to do with sound quality. It's largely irrelevant in this context, it makes no difference to us whether there is 5ms or 100ms of delay between the decoder and the actual sound being created. The bits are the same, the DAC timing is the same (and has nothing to do with the bus timing) - where is the difference? As long as the bus is not so saturated that it can't keep the soundcard buffer full, there will be no difference whatsoever.
Also, trying to minimize transfer on the PCI bus is folly with all but the newest computers and chipsets. Most consumer motherboards up until the last year or so have only a single PCI bus that is also shared among onboard hardware like the IDE or SATA controller that he advocates the use of. Chances are very good that your IDE drive is also passing data to the CPU via the very same bus that your soundcard is on (crap, those engineers still don't know how to deal with bus sharing after 50 years). Only recently has PCIe begun gaining traction as the primary system bus, and in such cases your PCI bus is probably implemented as a bridge to PCIe - oh noes the bus is shared with the hard drive still, tragedy for sound quality! CPU interfaces are expensive to implement, and thus are generally minimized as much as possible. There will generally be one CPU->RAM bus and one CPU->I/O bus in each computer. If multiple I/O interfaces are required (ie. PCIe, PCI, USB, IDE etc.) they are all implemented on the fastest bus available using a bridge or controller where appropriate.
Finally, if your soundcard needed to monopolize the PCI bus as much as this guy suggests, your computer would be next to useless. The bus standard provides guidelines for mastering, and the arbitrator forces bus masters to give up control of the bus when their time is up. If your soundcard can't operate properly under the constraints the bus imposes, it's broken (hello Creative with your broken bus mastering...).
Anyway, I'm feeding here...sorry...
| Originally Posted by Patrick82 /img/forum/go_quote.gif Don’t play music from USB drives and Network |
This poster knows enough to get into trouble, but not enough to actually understand what he's talking about. First of all, there are necessarily buffers on the soundcard to deal with this. All practical buses operate in the same asynchronous fashion. No soundcard can ever expect to get data off the bus at exactly the sample rate, and therefore there must be a (small amount of) memory on the card to buffer the data coming from the CPU. Your playback happens from this buffer. Latency is something else entirely, and also has nothing to do with sound quality. It's largely irrelevant in this context, it makes no difference to us whether there is 5ms or 100ms of delay between the decoder and the actual sound being created. The bits are the same, the DAC timing is the same (and has nothing to do with the bus timing) - where is the difference? As long as the bus is not so saturated that it can't keep the soundcard buffer full, there will be no difference whatsoever.
Also, trying to minimize transfer on the PCI bus is folly with all but the newest computers and chipsets. Most consumer motherboards up until the last year or so have only a single PCI bus that is also shared among onboard hardware like the IDE or SATA controller that he advocates the use of. Chances are very good that your IDE drive is also passing data to the CPU via the very same bus that your soundcard is on (crap, those engineers still don't know how to deal with bus sharing after 50 years). Only recently has PCIe begun gaining traction as the primary system bus, and in such cases your PCI bus is probably implemented as a bridge to PCIe - oh noes the bus is shared with the hard drive still, tragedy for sound quality! CPU interfaces are expensive to implement, and thus are generally minimized as much as possible. There will generally be one CPU->RAM bus and one CPU->I/O bus in each computer. If multiple I/O interfaces are required (ie. PCIe, PCI, USB, IDE etc.) they are all implemented on the fastest bus available using a bridge or controller where appropriate.
Finally, if your soundcard needed to monopolize the PCI bus as much as this guy suggests, your computer would be next to useless. The bus standard provides guidelines for mastering, and the arbitrator forces bus masters to give up control of the bus when their time is up. If your soundcard can't operate properly under the constraints the bus imposes, it's broken (hello Creative with your broken bus mastering...).
Anyway, I'm feeding here...sorry...
