RE: snd-hdsp+cardbus=distortion -- the sagacontinues (cardbus driver=culprit?) UPDATE: 99.9% sure it is the cardbus driver yenta_socket

RE: snd-hdsp+cardbus=distortion -- the sagacontinues (cardbus driver=culprit?) UPDATE: 99.9% sure it is the cardbus driver yenta_socket

[Ivica Ico Bukvic]

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

Re: [linux-audio-user] snd-hdsp+cardbus=distortion -- the sagacontinues (cardbus driver=culprit?) UPDATE: 99.9% sure it is the cardbus driver yenta_socket

[Russell King]

On Tue, Mar 30, 2004 at 12:52:11AM -0500, Ivica Ico Bukvic wrote:
> 6) Pester alsa-dev, lau, and kernel/pcmcia people to death begging for help
> :-)
> 
> IN-PROGRESS :-)

What needs to happen is that the card driver author needs to investigate
what is going on, and, if it seems related to the core PCMCIA core or
the socket driver, we need to get involved.

IOW, linux-pcmcia people don't debug card drivers.

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:  2.6 PCMCIA      - http://pcmcia.arm.linux.org.uk/
                 2.6 Serial core

Re: [linux-audio-user] snd-hdsp+cardbus=distortion -- the sagacontinues (cardbus driver=culprit?) UPDATE: 99.9% sure it is the cardbus driver yenta_socket

[Tim Blechmann]

> What needs to happen is that the card driver author needs to
> investigate what is going on, and, if it seems related to the core
> PCMCIA core or the socket driver, we need to get involved.
he pointed out that it's probably a kernel problem ...

we don't want you to solve problems of the alsa driver, but we suspect
there is a problem with the cardbus bridge...

basics:
1.) the card is a combination of 2 devices: a interface device, either a
    pci or a cardbus card, and a dsp device, either digital or analog
    audio ... no problems have ever been reported about the pci
    interface, so it's likely to be a problem with the cardbus interface
    ... although i have to admit, that there are only 3 reported systems
    that have the problems, we experience ... but these systems are
    completely different ones (p4 / amd64, different cardbus bridges)

2.) the dsp device has an internal matrix mixer, that's independant from
    the computer (this audio data isn't sent to the computer at all) ...
    in fact it's possible to set the matrix mixer and unplug the dsp
    device from the computer ...

there are three problems, that show the situation:
3.) if we start an audio application that produces interrupts on the
    hdsp device, some of the audio data that's been transfered to the
    computer will be copied or mapped to the buffer of the audio data
    that's been transfered from the computer to the corresponding
    output. this could either happen
    - inside the device itself (i doubt that, since the same driver, the
      same firmware, the same devices are working without and problems
      on other linux machines or with windows on the same machine) 
    - inside the cardbus bridge 
    - inside the kernel 

4.) if we start the audio playback, the audio playback seems to be
    distorted: 
    one block of samples will be followed by one block of samples of 0
    (zero) ... note that these block are not the blocks of data, that
    are sent to the hdsp during one interrupt. it's usually 32 samples 
    of sound followed by 32 samples of silence, the driver sends blocks
    of 64 to 8192 during one interrupt depending on user settings...
    iirc one sample is 24 bit
    on the other hand the blocks of silence aren't missing, but the alsa
    layer will adapt, so that it takes twice as long as it should to
    play back a soundfile (i'm not sure if it's because of the alsa
    soundfile player or of the driver)

5.) the reason why we (or at least i) think, that it's a problem with
    the cardbus interface, is because of jack's output ...
    jack is both an audio connection interface for different softwares
    and a very good alsa implementation... using jack as super user
    in realtime mode, it complains about latency problems:
    
    delay of xxx usecs exceeds estimated spare time of yyy; restart ...

    at the default sample rate of 48000 xxx only about 0.06 % bigger
    than yyy ... on the other hand, i only get this error on sample
    rates of more than 32000 ... although the sound at 32000 is
    distorted, as well...
    
other thoughts i had:
6.) the distortion isn't affected by the block size / the number of
    interrupts ...
    it is affected by the samplerate ... that's why i think, there are
    always 32 samples (768 bit) followed by 32 samples of silence (768
    bit zero ???)
7.) the problems occured on different cardbus bridges:	
    ENE C1410 (ico / mandrake)
    o2micro6933 (myself / gentoo)
    Texas Instruments PCI1250 (timothy / red hat)

i don't know what's the reason for the problems, the latency or the
mapping problem, or if there is something else that results this problem
... but since it's a software and not a hardware issue (works fine with
windows), i'd like to get into it, and at least try to solve it ... but
since i'm neiter a kernel hacker nor i have any idea about the hardware
internals, i'd need some help from some people, who are able to help
me... i don't want some people to solve my problems for me, but i'd
appreciate any help of people, who know what's going on inside the
computer...

cheers ... 

 Tim                          mailto:TimBlechmann@gmx.de
                              ICQ: 96771783
