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

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

Nathaniel Reindl <fiction@sdf.lonestar.org> wrote:
> Read: 125MBytes/s practical

I have never broken half that in actual usage with just one
bursting device.  Address, control and other details are mux'd on
some pins, and there are the setup and tear-down times on
transfers.

Contention is then the biggest killer as devices don't even get a
1MBps burst before something else takes control.
Everything from the slowest character devices to any on-board I/O
and other components are on the legacy PCI bus.

You can literally get far less than 10MBps out of a legacy PCI
bus if you're using programmed I/O for various device transfers,
depending on how much you're trying to push through.

> I'm not even pushing the practical limit with 44.1kHz stereo,
> but it still sounds like hell, and the PCI bus is very, very,
> very far from being saturated.  I'd give it another
100MBytes/s.

Just because it is capable of the bandwidth doesn't mean there's
not a device holding up the bus not using it optimally.  PCI is a
peripheral interconnect, _not_ a system interconnect (like
HyperTransport) where you burst data through at its optimal rate.
 Audio cards and many "character" devices are a major issue.

> ... this is with the 3D features turned OFF, BTW.  2-channel
> stereo.

Again, depends on how many voices.

> Not that I was sending anything to the other channels anyway. 
> (But, mayhaps the driver just sends silence and eats bandwidth
> no matter what?)

Anything that takes ahold of the PCI bus does exactly that.
That's what I meant by contention.

As I said, I have my NIC and my ATA on their _own_ interconnects
in the nForce4 (direct HyperTransport for the NIC, PCIe x1
channel for the ATA) and my ALC850 can saturate the PCI bus
anytime I enable a few features or turn up the number of voices.

And that is under _Windows_XP_!

> I don't care about synthesis.  Synthesis can easily be done
> with timidity++, so I'm not so concerned.  Yes, timidity eats
> up a ton of CPU, but I'm on a 1.4GHz Opteron, so that shouldn't
> be a big deal.

You _continue_ to miss the point!

The problem isn't the CPU load, it's the amount of data that
thrashes between the I/O and main memory over the measly PCI bus!
I/O that eats less than 5% of a CPU can _saturate_ a legacy PCI
bus.

> I'll live with that.  I'm talking straight-up 44.1kHz
> stereo audio playback plus some decoding.  In other words, 
> MP3s.

Which come back uncompressed from the CPU to memory down the PCI
bus to the card.  Depending on what format the MP3s are being
decoded into, you can eat up a lot of PCI time.

Which is why I said check the settings of the card at the _OS_
level, as well as in the program itself.  The compressed MP3
stream might only be 44.1KHz, 2-channel _before_ it is decoded,
but afterwards it might be decoded into a much higher rate for
your audio card.

What else is on your PCI bus (including on-mainboard
peripherals)?

> I did that test.  And I gronked my disk.  And I bombed the hell
> out of the few hosts on the network.  Individually at first and
> after that, at the same time.
> During audio playback, I noticed no change at all.

Okay then.  That's not the most ideal test, but it's still a
test.
It doesn't really give you much either way, although I guess I'd
have to hear the distortion to know.

> Save the rest of the engineering ``why''.  If there's a way to
> get the distortion to go away aside from staying up until the
> start of the semester, hacking up ALSA, and learning the 
> intimate details of how the Linux sound subsystem works, I
> want to know about it.  HOW, not WHY.

I have recommended you find the options for ALSA and verify
you are not putting the card into a mode that requires 2, 3 or
even 6+ times more bandwidth in the stream that comes from the
CPU.

I'm _not_ telling you to hack the kernel.  I'd do the same if
someone had the problem -- like I do -- where my ALC850 installer
under _Windows_XP_ enabled 3D audio by default and I was getting
choppy audio.

With a 2-channel, 32-voice program no less!

> Step-by-step would be totally groovy.  Bonus points for saving
> my wrists.  The CLI is for pinheads who haven't seen the joys
of
> painful RSI.

Hit the ALSA docs.  Otherwise I'll be typing a 50-step procedure
that might not even be applicable for your card.

The options are pretty module-specific.

> As an aside, please do quit being an ALSA apologist.

I'm not.  I said that the rather "generic" ALSA drivers are
_not_ going to be as "ideal" as the vendor's drivers.
I've seen this first-hand.

So far, the best features v. drivers support I've seen under
Linux is the Creative SB Audigy2 series.  I can jack up full
5.1 decoding on that sucker with UT2004 and it's no issue at
all.

> Admit that it's the software's fault and just walk away.

Okay, instead of blaming the audio driver configuration of my
ALC850 that is in 3D spatial, 2-channel mode, I'll blame
Windows XP.  That's _exactly_ what I'm talking about.

> One stream being written to /dev/dsp (and only one!) should
> not cause saturation like that.  It just shouldn't. 

It does, under Windows XP too.

> If this escalates into a flamewar, I'll be the first one to
> leave.

???

Honestly, if you can't have a technical discussion without being
offended, please _do_ leave!


-- 
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.