Re: irq sharing

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

 



On Tue, Aug 24, 2010 at 8:13 AM, David Santamauro <david.santamauro@xxxxxxxxx> wrote:
thanks for the time. I only have one PCI slot, but 3 empty PCI-x slots.

I basically unplugged all USB devices as well as shut off both network
interfaces and on board audio interface in the bios and the noise
persists ...

Not sure what to try next, this was a shot-in-the-dark.

If you think it's a interrupt-sharing issue, consider using a pcie-to-pci riser to plug in your card. Apparently, this way of doing things may ensure less bus contention:
http://old.nabble.com/does-a-pci-e-x1-to-pci-adapter-work-with-Linux-soundcards-and-existing-drivers--td29444687.html 

Also, be sure that interrupt contention is really the problem. If it's a constant noise, there's a better chance that it's a different problem. One issue is that your recording software may not be using the same bit depth, alignment, or complement as what the card expects. I can get this effect on output, for example, simply by using 'mplayer'

$ mplayer -quiet http://media.kcrw.com/live/kcrwlive.pls -ao alsa:device=66ch34
[...]
==========================================================================
Opening audio decoder: [mp3lib] MPEG layer-2, layer-3
AUDIO: 44100 Hz, 2 ch, s16le, 112.0 kbit/7.94% (ratio: 14000->176400)
Selected audio codec: [mp3] afm: mp3lib (mp3lib MPEG layer-2, layer-3)
==========================================================================
AO: [alsa] 44100Hz 2ch s16le (2 bytes per sample)
Video: no video
Starting playback...

IMHO, the problem w/ mplayer is the fact that it passes on the "s16le" format of the stream straight to the soundcard. This results in something that sounds like the original signal, but superimposed with all sorts of garbage and noise.

Playing the exact same stream using  
$ gst123 -a alsa=66ch34 http://64.12.61.1:80/stream/1046
uses the correct format and so the playback sounds as intended.

I'm thinking that something similar w/r/t bit order/depth/complement/etc might be happening on record/capture from your 1010?

What happens when you setup jackd to talk to your soundcard? My experience is that Jackd seems to do the right thing w/r/t matching the bit order/depth/complement expected by the soundcard.

-- Niels
http://nielsmayer.com

PS: If this doesn't help, perhaps asking on the alsa-dev list may help? Alternately, perhaps someone from the ALSA project (Clemens Ladisch?)  may know about this problem and how to resolve it.
_______________________________________________
Linux-audio-user mailing list
Linux-audio-user@xxxxxxxxxxxxxxxxxxxx
http://lists.linuxaudio.org/listinfo/linux-audio-user

[Index of Archives]     [Linux Sound]     [ALSA Users]     [Pulse Audio]     [ALSA Devel]     [Sox Users]     [Linux Media]     [Kernel]     [Photo Sharing]     [Gimp]     [Yosemite News]     [Linux Media]

  Powered by Linux