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

[Nathaniel Reindl <fiction@sdf.lonestar.org>]

On Thu, Jul 21, 2005 at 10:56:47AM -0700, Bryan J. Smith wrote:
> Today, we are pushing 64-256 voices at full 24-bit audio at 48MHz
> or even 96MHz, in stereo, if not 5.1, and that is _uncompressed_
> because the host is sending it to the audio chipset (which
> doesn't have any intelligence).  Just the stream coming back to
> the audio card for output can be over 10MBps (and even higher for
> 7.1), on a bus that is only 133MBps one-way _ideal_ (with no
> contension).

Read: 125MBytes/s practical

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.

... this is with the 3D features turned OFF, BTW.  2-channel stereo.
Not that I was sending anything to the other channels anyway.  (But,
mayhaps the driver just sends silence and eats bandwidth no matter
what?)

> That's not including any synthesis where there is a 2-4MB wave
> table sample in main memory that I/O is going on.  It's that
> "thrashing" over the I/O because there is *0* intelligence
> on-board that is the problem.  A good "test" is to reduce the
> quality of the output at the source application.  If it goes
> away, it's the I/O bottleneck.

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

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.

> I'm sure part of ALSA's problem is that sound cards are ideally
> configured (all channels) in Linux by default).  In Windows, it
> typically defaults to 2-channel and lower settings (although it
> depends on the installer, many are interactive).  And I'm sure
> the "independently created" ALSA programs aren't as "tuned" as
> the vendor's Windows drivers -- especially for its more "unified"
> wavetable approach in the case of synthesis.

Now, isn't this more a _software_ problem than it is a _hardware_
problem?  Shouldn't the software developers take into account that
interconnects _may_not_ be up to snuff for dealing with the traffic that
they're wanting to pull across them?  Accordingly, shouldn't they be
setting defaults that turn off all the options that may be saturating
the bus with data?  I mean, it makes sense.  And it goes with my mantra
of dealing only with software that does not suck.

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.

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.

==

As an aside, please do quit being an ALSA apologist.  Admit that it's
the software's fault and just walk away.  One stream being written to
/dev/dsp (and only one!) should not cause saturation like that.  It just
shouldn't.

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

-- 
Nathaniel Reindl    http://www.corvidae.org/
    unemployed monkey (hire me!) and college student
    class schedule: http://www.corvidae.org/schedule.html
Fedora Core 4 kernel 2.6.12-1.1398_FC4 on an AMD Opteron 240

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