derek holzer wrote on Fri, 26-Mar-2004: Just to note, i don't think all Ricoh cardbus controllers cause problems. My Thinkpad A31 has a "Ricoh Co Ltd RL5c476 II (rev 80)" controller and my HDSP works great. I also was able to get it by itself on IRQ9, but not all BIOSs let you do that. Also, ACPI is definitely disabled. jlc

Tim Blechmann wrote: CardBus bridge: Ricoh Co Ltd RL5c476 II (rev a8) I ran the spectrum of problems, but them main issue was that the card would not make sound. Sometimes the card was not recognized, sometimes the card was recognized, but the firmware would not load. Other times, card was recognized, firmware was loaded, but I would get awful sound out of it like the problems you, Timothy and Ico report. But that was the last step along the way, and I could attribute it to bad IRQ assignment from ACPI, if I remember correct. But that only happened after a significant amount of "voodoo" with the recognition and the firmware with Planet-CCRMA. By "voodoo", I mean things like this: there were times, espc with Red Hat, where it seemed to work only after power cycling both the laptop and the multiface, but that was not a real solution. Changing distros was the final voodoo, but it seemed to do the trick. You can search the archives of Planet-CCRMA list for "derek+HDSP" for all the gorey details of my saga there, as I kept them very up to date on my woes. TCI 1420 and 1440 are listed as problem cards by RME. TCI 1225 shows up ok, though, so I imagine a 1250 is probably cool too. I maintain to this day it is something between the cardbus controllers, their kernel-drivers or modules, or the configurations thereof which creates this mess. I don't think the ALSA-dev folks have much power to correct this problem, although I would bet that their understanding of the upstream problems might be more educated than ours. My guess, along with Ico, is that kernel-dev folks might be the best resource, if you can document the issue well enough. Which is hard when you aren't sure excatly where it lies. good luck, D. -- derek holzer ::: http://www.umatic.nl ---Oblique Strategy # 196: "What else is this like?"

On Fri, 2004-03-26 at 16:08, Tim Blechmann wrote: Can we construct some sort of environment to test the problem and gather real data? For instance, if you play a sine wave in some application, and send it to a specific ADAT (or spdif) output, can you loop that ADAT (or spdif) output back into the same card and record it? Can you record it on another spdif enabled recorder and then compare the recordings? I'm unclear whether the same sine wave, transmitted on every output produces the exact same problem. Since cardbus controllers are essentially PCI bridges this means they have buffer memory that is written by DMA devices. Is this problem related to buffer memory being over used? Or is it purely a timing issue? Is the since wave going through the controller, but extra data (all zeros) is being inserted? This probably means an addressing problem as opposed to a data problem. If you install snd-dummy and run Jack can you show conclusively that there is no problem back inside the computer? While it's easy to say this is a card bus problem, what if it's related to some other part of the system? Some carefully constructed experiments could give us a better idea what's going on. Just asking... - Mark

Here's the update on the issue (at least from my aspect): TODO: 1) provide detailed lspci (will do later tomorrow, too tired right now) 2) thoroughly check /var/log/syslog for anything suspicious Apart from the ACPI and APIC problems, nothing out of the ordinary (i.e. APIC assigns IRQ 0 to cardbus and therefore nothing works, but if I disable APIC it's all ok. Furthermore, I've just yesterday fixed the ACPI and APIC problems by patching the kernel yet the problem persists. Right now the laptop boots with ACPI and APIC turned on, IRQ's get assigned properly, as a matter of fact EXACTLY the same like in Windows where the problem does not occur. Therefore, now the assumption that there is a "sweet" IRQ I need to select does not stand any more, as the same problem is exhibiting itself when the cardbus is at IRQ 11 (no ACPI/APIC) or at 17 (with ACPI/APIC and also the same IRQ as in WinXP). This now leads me to believe that the problem is strictly limited to the yenta_socket driver. 3) try pcmcia-cs (most likely won't work as Tim already tried that and it made no difference on his laptop, also the package wasn't updated since Dec.) This is not an option, as Tim pointed out, not only because this package only works with pre 2.5 kernels but also because it has been tested by Tim and had no difference. 4) try playback with an external Word Clock source Will try tomorrow (although I don't think so, as the card appears to work just fine on other Linux notebook). 5) provide downloadable examples of the distorted sounds (will do tomorrow). But by briefly looking at it, it definitely looks the same like Tim's (image found here: http://www.volny.cz/guitar_billy/hdsp.screenshot.png) where it seems like the sound has one small burst of audio data, then the comparably-sized streak of no change in data. There is still some distortion which I am not sure whether it is a result of this kind of misperformance of the sound or there is more to the story. 6) Pester alsa-dev, lau, and kernel/pcmcia people to death begging for help :-) IN-PROGRESS :-) 7) Pester eMachines to update BIOS (I may retire before this one happens, though) I did get through to someone and they did reply to my e-mail seeming interested in cooperating to resolve the issue, but at this point it does not seem like the BIOS is the culprit. 8) Something else? How about I go catch some z's :-) Good idea... Best wishes, Ico