24 Aug
2010
24 Aug
'10
2:13 p.m.
Hi,
I've decided to get back to diagnosing why my delta 1010 inputs have a
background noise and stumbled across a few websites indicating that the
problem could be irq sharing.
My delta shares irq 20 with usb devices:
$ cat /proc/interrupts |grep ICE
20: 1325915 1326971 1335010 1348560 1337725
1330100 1336582 1346152 IO-APIC-fasteoi ehci_hcd:usb1,
uhci_hcd:usb2, ICE1712
Is there a way to forcibly assign ICE1712 to another IRQ? I just want
to test the theory.
thanks
David
24 Aug
24 Aug
3:54 p.m.
On Tue, Aug 24, 2010 at 5:10 AM, David Santamauro
<david.santamauro(a)gmail.com> wrote:
Hi,
I've decided to get back to diagnosing why my delta 1010 inputs have a
background noise and stumbled across a few websites indicating that the
problem could be irq sharing.
My delta shares irq 20 with usb devices:
$ cat /proc/interrupts |grep ICE
20: 1325915 1326971 1335010 1348560 1337725
1330100 1336582 1346152 IO-APIC-fasteoi ehci_hcd:usb1,
uhci_hcd:usb2, ICE1712
Is there a way to forcibly assign ICE1712 to another IRQ? I just want
to test the theory.
thanks
David
IRQ's and their numbering are physical things. Their assignment is
made, fundamentally, when the motherboard is designed and is hardwired
based on the PC board traces. You cannot change those.
For desktop machines the control you do have is to move PCI devices to
different PCI slots. Asus motherboards are usually pretty good about
calling out what slots share interrupts with other devices. Check your
MB manual.
If you don't have a manual use your eyes and think about the whole IRQ
list. (Not just the part you showed.) Look for another PCI card that
seems to be on an interrupt by itself and then switch that card with
your sound card.
For USB devices, if you have multiple USB controllers and _if_ they
use different IRQs, then you may be able to choose a different
controller by choosing a different USB connector to plug into. Move
your USB devices if this appears to be true about your motherboard.
(It is on many of mine...)
Note that sharing IRQs with a USB controller isn't necessarily bad. It
depends on what sort of USB device is attached, how its driver is
written, and how many interrupts it generates. However, all things
being equal, it's better if everything is completely separated as that
allows very little interaction.
Hope this helps,
Mark
5:16 p.m.
Mark,
On Tue, 24 Aug 2010 06:54:30 -0700
Mark Knecht <markknecht(a)gmail.com> wrote:
On Tue, Aug 24, 2010 at 5:10 AM, David Santamauro
<david.santamauro(a)gmail.com> wrote:
Manual says PCI at irq 20.
Hi,
Is there a way to forcibly assign ICE1712 to another IRQ? I just
want to test the theory.
IRQ's and their numbering are physical things. Their assignment is
made, fundamentally, when the motherboard is designed and is hardwired
based on the PC board traces. You cannot change those.
For desktop machines the control you do have is to move PCI devices to
different PCI slots. Asus motherboards are usually pretty good about
calling out what slots share interrupts with other devices. Check your
MB manual.
If you don't have a manual use your eyes and think about the whole IRQ
list. (Not just the part you showed.) Look for another PCI card that
seems to be on an interrupt by itself and then switch that card with
your sound card.
For USB devices, if you have multiple USB controllers and _if_ they
use different IRQs, then you may be able to choose a different
controller by choosing a different USB connector to plug into. Move
your USB devices if this appears to be true about your motherboard.
(It is on many of mine...)
Note that sharing IRQs with a USB controller isn't necessarily bad. It
depends on what sort of USB device is attached, how its driver is
written, and how many interrupts it generates. However, all things
being equal, it's better if everything is completely separated as that
allows very little interaction.
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.
David
5:30 p.m.
On Tue, Aug 24, 2010 at 8:13 AM, David Santamauro
<david.santamauro(a)gmail.com> wrote:
Mark,
On Tue, 24 Aug 2010 06:54:30 -0700
Mark Knecht <markknecht(a)gmail.com> wrote:
David,
Well, at first blush that implies to me this has nothing to do with
interrupts. Is the any card good? Have you tried it in another system?
This was a long time ago in my chip design architect history but I
helped write one of the early versions of the PCI-x spec for bridging
devices. IIRC PCI-x host controllers were supposed to correctly handle
both 32-bit and 64-bit PCI cards when plugged into those slots so
(according to the original spec written maybe 12 years ago) if your
card physically plugs into whatever connectors your MB provides it
should work. (I.e. - PCI-x slows down to become PCI.) However if you
had any PCI-x cards they would slow down also. Not a problem in your
case it seems.
Obviously we don't want to damage anything so I'd check your MB
manual on this, as well as looking at any BIOS for any settings or
clues about allowing PCI cards in PCI-x slots. You'll find a
supporting position here:
http://en.wikipedia.org/wiki/Pci-x
As long as your card is a modern PCI card it's likely it will work
but be careful and read your docs first.
Cheers,
Mark
On Tue, Aug 24, 2010 at 5:10 AM, David
Santamauro
<david.santamauro(a)gmail.com> wrote:
Manual says PCI at irq 20.
Hi,
Is there a way to forcibly assign ICE1712 to another IRQ? I just
want to test the theory.
IRQ's and their numbering are physical things. Their assignment is
made, fundamentally, when the motherboard is designed and is hardwired
based on the PC board traces. You cannot change those.
For desktop machines the control you do have is to move PCI devices to
different PCI slots. Asus motherboards are usually pretty good about
calling out what slots share interrupts with other devices. Check your
MB manual.
If you don't have a manual use your eyes and think about the whole IRQ
list. (Not just the part you showed.) Look for another PCI card that
seems to be on an interrupt by itself and then switch that card with
your sound card.
For USB devices, if you have multiple USB controllers and _if_ they
use different IRQs, then you may be able to choose a different
controller by choosing a different USB connector to plug into. Move
your USB devices if this appears to be true about your motherboard.
(It is on many of mine...)
Note that sharing IRQs with a USB controller isn't necessarily bad. It
depends on what sort of USB device is attached, how its driver is
written, and how many interrupts it generates. However, all things
being equal, it's better if everything is completely separated as that
allows very little interaction.
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.
David
5:58 p.m.
On Tue, 24 Aug 2010 08:30:39 -0700
Mark Knecht <markknecht(a)gmail.com> wrote:
On Tue, Aug 24, 2010 at 8:13 AM, David Santamauro
<david.santamauro(a)gmail.com> wrote:
the card works fine on the same hardware under 64-bit windows7. I'm
trying to get it working 100% in fedora 12 64-bit with an rt-kernel
(multi-os machine). I agree, interrupts are probably not the issue.
Last time I was fiddling with this problem I had suspected 64-bit
linux drivers as it works in the 32-bit machine I have.
Mark,
On Tue, 24 Aug 2010 06:54:30 -0700
Mark Knecht <markknecht(a)gmail.com> wrote:
David,
Well, at first blush that implies to me this has nothing to do with
interrupts. Is the any card good? Have you tried it in another system? On Tue, Aug 24, 2010 at 5:10 AM, David
Santamauro
<david.santamauro(a)gmail.com> wrote:
Manual says PCI at irq 20.
Hi,
Is there a way to forcibly assign ICE1712 to another IRQ? I just
want to test the theory.
IRQ's and their numbering are physical things. Their assignment is
made, fundamentally, when the motherboard is designed and is
hardwired based on the PC board traces. You cannot change those.
For desktop machines the control you do have is to move PCI
devices to different PCI slots. Asus motherboards are usually
pretty good about calling out what slots share interrupts with
other devices. Check your MB manual.
If you don't have a manual use your eyes and think about the whole
IRQ list. (Not just the part you showed.) Look for another PCI
card that seems to be on an interrupt by itself and then switch
that card with your sound card.
For USB devices, if you have multiple USB controllers and _if_ they
use different IRQs, then you may be able to choose a different
controller by choosing a different USB connector to plug into. Move
your USB devices if this appears to be true about your motherboard.
(It is on many of mine...)
Note that sharing IRQs with a USB controller isn't necessarily
bad. It depends on what sort of USB device is attached, how its
driver is written, and how many interrupts it generates. However,
all things being equal, it's better if everything is completely
separated as that allows very little interaction.
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.
David This was a long time ago in my chip design
architect history but I
helped write one of the early versions of the PCI-x spec for bridging
devices. IIRC PCI-x host controllers were supposed to correctly handle
both 32-bit and 64-bit PCI cards when plugged into those slots so
(according to the original spec written maybe 12 years ago) if your
card physically plugs into whatever connectors your MB provides it
should work. (I.e. - PCI-x slows down to become PCI.) However if you
had any PCI-x cards they would slow down also. Not a problem in your
case it seems.
Obviously we don't want to damage anything so I'd check your MB
manual on this, as well as looking at any BIOS for any settings or
clues about allowing PCI cards in PCI-x slots. You'll find a
supporting position here:
http://en.wikipedia.org/wiki/Pci-x
I read that as well, but my MB pci-x slots are (apparently) backwards
(pardon my ignorance)
see page 7
http://www.tyan.com/manuals/m_s5396_120.pdf
... backwards, meaning, I'd have to stick the card in backwards.
David
25 Aug
25 Aug
10:34 a.m.
--- On Tue, 8/24/10, David Santamauro <david.santamauro(a)gmail.com> wrote:
From: David Santamauro
<david.santamauro(a)gmail.com>
Subject: Re: [LAU] irq sharing
To: "Mark Knecht" <markknecht(a)gmail.com>
Cc: "LAU" <linux-audio-user(a)lists.linuxaudio.org>
Date: Tuesday, August 24, 2010, 11:55 AM
On Tue, 24 Aug 2010 08:30:39 -0700
Mark Knecht <markknecht(a)gmail.com>
wrote:
this has nothing to do with
wow, how backward! (pun intended :)
Would a PCI ribbon extender like this one help ?
http://www.plinkusa.net/webR1PCI1-1R.htm
I know you can find PCI risers of various length. I used to use one in my mini ITX
multimedia server some long time ago. Don't remember the specs now but that should
allow you to twist things back to a normal position (hopefully).
J.
On Tue, Aug 24, 2010 at 8:13 AM, David
Santamauro
<david.santamauro(a)gmail.com>
wrote:
>
> Mark,
>
>
> On Tue, 24 Aug 2010 06:54:30 -0700
> Mark Knecht <markknecht(a)gmail.com>
wrote:
>
>> On Tue, Aug 24, 2010 at 5:10 AM, David
Santamauro
>> <david.santamauro(a)gmail.com>
wrote:
>> >
>> > Hi,
>> >
>> >
>> > Is there a way to forcibly assign
ICE1712 to another IRQ? I just
>> > want to test the theory.
>> >
>>
>> IRQ's and their numbering are physical
things. Their assignment is
>> made, fundamentally, when the
motherboard is
designed and is
>> hardwired based on the PC board traces.
You
cannot change those.
>>
>> For desktop machines the control you do have
is to move PCI
>> devices to different PCI slots. Asus
motherboards are usually
>> pretty good about calling out what slots
share interrupts with
>> other devices. Check your MB manual.
>>
>> If you don't have a manual use your eyes and
think about the whole
>> IRQ list. (Not just the part you
showed.)
Look for another PCI
>> card that seems to be on an interrupt by
itself and then switch
>> that card with your sound card.
>
> Manual says PCI at irq 20.
>
>>
>> For USB devices, if you have multiple USB
controllers and _if_ they
>> use different IRQs, then you may be able
to
choose a different
>> controller by choosing a different USB
connector to plug into. Move
>> your USB devices if this appears to be
true
about your motherboard.
>> (It is on many of mine...)
>>
>> Note that sharing IRQs with a USB controller
isn't necessarily
>> bad. It depends on what sort of USB
device is
attached, how its
>> driver is written, and how many
interrupts it
generates. However,
>> all things being equal, it's better
if
everything is completely
>> separated as that allows very little
interaction.
>
> 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.
David
David,
Well, at first blush that implies to me interrupts. Is the any card good? Have you tried
it in
another system?
the card works fine on the same hardware under 64-bit
windows7. I'm
trying to get it working 100% in fedora 12 64-bit with an
rt-kernel
(multi-os machine). I agree, interrupts are probably not
the issue.
Last time I was fiddling with this problem I had suspected
64-bit
linux drivers as it works in the 32-bit machine I have.
This was a long time ago in my chip
design architect history but I
helped write one of the early versions of the
PCI-x
spec for bridging
devices. IIRC PCI-x host controllers were
supposed to
correctly handle
both 32-bit and 64-bit PCI cards when plugged
into
those slots so
(according to the original spec written maybe 12
years
ago) if your
card physically plugs into whatever connectors
your MB
provides it
should work. (I.e. - PCI-x slows down to become
PCI.)
However if you
had any PCI-x cards they would slow down also.
Not a
problem in your
case it seems.
Obviously we don't want to damage
anything so I'd check your MB
manual on this, as well as looking at any BIOS
for any
settings or
clues about allowing PCI cards in PCI-x slots.
You'll
find a
supporting position here:
http://en.wikipedia.org/wiki/Pci-x
I read that as well, but my MB pci-x slots are (apparently)
backwards
(pardon my ignorance)
see page 7
http://www.tyan.com/manuals/m_s5396_120.pdf
... backwards, meaning, I'd have to stick the card in
backwards.
David
_______________________________________________
Linux-audio-user mailing list
Linux-audio-user(a)lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-user
11:04 a.m.
On Tue, Aug 24, 2010 at 8:55 AM, David Santamauro
<david.santamauro(a)gmail.com> wrote:
<SNIP>
No, the PCI-X slots aren't backwards but you __MIGHT__ have a card
that cannot be inserted safely.
Look at page 30. Notice that the PCI connector (very bottom) matches
up against the __length__ of the first two sections of PCI-X 64-bit
connector. (Just above it) That's where the PCI-X spec expects the PCI
card to be placed.
The reason you are thinking it's backwards is because of the way the
smallest section of each connector is positioned. However that's not
what's really going on with the cards.
There are two kinds of PCI cards - those with a single indentation in
the gold connector area on the card and those with two indentations.
Cards with a single indentation required 5 volts (IIRC) and those with
2 indentations did not. A PCI card with two indentations only used 3.3
volts and can be safely inserted in the PCI-X connector because that
second indentation allows it to fit. If the card doesn't have two
indentations then that piece of plastic in the connector (which is
making you think things are backward) will keep the card out and thus
protect it from voltages that it's not designed to use.
Again, go slowly and maybe find a copy of the spec to read. I am doing
this from memory circa 1997 so it's very vague and should be verified
somewhere. I've never actually owned a PCI-X machine - the spec never
because important in the retail market but is much loved in the server
market where lots of RAID controllers do PCI-X.
Hope this helps, and again, BE CAREFUL!
- Mark
David,
Well, at first blush that implies to me this has nothing to do with
interrupts. Is the any card good? Have you tried it in another system?
the card works fine on the same hardware under 64-bit windows7. I'm
trying to get it working 100% in fedora 12 64-bit with an rt-kernel
(multi-os machine). I agree, interrupts are probably not the issue.
Last time I was fiddling with this problem I had suspected 64-bit
linux drivers as it works in the 32-bit machine I have.
This was a long time ago in my chip design
architect history but I
helped write one of the early versions of the PCI-x spec for bridging
devices. IIRC PCI-x host controllers were supposed to correctly handle
both 32-bit and 64-bit PCI cards when plugged into those slots so
(according to the original spec written maybe 12 years ago) if your
card physically plugs into whatever connectors your MB provides it
should work. (I.e. - PCI-x slows down to become PCI.) However if you
had any PCI-x cards they would slow down also. Not a problem in your
case it seems.
Obviously we don't want to damage anything so I'd check your MB
manual on this, as well as looking at any BIOS for any settings or
clues about allowing PCI cards in PCI-x slots. You'll find a
supporting position here:
http://en.wikipedia.org/wiki/Pci-x
I read that as well, but my MB pci-x slots are (apparently) backwards
(pardon my ignorance)
see page 7
http://www.tyan.com/manuals/m_s5396_120.pdf
... backwards, meaning, I'd have to stick the card in backwards.
David
2:15 p.m.
On Tuesday 24 August 2010 21:42:53 Mark Knecht wrote:
There are two kinds of PCI cards - those with a single
indentation in
the gold connector area on the card and those with two indentations.
Cards with a single indentation required 5 volts (IIRC) and those with
2 indentations did not. A PCI card with two indentations only used 3.3
volts <snip>
Nope, the cards with two indentations run with both 5V or 3.3V. The ones with
one indentation have the voltage hard-coded by the position (back or front)
and don't run with the other voltage at all. Even if you break out the saw to
make them fit...
Have fun,
Arnold
2:30 p.m.
On Wed, 25 Aug 2010 14:15:35 +0200
Arnold Krille <arnold(a)arnoldarts.de> wrote:
On Tuesday 24 August 2010 21:42:53 Mark Knecht wrote:
both the delta and the 2496 have two indentations. I *may* just try and
stick it in my 64-bit box alongside the delta, although frying it
wouldn't be a good thing... needs more thought and research first.
David
There are two kinds of PCI cards - those with a
single indentation
in the gold connector area on the card and those with two
indentations. Cards with a single indentation required 5 volts
(IIRC) and those with 2 indentations did not. A PCI card with two
indentations only used 3.3 volts <snip>
Nope, the cards with two indentations run with both 5V or 3.3V. The
ones with one indentation have the voltage hard-coded by the position
(back or front) and don't run with the other voltage at all. Even if
you break out the saw to make them fit...
5:45 p.m.
On Wed, Aug 25, 2010 at 5:27 AM, David Santamauro
<david.santamauro(a)gmail.com> wrote:
On Wed, 25 Aug 2010 14:15:35 +0200
Arnold Krille <arnold(a)arnoldarts.de> wrote:
David,
Arnold is probably right about me having the description backward.
I know from serving on some of the committee that wrote these bus
specs (PCI-X, 1394a, 1394b, etc.) that the intention was ALWAYS to be
user-friendly and safe to hardware. My intention earlier was simply to
help you see how you might possibly be able to do more with your
hardware than you previously realized was possible.
Still, as I said early in this thread, I don't believe that the
noise you are experiencing is interrupt-based, nor do I believe that
changing slots is likely to help. The root cause almost certainly lies
elsewhere and we just don't understand it yet.
Should you be interested in using your empty PCI-X slots for
something else then look around for something you don't mind killing
should that happen. An old NIC card or possibly an old PCI-based VGA
card sleeping in a dusty box in the dark garage somewhere and try that
first. No reason to subject your most important audio cards to this
sort of a experiment before you know it works with other things less
important.
Post back more info and we can try to guess what is really going on here.
- Mark
On Tuesday 24 August 2010 21:42:53 Mark Knecht
wrote:
both the delta and the 2496 have two indentations. I *may* just try and
stick it in my 64-bit box alongside the delta, although frying it
wouldn't be a good thing... needs more thought and research first.
David There are two kinds of PCI cards - those with a
single indentation
in the gold connector area on the card and those with two
indentations. Cards with a single indentation required 5 volts
(IIRC) and those with 2 indentations did not. A PCI card with two
indentations only used 3.3 volts <snip>
Nope, the cards with two indentations run with both 5V or 3.3V. The
ones with one indentation have the voltage hard-coded by the position
(back or front) and don't run with the other voltage at all. Even if
you break out the saw to make them fit...
9:04 a.m.
On Tue, Aug 24, 2010 at 8:13 AM, David Santamauro <
david.santamauro(a)gmail.com> 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-soundc…
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.
10:42 a.m.
Hi,
On Tue, 24 Aug 2010 12:46:06 -0700
Niels Mayer <nielsmayer(a)gmail.com> wrote:
On Tue, Aug 24, 2010 at 8:13 AM, David Santamauro
<
david.santamauro(a)gmail.com> wrote:
interesting angle ...
envy24control (and the new mudita24) register this noise on input
whether devices are plugged in or not. So the noise is clearly coming
from either the delta breakout, card or driver. I've ruled out the
breakout box and card simply by the fact that the noise doesn't exist
on the same hardware with windows7 drivers.
There is no problem on any of the 10 outputs.
[ snip ]
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-soundc…
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' 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.
jackd controls the delta 100% of the time.
-- 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.
I will, thanks
David
26 Aug
26 Aug
11:08 a.m.
David Santamauro wrote:
Hi,
On Tue, 24 Aug 2010 12:46:06 -0700
Niels Mayer <nielsmayer(a)gmail.com> wrote:
Or the Windows drivers are doing something that removes the noise?
I have a friend who has a Delta 1010LT in his WindowsXP-based audio
workstation. He's never said anything about input noise.
--
David
gnome(a)hawaii.rr.com
authenticity, honesty, community
On Tue, Aug 24, 2010 at 8:13 AM, David Santamauro
<
david.santamauro(a)gmail.com> wrote:
interesting angle ...
envy24control (and the new mudita24) register this noise on input
whether devices are plugged in or not. So the noise is clearly coming
from either the delta breakout, card or driver. I've ruled out the
breakout box and card simply by the fact that the noise doesn't exist
on the same hardware with windows7 drivers. 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-soundc…
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'
4:26 p.m.
On Thu, Aug 26, 2010 at 2:08 AM, david <gnome(a)hawaii.rr.com> wrote:
David Santamauro wrote:
That would imply that everyone using a 1010LT in Linux would
experience the same noise, correct?
If I understand, you are saying that the card, with nothing plugged
into it, shows noise coming out of the card? If so it sounds like a
bad card.
If he's local can you ask your Windows friend to plug your card into
his system for testing and see if it's noisy or not? Good weekend
project if he's game.
- Mark
Hi,
On Tue, 24 Aug 2010 12:46:06 -0700
Niels Mayer <nielsmayer(a)gmail.com> wrote:
Or the Windows drivers are doing something that removes the noise?
I have a friend who has a Delta 1010LT in his WindowsXP-based audio
workstation. He's never said anything about input noise.
On Tue, Aug 24, 2010 at 8:13 AM, David Santamauro
<
david.santamauro(a)gmail.com> wrote:
interesting angle ...
envy24control (and the new mudita24) register this noise on input
whether devices are plugged in or not. So the noise is clearly coming
from either the delta breakout, card or driver. I've ruled out the
breakout box and card simply by the fact that the noise doesn't exist
on the same hardware with windows7 drivers. 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-soundc…
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'
4:35 p.m.
Hi,
On Thu, 26 Aug 2010 07:26:42 -0700
Mark Knecht <markknecht(a)gmail.com> wrote:
On Thu, Aug 26, 2010 at 2:08 AM, david
<gnome(a)hawaii.rr.com> wrote:
not necessarily...
Maybe limiting that statement to: 1010LT in linux 64-bit fedora 12 (my
case) -- you could probably even add add driver version.
David Santamauro wrote:
That would imply that everyone using a 1010LT in Linux would
experience the same noise, correct?
Hi,
On Tue, 24 Aug 2010 12:46:06 -0700
Niels Mayer <nielsmayer(a)gmail.com> wrote:
Or the Windows drivers are doing something that removes the noise?
I have a friend who has a Delta 1010LT in his WindowsXP-based audio
workstation. He's never said anything about input noise.
On Tue, Aug 24, 2010 at 8:13 AM, David Santamauro
<
david.santamauro(a)gmail.com> wrote:
> thanks for the time. I only have one PCI slot, but 3 empty PCI-x
interesting
angle ...
envy24control (and the new mudita24) register this noise on input
whether devices are plugged in or not. So the noise is clearly
coming from either the delta breakout, card or driver. I've ruled
out the breakout box and card simply by the fact that the noise
doesn't exist on the same hardware with windows7 drivers.
If I understand, you are saying that the card, with nothing plugged
into it, shows noise coming out of the card? If so it sounds like a
bad card.
In my situation, I can reliably say it is not the card or breakout box
as this input noise is non-existent in windows7 on the same hardware.
David
9:45 p.m.
Mark Knecht wrote:
On Thu, Aug 26, 2010 at 2:08 AM, david
<gnome(a)hawaii.rr.com> wrote:
Oh, I'm not the original poster. Although that could be something the
original poster might try. IIRC, he mentioned that the noise isn't there
under Windows7 or 32-bit Linux. Only 64-bit Linux.
David Santamauro wrote:
That would imply that everyone using a 1010LT in Linux would
experience the same noise, correct?
If I understand, you are saying that the card, with nothing plugged
into it, shows noise coming out of the card? If so it sounds like a
bad card. Hi,
On Tue, 24 Aug 2010 12:46:06 -0700
Niels Mayer <nielsmayer(a)gmail.com> wrote:
Or the Windows drivers are doing
something that removes the noise?
I have a friend who has a Delta 1010LT in his WindowsXP-based audio
workstation. He's never said anything about input noise.
On Tue, Aug 24, 2010 at 8:13 AM, David Santamauro
<
david.santamauro(a)gmail.com> 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-soundc…
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'
interesting angle ...
envy24control (and the new mudita24) register this noise on input
whether devices are plugged in or not. So the noise is clearly coming
from either the delta breakout, card or driver. I've ruled out the
breakout box and card simply by the fact that the noise doesn't exist
on the same hardware with windows7 drivers. If he's local can you ask your Windows friend to
plug your card into
his system for testing and see if it's noisy or not? Good weekend
project if he's game.
That's worth checking.
Another a idea for original poster: Boot your existing hardware from a
live Linux audio distro such as Ubuntu Studio or Musix or ArtistX or
some such, and see if the noise exists. Just in case it's some obscure
setting somewhere?
--
David
gnome(a)hawaii.rr.com
authenticity, honesty, community
9:56 p.m.
On Thu, 26 Aug 2010 09:45:05 -1000
david <gnome(a)hawaii.rr.com> wrote:
Another a idea for original poster: Boot your existing hardware from
a live Linux audio distro such as Ubuntu Studio or Musix or ArtistX
or some such, and see if the noise exists. Just in case it's some
obscure setting somewhere?
Doing that now ... thanks
David
10:42 p.m.
Working with 1010LT on debian testing 64-bit, I can hear some hiss at 96 KHz. Noise
vanishes in lower samplerates. I guess it comes from the motherboard.
My 2 cents,
Roman
On Thu, 26 Aug 2010 15:52:43 -0400
David Santamauro <david.santamauro(a)gmail.com> wrote:
On Thu, 26 Aug 2010 09:45:05 -1000
david <gnome(a)hawaii.rr.com> wrote:
--
Another a idea for original poster: Boot your existing hardware from
a live Linux audio distro such as Ubuntu Studio or Musix or ArtistX
or some such, and see if the noise exists. Just in case it's some
obscure setting somewhere?
Doing that now ... thanks
David
_______________________________________________
Linux-audio-user mailing list
Linux-audio-user(a)lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-user
27 Aug
27 Aug
9:13 p.m.
New subject: irq sharing / delta 1010 input hiss
Hi Roman,
On Thu, 26 Aug 2010 22:41:56 +0200
Roman <intxixu(a)gisa-elkartea.org> wrote:
Working with 1010LT on debian testing 64-bit, I can
hear some hiss at
96 KHz. Noise vanishes in lower samplerates. I guess it comes from
the motherboard.
My goodness, what a revelation! I can't believe changing the sample
rate to 48000, down from 96000 actually eliminates the hiss. I sort-of
understand why, just that I never thought of doing it as a means to fix
the problem -- wow, I feel like I missed the forest being blocked by a
big tree.
For now, I thank all that had something to say in my fight with this
problem from irq's and pci-x to live distributions and power
testing (alsa list advice).
I'll will now slowly dismantle all the hacks I had to get music into my
computer and start making it again with my beloved delta 1010.
Thank you
David
/crossing fingers/
24 Aug
24 Aug
3:55 p.m.
On Tue, Aug 24, 2010 at 8:10 AM, David Santamauro
<david.santamauro(a)gmail.com> wrote:
Hi,
I've decided to get back to diagnosing why my delta 1010 inputs have a
background noise and stumbled across a few websites indicating that the
problem could be irq sharing.
My delta shares irq 20 with usb devices:
$ cat /proc/interrupts |grep ICE
20: 1325915 1326971 1335010 1348560 1337725
1330100 1336582 1346152 IO-APIC-fasteoi ehci_hcd:usb1,
uhci_hcd:usb2, ICE1712
Is there a way to forcibly assign ICE1712 to another IRQ? I just want
to test the theory.
it depends on your motherboard and your BIOS. on most laptops, there
is no way. since have a 1010, its not a laptop, so you'll have to
check the BIOS to see if it offers control over interrupt assignments.
mine does not, for example.
4:26 p.m.
Excerpts from David Santamauro's message of 2010-08-24 14:10:12 +0200:
Hi,
I've decided to get back to diagnosing why my delta 1010 inputs have a
background noise and stumbled across a few websites indicating that the
problem could be irq sharing.
My delta shares irq 20 with usb devices:
$ cat /proc/interrupts |grep ICE
20: 1325915 1326971 1335010 1348560 1337725
1330100 1336582 1346152 IO-APIC-fasteoi ehci_hcd:usb1,
uhci_hcd:usb2, ICE1712
Is there a way to forcibly assign ICE1712 to another IRQ? I just want
to test the theory.
thanks
David
A few BIOSes allow that, plugging it into another slot might help as
well. I'm not sure there is a software way to do it. I'm not sure
whether the rtirq script does something like that or just changes
priorities.
--
Philipp
--
"Wir stehen selbst enttäuscht und sehn betroffen / Den Vorhang zu
und alle Fragen offen." Bertolt Brecht, Der gute Mensch von Sezuan
4:33 p.m.
On Tue, 24 Aug 2010, Philipp Überbacher wrote:
> Is there a way to forcibly assign ICE1712 to
another IRQ? I just want
> to test the theory.
[snip]
well. I'm not sure there is a software way to do it. I'm not sure
whether the rtirq script does something like that or just changes
priorities.
rtirq just changes priorities... not IRQ assignments.
-gabriel
4998
days inactive
5001
days old
linux-audio-user@lists.linuxaudio.org
21 comments
10 participants
participants (10)
-
Arnold Krille -
david -
David Santamauro -
Gabriel M. Beddingfield -
James Warden -
Mark Knecht -
Niels Mayer -
Paul Davis -
Philipp Überbacher -
Roman