Re: FC4/x86_64 and ALSA: [long] noise and distortion

["Bryan J. Smith" <b.j.smith@ieee.org>]

Bryan J. Smith wrote:
> Correct.  You're reducing the amount of I/O traffic
> by 83% (1/6th) by turning off the 3D spacial aspects.
 
Nathaniel Reindl wrote:
> Er, wouldn't 1/6 be 16.7%?  83% is 5/6.

Sorry, I should have said:  
"reduce ... by 83% (1/6th of original)."

Or I could have been more clear with:  
"reduce ... by 83% (5/6th, 16% or 1/6th of original)."

> This doesn't explain the same behavior across my intel8x0
> and the es1370, though.

Yes it does.  The i810 and ES137x rely _even_more_ on the
CPU host, even for 2D audio, than the Emu10k.  The Emu10k
handles 2D, no problem, with little host (especially in
the "non-value" chipsets).  Even though the CPU load
might be under 10%, that can saturate the PCI bus.

Especially if you have ATA and NIC running on it.

In my case of a nForce4 with NIC on the HyperTransport
and ATA on PCIe x1 (I believe this is the arrangement),
my Realtek ALC650 can _saturate_ the PCI bus on its
own if I enable 3D audio -- in Windows XP Pro!

Some chipsets are better and worse in the I2C bus
control, adding to the problem.  I've found SiS to
have the greatest issues, although ViA 823x and even
some of Intel's early ICH series had some issues too.

> If the rest of these devices fall victim to the same
> thing, there must be some sort of laziness or
> pinheadedness that I'm not quite getting here.

AudioPCI (ES1370), also adopted in latter products
like the SBPCI 16, 64, 128, 256 (ES1371-1373), as well
the Intel i810, all Realtek ALC8xx series, etc...,
the host CPU bears the load.  Just like software RAID-5,
the problem isn't the actual CPU time for audio processing
like XORs in RAID-5 -- it's pushing all that data back
and forth through the CPU-memory-I/O interconnect.

The legacy 32-bit@33MHz PCI bus is a _measly_ 0.125GiBps.
The typical Intel MCH or a single AMD HyperTransport I/O
channel is capable of up to 8.0GBps, 64x more.  It
literally takes up a good chunk of PCI time to stream
a few seconds of real-time audio.  If that is interrupted,
by say some other PCI device (as all devices contend for
the same bus), then that is "choppy."

The more channels, the worse it gets.

With more and more audio channeling, and the more
bandwidth that is required.

> ALSA had this same problem back in 2002.  It's now
> 2005, and it still sucks in this regard.  What gives?

Host-based (software) audio processing, that's what gives.
The more you can put in software, the cheaper things get.

One of the primary reasons for PCIe is to get the ATA and
NIC off of the legacy PCI bus, so it's not trumping other
I/O.  Desktop audio is a big one (whereas most servers
already use dedicated PCI-X channels for disk and network).

> Nevertheless, I'll go ahead and try turning off all of the 3D
> stuff (if it exists) on my emu10k1 the next time I think about
> sticking it in here when I have the machine down for some 
> reason.

Check what modules are loading, and what options are available
for the main sound module.

I have a full SB Audigy2 and the driver is superb for 5.1,
even on an dual-Athlon MP with a shared PCI bus.  Granted,
it has 64-bit slots (so my 3Ware Escalade 7410 runs at
0.25GiBps), but it's also shared with NIC and audio (which
is bridged to the 0.125GiBps PCI slots).


-- 
Bryan J. Smith                 mailto:b.j.smith@ieee.org
Sent from Yahoo Mail (please excuse any missing headers)

-
To unsubscribe, send email to majordomo@silug.org with
"unsubscribe silug-discuss" in the body.