On Sat, 2004-01-17 at 16:36, Tim Blechmann wrote: > > The relevant interrupts (from /proc/interrupts) looks like this: > > 9: XT-PIC Ricoh Co Ltd RL5c476 II (#2), Intel 82801CA-ICH3, hdsp > > 11: XT-PIC Ricoh Co Ltd RL5c476 II, wlan0, usb-uhci, usb-uhci, > > usb-uhci, ohci1394, radeon@PCI:1:0:0 > this is still more than on my interrupt 11, which can be configured only > to be used by the cardbus controller and the hdsp ... > > btw ... might my problems come from the agp graphic device? i have > absolutely no idea how the agp port is addressed by the cpu, but since > nearly everyone thinks that my problem is interrupt related (although i > think i tried everything, dealing with interrupts) ... is it possible > that there are agp interrupts sent that somehow interfere with the hdsp? > just a guess since i have no ideas any more ... Tim, I doubt it's AGP causing the problems. I guess it's possible, but I don't think it's likely. AGP devices are a super set of PCI. They have PCI config spaces and sit on what looks (in some ways) like a PCI bus. However that bus is physically completely separate from all of your PCI and cardbus buses, so I don't think it's real likely. As I've watched you go through this (rather painful) debug I must say that after everything you've done I also think that it is possibly an interrupt problem. My thought is that (unfortunately) either the cardbus controller or the PC chipset itself is somehow missing every other interrupt coming from the RME cardbus card. In this idea the first interrupt gets through, the system sends the first block of data, and then the second interrupt is lost. When the 3rd interrupt arrives the system thinks it's the second interrupt and send the data. This sort of misoperation would possibly result in something looking like the waveforms you recorded. (I think) To delve a bit further into this idea, I think you should consider transmitting a known waveform and look carefully at what is actually transmitted. RME's web site has some sine waves (or used to) that are meant for purposes like this. If you transmit a known waveform at a known frequency you should be able to tell if the HDSP is operating at the right rate (or wrong rate) and what (if anything) is missing. As you send this data possibly you can collect info from cat /proc/interrupts and see how many interrupts are generated. One problem with Alsa is that you don't know (or I don't know) what its default settings are for plain Alsa transmissions. I'm finding that playing alsaplayer for 10 seconds at 44.1K seems to generate about 440 interrupts every 10 seconds. I suppose that means 44 interrupts/second with a block size of 1K bytes? If you transmit for a known time and get a different number of interrupts then that's probably important. You could also try this with Jack where you can change block sizes and gather more info. Beyond that, and I don't think you'll like this idea, but it would make a *lot* of sense to install Windows on this laptop as a dual boot configuration and test that. It is a lot of work, but then you could tell whether the problem is specifically that the hardware just doesn't work or whether it's a Linux specific problem. Maybe this is not even hardware or Alsa, but rather a kernel issue and how it handles your cardbus chipset? I think the kernel guys, or who ever works on cardbus, would want info like this. I wish you the best of luck. This one has been difficult. I hope you come to a good solution. With best regards, Mark
