[linux-audio-user] RME Cardbus + multiface

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

 



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


[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