I think this is might be important. BTW - what's in your .soundrc
file?
i think you mean the .asoundrc:
Yes I did. Sorry.
Have you tried removing all of this stuff, or at least everything past the
first 8 lines? I have nothing of this level of sophistication in my
.asoundrc file and my HDSP 9652 works fine. Possibly all of this is somehow
creating a problem?
pcm.hdsp0 {
type hw
card 0
}
ctl.hdsp0 {
type hw
card 0
}
<SNIP>
Does Alsa audio work correctly with the Intel controller?
it does ... as well as
my old maudio quattro ...
That's good info I think.
Comment to Tim
- Tim, the slot you have chosen for the HDSP is using
IRQ 5. (the second O2 controller) Can you switch to the other slot and
take advantage of IRQ11 instead?
if i use the second pcmcia slot, i can manage to
run the hdsp on irq11
... anyway, there are quite a few devices on this irq, too (pcmcia,
on-board sound, usb, eth0) ... on irq5 there are only the pcmcia and the
usb controller ... i suppose it's not possible to get the hdsp to use
another irq than the corresponding pcmcia controller ... if i'm wrong,
please correct me...
No, TTBOMK it is not possible. The pcmcia controller (cardbus controller)
acts as a bridge to the secondary PCI/cardbus bus. The interrupt generated
by your HDSP card is handed to one side of this bridge and the bridge sends
it on to the main internal interrupt controller. The main point here is that
when the interrupt occurs the system needs to know where to go to determine
what the cause of the interrupt is. The interrupt may have come from your
HDSP, or it may have come from the bridge signaling some sort of error
condition, so a single interrupt line has to serve both error reporting
devices. (This is just a very generic description of what happens. Please
don't take it too literally.)
As was stated in a separate email from Alex, it's my opinion that having a
higher priority interrupt is more important than having an separate low
priority interrupt. In the configuration you have been using every mouse
interrupt, every hard drive interrupt, every FPU interrupt and every chipset
interrupt has higher priority than you sound card. This is not good.
If the sound card has to be shared with other controllers, like USB
Ethernet, etc., but it's high priority, then the data will move as quickly
as possible and with the fewest interruptions from other devices like your
drives doing DMA or your mouse just moving. If you want to see one effect of
mouse interrupts, start top on a quiet machine, let it stabilize, and then
start moving the mouse rapidly all over the place. Suddenly X starts using
lots of CPU cycles to essentially do nothing. You do not want your sound
card to be lower priority.
Firmware version: 5
Presumably this is the right version?
this is strange, true, i was using both
firmware revision 10 and 11
included in alsa-firmware ...
hum....
Is this Win XP
on this PC or you ran the card in a different PC?
i tried the devices on my laptop
and the laptop of my roommate ... winxp
and winme ... both worked fine...
Sorry. Still slightly confused. Is your laptop dual boot? If we are worried
about the laptop hardware, then this specific laptop running any version of
Windows and working well shows the problem is not the machine, but the way
Alsa configures the machine. (Or that's my thought right now...)
- Mark