--
The only people for me are the mad ones, the ones who are mad to live,
mad to talk, mad to be saved, desirous of everything at the same time,
the ones who never yawn or say a commonplace thing, but burn, burn,
burn, like fabulous yellow roman candles exploding like spiders across
the stars and in the middle you see the blue centerlight pop and
everybody goes "Awww!"
                                                          Jack Kerouac






-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click

Re: snd-hdsp+cardbus=distortion -- the sagacontinues (cardbus driver=culprit?) UPDATE: 99.9% sure it is the cardbus driver yenta_socket

[Tim Blechmann]

hi russel

> The majority of PCMCIA is the same between the two kernels.  There
> have been some cleanups and changes to the way card events (insertions
> and removals) occur, and some setup changes to the cardbus bridge to
> turn on some extra features.
> 
> However, if you're saying that 2.4 and 2.6 behave the same way, then
> logically it isn't something that any of these changes have caused.

i tried to use the pcmcia-cs driver again (2.4.24-ck1 ... they didn't
work with the hdsp, either (afaik, the pcmcia-cs driver never worked
with the hdsp, but i'm not sure about that)
the dmesg output was:

PCI: Found IRQ 5 for device 02:00.0
PCI: Sharing IRQ 5 with 01:00.0
PCI: Found IRQ 11 for device 02:00.1
PCI: Sharing IRQ 11 with 00:1f.3
PCI: Sharing IRQ 11 with 00:1f.5
PCI: Sharing IRQ 11 with 00:1f.6
  O2Micro OZ6933 rev 01 PCI-to-CardBus at slot 02:00, mem 0x20000000
    host opts [0]: [pci/way] [pci irq 5] [lat 168/176] [bus 3/6]
    host opts [1]: [pci/way] [pci irq 11] [lat 168/176] [bus 7/10]
    ISA irqs (default) = 3,4,7,9,10 PCI status changes
cs: cb_alloc(bus 7): vendor 0x10ee, device 0x3fc5
cs: cb_free(bus 7)
cs: cb_alloc(bus 7): vendor 0x10ee, device 0x3fc5
PCI: No IRQ known for interrupt pin A of device .
ALSA ../../alsa-kernel/pci/rme9652/hdsp.c:5031: unable to grab memory
region 0x0-0x1bff 
RME Hammerfall-DSP: no cards found

i have no idea of the differences between the cardbus drivers of the
kernel and of the pcmcia-cs project ...
anyway, the hdsp is working on a certain area of memory, that the
pcmcia-cs driver can't grab the kernel driver can ... 
i disabled acpi and apic and used pci=biosirq as kernel flag

maybe this can give you a hint ... anyway, i hope thomas can comment on
that...

cheers and thanks for your help...

 Tim                          mailto:TimBlechmann-Mmb7MZpHnFY@public.gmane.org
                              ICQ: 96771783
--
The only people for me are the mad ones, the ones who are mad to live,
mad to talk, mad to be saved, desirous of everything at the same time,
the ones who never yawn or say a commonplace thing, but burn, burn,
burn, like fabulous yellow roman candles exploding like spiders across
the stars and in the middle you see the blue centerlight pop and
everybody goes "Awww!"
                                                          Jack Kerouac

RE: [linux-audio-user] snd-hdsp+cardbus=distortion -- the sagacontinues (cardbus driver=culprit?) UPDATE: 99.9% sure it is the cardbus driver yenta_socket

[Ivica Ico Bukvic]

> -----Original Message-----
> From: Russell King [mailto:rmk@arm.linux.org.uk] On Behalf Of Russell King
> Sent: Tuesday, March 30, 2004 3:01 AM
> To: Ivica Ico Bukvic
> Cc: 'A list for linux audio users'; alsa-devel@lists.sourceforge.net;
> linux-kernel@vger.kernel.org; linux-pcmcia@lists.infradead.org
> Subject: Re: [linux-audio-user] snd-hdsp+cardbus=distortion -- the
> sagacontinues (cardbus driver=culprit?) UPDATE: 99.9% sure it is the
> cardbus driver yenta_socket
> 
> On Tue, Mar 30, 2004 at 12:52:11AM -0500, Ivica Ico Bukvic wrote:
> > 6) Pester alsa-dev, lau, and kernel/pcmcia people to death begging for
> help
> > :-)
> >
> > IN-PROGRESS :-)
> 
> What needs to happen is that the card driver author needs to investigate
> what is going on, and, if it seems related to the core PCMCIA core or
> the socket driver, we need to get involved.
> 
> IOW, linux-pcmcia people don't debug card drivers.
> 

To add to what Tim mentioned, I think that the driver is fine as it does
work on select notebooks and desktops (the card can be plugged into either
PCI card or PCMCIA cardbus). Yet, in these select instances it does not work
even though neither the cardbus driver nor the actual card driver do not
report any particular problems. Hence the only logical explanation is that
there is something wrong with the pcmcia controller driver.

This card does tax the throughput of the cardbus like no other card I can
think of, hence the problem may be more widespread, but exhibits itself just
in this case where the cardbus is being pushed to its limits. Yet, the
hardware is not the issue when the same notebook/soundcard combo works
flawlessly in WinXP.

Hope this helps!

Ico