<div class="gmail_quote">On Tue, Aug 24, 2010 at 8:13 AM, David Santamauro <span dir="ltr"><<a href="mailto:david.santamauro@gmail.com">david.santamauro@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im">thanks for the time. I only have one PCI slot, but 3 empty PCI-x slots.</div>
<br>
I basically unplugged all USB devices as well as shut off both network<br>
interfaces and on board audio interface in the bios and the noise<br>
persists ...<br>
<br>
Not sure what to try next, this was a shot-in-the-dark.</blockquote><div><br></div><div>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:</div>
<div><a href="http://old.nabble.com/does-a-pci-e-x1-to-pci-adapter-work-with-Linux-soundcards-and-existing-drivers--td29444687.html">http://old.nabble.com/does-a-pci-e-x1-to-pci-adapter-work-with-Linux-soundcards-and-existing-drivers--td29444687.html</a> </div>
<div><br></div><div>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'</div>
<div><br></div><div><div>$ mplayer -quiet <a href="http://media.kcrw.com/live/kcrwlive.pls">http://media.kcrw.com/live/kcrwlive.pls</a> -ao alsa:device=66ch34</div><div>[...]</div><div>==========================================================================</div>
<div>Opening audio decoder: [mp3lib] MPEG layer-2, layer-3</div><div>AUDIO: 44100 Hz, 2 ch, s16le, 112.0 kbit/7.94% (ratio: 14000->176400)</div><div>Selected audio codec: [mp3] afm: mp3lib (mp3lib MPEG layer-2, layer-3)</div>
<div>==========================================================================</div><div>AO: [alsa] 44100Hz 2ch s16le (2 bytes per sample)</div><div>Video: no video</div><div>Starting playback...</div></div><div><br></div>
<div>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.</div>
<div><br></div><div>Playing the exact same stream using </div><div>$ gst123 -a alsa=66ch34 <a href="http://64.12.61.1:80/stream/1046">http://64.12.61.1:80/stream/1046</a></div><div>uses the correct format and so the playback sounds as intended.</div>
<div><br></div><div>I'm thinking that something similar w/r/t bit order/depth/complement/etc might be happening on record/capture from your 1010?</div><div><br></div><div>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.</div>
<div><br></div><div>-- Niels</div><div><a href="http://nielsmayer.com">http://nielsmayer.com</a></div><div><br></div><div>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.</div>
</div>