[NTLUG:Discuss] Re: inconsistent sound (revisited)

[Bryan J. Smith]

Someone brought up some valid complaints about my comments off-list.

1.  Bitrate is more than the actual data/digital stream

Samples and, even more so, work done in software does far more than taxi
just the CPU, but it involves massive amounts of I/O between the CPU and
main memory.  While the CPU-memory interconnect can handle it, the far
slower PCI bus may not.

Cheaper DSPs in audio cards do more in software and on the main CPU. 
They also have less on-chip SRAM, requiring more storage in memory. 
These _exponentially_ increase the amount of usage of the bus.

Usage is the key.  If a cheap DSP requires "response times" of several
times a second, if you have a burst of ATA or NIC traffic on the PCI
bus, then there will be some latency of that required DSP traffic. 
Hence the "inconsistent output."

If you have a quality DSP, it will typically require less software
control, possibly with enough SRAM on-chip to buffer possibly even a
second or two of playback.

2.  Windows and Linux performance may differ

When the DSP relies on more and more software, then the quality of the
software will factor.  Vendors typically provide optimized versions of
a 3rd party developed software driver for their cheap DSPs.  Linux
ALSA/OSS provides their own, generic software subsystem for these
cheaper DSPs, but they are typically not optimized for each (especially
for on-chip SRAM, specific capabilities, etc...).

As such, you may have a case where you are not getting issues with MP3
playback under Windows, but you are under Linux.  That's why a higher
quality DSP could work fine under Linux, but a cheap, on-board DSP logic
may not.

Again, let's revisit the original posters comments:
- On-chipset DSP has issues on Athlon 2GHz (XP2400+)
- Off-chipset Emu10k DSP does not on old Pentium III 500MHz

It is very, very difficult to show actual peripheral bus usage with
built-in Linux tools.  As such, you're not going to get anything out of
the typical CPU or VM stat tools that will help you.  Hence why these
considerations should be made out of "good system design."

Relying on cheap DSP components on a shared PCI bus is the problem.  Not
so much because of the traffic the DSP generates, but the fact that the
traffic can and will contend with that for the ATA and NIC.  And when
ATA and NIC burst through the PCI bus, the periods of the burst can
overrun the periods required for a cheap DSP to be software controlled.
 
Simple Test:  Put the Emu10k (SBLive) DSP in the Athlon 2GHz system and
see what happens.  You may want to try tweaking PCI settings in your
BIOS.

[ Note to self:  See if the Linux kernel offers any run-time PCI
tweaking ]

-- 
Bryan J. Smith                                  b.j.smith at ieee.org 
------------------------------------------------------------------ 
"Communities don't have rights. Only individuals in the community
 have rights. ... That idea of community rights is firmly rooted
 in the 'Communist Manifesto.'" -- Michael Badnarik