[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



have you tried going through all your volume sliders for alsa and
turning them all down then bringing them up?  i experience the same
problem regularly, its like the linux drivers are trying to run the
cards too hot volume wise.  i just turn the volume sliders down and then
bring them up slowly until i find the sweetspot off maximum volume
without distortion.

hope this helps

Casey



Nathaniel Reindl wrote:

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


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