RE: [linux-audio-user] snd-hdsp+cardbus=distortion -- the sagacontinues (cardbus driver=culprit?) MORE UPDATE

RE: [linux-audio-user] snd-hdsp+cardbus=distortion -- the sagacontinues (cardbus driver=culprit?) MORE UPDATE

[Ivica Ico Bukvic]

Hi all,

I've tinkered even further with the stuff and I do have my lspci and other
logs (will post them shortly). I've tried now runnning card with the
external Word Clock -- the results are the same (distortion persists).

At this point what I know for a fact:

1) Soundcard is distorted no matter what app/framework (i.e. direct Alsa
access vs. Jack) I use in Linux
2) Likely culprit is either PCMCIA cardbus driver or the audio driver itself
3) External Word clock does not fix the issue
4) Changing sample rate does not fix the issue
5) Apparently sound has gaps that are comparable in size to the sound data
buffers (apparently 32 points)
6) I've updated BIOS and that did not fix it (yet the DSDT table is still
trashed on my notebook but that should not affect the operability of the
PCMCIA card -- see next point)
7) Tried using the card without ACPI and APIC and the IRQ was 11 together
with the cardbus as well as with ACPI (patched 2.6.3 kernel) and APIC,
having IRQ 17 for both the cardbus and the soundcard. Both sounded the same
(distorted). Using only APIC without ACPI fails to allocate proper IRQ to
cardbus (IRQ 0) resulting in failed modprobing of the soundcard.
8) In Win32, the card works fine on the same hardware and using the same IRQ
17 like in Linux, however, upon suspending/hibernating and resuming, the
soundcard produces a similar but different kind of distortion than in Linux
except when using 32000Hz sampling rate (???).
9) The color of the distortion changes in Linux when changing sampling rates
of the card on-the-fly (Will post the link to the sound shortly). The sound
plays slower and slower in Win32 when the distortion is present and higher
sampling rates are being used
10) RME has officially ok-ed my cardbus ENE CB1410 for use in Win32 since
they tested it in their labs and it worked ok (so all they talked about its
problems before is not true any more)
11) The throughput is not the issue since I stressed the card in Win32 and
it worked ok (16 outputs at 44100Hz sampling rate at 3ms latency is flawless
using Directx and Cool Edit Pro/Adobe Audacity, as well as 8 outputs at
96000Hz at 6ms latency using ASIO in Max/MSP).
12) Even after resuming in Win32 DirectX and MME drivers still work ok, it's
only that ASIO drivers crap-out.
13) At least one more person reported similar behavior as mine on RME-audio
news server
14) At least one more person has the same problem in Linux like me
15) Once I resume from hibernate/standby in Win32, successive disconnects
eventually result in weird stuff, even a BSOD.

Here is the additional info regarding my notebook:

Boot log using ACPI&APIC on 2.6.3 patched kernel that fixes IRQ
misallocation and freezes when inserting PCMCIA card:
http://meowing.ccm.uc.edu/~ico/eMachines/boot-with-acpi&apic.log

Boot log without using ACPI&APIC on the same kernel:
http://meowing.ccm.uc.edu/~ico/eMachines/boot-without-acpi&apic.log

Detailed view of the "distorted" sound that reveals 32-points of sound
followed by 32-points of silence:
http://meowing.ccm.uc.edu/~ico/eMachines/Distortion.jpg

Simple lspci output:
http://meowing.ccm.uc.edu/~ico/eMachines/lspci-simple.log


Complex lspci output (lspci -vvv)
http://meowing.ccm.uc.edu/~ico/eMachines/lspi-complex.log

Recorded sound with the aforementioned distortion (towards the end of it,
namely last second I actually change the sampling rate on-the-fly using
hdspconf)(WARNING: the sound is normalized at 50% but was recorded clipping,
so there is some artifacts just from the clipping, but they are simply an
addon on top of what is already wrong):
http://meowing.ccm.uc.edu/~ico/eMachines/test.wav (1.7MB)

TODO:
1) Log the Jack -R output (likely to be ridden with xrun's)
2) You tell me :-)

Any help is greatly appreciated!

Best wishes,

Ivica Ico Bukvic, composer & multimedia sculptor
http://meowing.ccm.uc.edu/~ico/

RE: [linux-audio-user] snd-hdsp+cardbus=distortion -- the sagacontinues (cardbus driver=culprit?) MORE UPDATE

[Ivica Ico Bukvic]

Hi all,

I've tinkered even further with the stuff and I do have my lspci and other
logs (will post them shortly). I've tried now runnning card with the
external Word Clock -- the results are the same (distortion persists).

At this point what I know for a fact:

1) Soundcard is distorted no matter what app/framework (i.e. direct Alsa
access vs. Jack) I use in Linux
2) Likely culprit is either PCMCIA cardbus driver or the audio driver itself
3) External Word clock does not fix the issue
4) Changing sample rate does not fix the issue
5) Apparently sound has gaps that are comparable in size to the sound data
buffers (apparently 32 points)
6) I've updated BIOS and that did not fix it (yet the DSDT table is still
trashed on my notebook but that should not affect the operability of the
PCMCIA card -- see next point)
7) Tried using the card without ACPI and APIC and the IRQ was 11 together
with the cardbus as well as with ACPI (patched 2.6.3 kernel) and APIC,
having IRQ 17 for both the cardbus and the soundcard. Both sounded the same
(distorted). Using only APIC without ACPI fails to allocate proper IRQ to
cardbus (IRQ 0) resulting in failed modprobing of the soundcard.
8) In Win32, the card works fine on the same hardware and using the same IRQ
17 like in Linux, however, upon suspending/hibernating and resuming, the
soundcard produces a similar but different kind of distortion than in Linux
except when using 32000Hz sampling rate (???).
9) The color of the distortion changes in Linux when changing sampling rates
of the card on-the-fly (Will post the link to the sound shortly). The sound
plays slower and slower in Win32 when the distortion is present and higher
sampling rates are being used
10) RME has officially ok-ed my cardbus ENE CB1410 for use in Win32 since
they tested it in their labs and it worked ok (so all they talked about its
problems before is not true any more)
11) The throughput is not the issue since I stressed the card in Win32 and
it worked ok (16 outputs at 44100Hz sampling rate at 3ms latency is flawless
using Directx and Cool Edit Pro/Adobe Audacity, as well as 8 outputs at
96000Hz at 6ms latency using ASIO in Max/MSP).
12) Even after resuming in Win32 DirectX and MME drivers still work ok, it's
only that ASIO drivers crap-out.
13) At least one more person reported similar behavior as mine on RME-audio
news server
14) At least one more person has the same problem in Linux like me
15) Once I resume from hibernate/standby in Win32, successive disconnects
eventually result in weird stuff, even a BSOD.

Here is the additional info regarding my notebook:

Boot log using ACPI&APIC on 2.6.3 patched kernel that fixes IRQ
misallocation and freezes when inserting PCMCIA card:
http://meowing.ccm.uc.edu/~ico/eMachines/boot-with-acpi&apic.log

Boot log without using ACPI&APIC on the same kernel:
http://meowing.ccm.uc.edu/~ico/eMachines/boot-without-acpi&apic.log

Detailed view of the "distorted" sound that reveals 32-points of sound
followed by 32-points of silence:
http://meowing.ccm.uc.edu/~ico/eMachines/Distortion.jpg

Simple lspci output:
http://meowing.ccm.uc.edu/~ico/eMachines/lspci-simple.log


Complex lspci output (lspci -vvv)
http://meowing.ccm.uc.edu/~ico/eMachines/lspi-complex.log

Recorded sound with the aforementioned distortion (towards the end of it,
namely last second I actually change the sampling rate on-the-fly using
hdspconf)(WARNING: the sound is normalized at 50% but was recorded clipping,
so there is some artifacts just from the clipping, but they are simply an
addon on top of what is already wrong):
http://meowing.ccm.uc.edu/~ico/eMachines/test.wav (1.7MB)

TODO:
1) Log the Jack -R output (likely to be ridden with xrun's)
2) You tell me :-)

Any help is greatly appreciated!

Best wishes,

Ivica Ico Bukvic, composer & multimedia sculptor
http://meowing.ccm.uc.edu/~ico/

Re: [linux-audio-user] snd-hdsp+cardbus=distortion -- the sagacontinues (cardbus driver=culprit?) MORE UPDATE

[Tim Blechmann]

hi ico,

you did a good job in documenting this problem ... 

> TODO:
> 1) Log the Jack -R output (likely to be ridden with xrun's)
i suppose, we will get the same result as me, with jack complaining
about latency problems...

> 2) You tell me :-)
i suppose, what we are able to do, has been done ... now we'll need the
right people to talk to each other ...
mainly the alsa guys who wrote the driver and know, how they access the
bus system and the hardware, have to tell the pcmcia guys, who know,
what's going on in the bus ... i CC'd this mail to the thomas
charbonnel, paul davis and winfried ritsch, who wrote or maintain this
driver and the alsa-devel list ...
i doubt that i'm able to understand either the cardbus or the alsa side
of the driver in a reasonable time ... 

as russell king pointed out ... for him it's an unknown hardware that
accesses the bus in an unknown way and without these information he
can't be of any help ... so we'll have to give him this information and
i hope that the alsa guys can help us with that ...

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

On Fri, 2 Apr 2004 23:17:29 -0500
"Ivica Ico Bukvic" <ico@fuse.net> wrote:

> Hi all,
> 
> I've tinkered even further with the stuff and I do have my lspci and
> other logs (will post them shortly). I've tried now runnning card with
> the external Word Clock -- the results are the same (distortion
> persists).
> 
> At this point what I know for a fact:
> 
> 1) Soundcard is distorted no matter what app/framework (i.e. direct
> Alsa access vs. Jack) I use in Linux
> 2) Likely culprit is either PCMCIA cardbus driver or the audio driver
> itself 3) External Word clock does not fix the issue
> 4) Changing sample rate does not fix the issue
> 5) Apparently sound has gaps that are comparable in size to the sound
> data buffers (apparently 32 points)
> 6) I've updated BIOS and that did not fix it (yet the DSDT table is
> still trashed on my notebook but that should not affect the
> operability of the PCMCIA card -- see next point)
> 7) Tried using the card without ACPI and APIC and the IRQ was 11
> together with the cardbus as well as with ACPI (patched 2.6.3 kernel)
> and APIC, having IRQ 17 for both the cardbus and the soundcard. Both
> sounded the same(distorted). Using only APIC without ACPI fails to
> allocate proper IRQ to cardbus (IRQ 0) resulting in failed modprobing
> of the soundcard. 8) In Win32, the card works fine on the same
> hardware and using the same IRQ 17 like in Linux, however, upon
> suspending/hibernating and resuming, the soundcard produces a similar
> but different kind of distortion than in Linux except when using
> 32000Hz sampling rate (???). 9) The color of the distortion changes in
> Linux when changing sampling rates of the card on-the-fly (Will post
> the link to the sound shortly). The sound plays slower and slower in
> Win32 when the distortion is present and higher sampling rates are
> being used 10) RME has officially ok-ed my cardbus ENE CB1410 for use
> in Win32 since they tested it in their labs and it worked ok (so all
> they talked about its problems before is not true any more)
> 11) The throughput is not the issue since I stressed the card in Win32
> and it worked ok (16 outputs at 44100Hz sampling rate at 3ms latency
> is flawless using Directx and Cool Edit Pro/Adobe Audacity, as well as
> 8 outputs at 96000Hz at 6ms latency using ASIO in Max/MSP).
> 12) Even after resuming in Win32 DirectX and MME drivers still work
> ok, it's only that ASIO drivers crap-out.
> 13) At least one more person reported similar behavior as mine on
> RME-audio news server
> 14) At least one more person has the same problem in Linux like me
> 15) Once I resume from hibernate/standby in Win32, successive
> disconnects eventually result in weird stuff, even a BSOD.
> 
> Here is the additional info regarding my notebook:
> 
> Boot log using ACPI&APIC on 2.6.3 patched kernel that fixes IRQ
> misallocation and freezes when inserting PCMCIA card:
> http://meowing.ccm.uc.edu/~ico/eMachines/boot-with-acpi&apic.log
> 
> Boot log without using ACPI&APIC on the same kernel:
> http://meowing.ccm.uc.edu/~ico/eMachines/boot-without-acpi&apic.log
> 
> Detailed view of the "distorted" sound that reveals 32-points of sound
> followed by 32-points of silence:
> http://meowing.ccm.uc.edu/~ico/eMachines/Distortion.jpg
> 
> Simple lspci output:
> http://meowing.ccm.uc.edu/~ico/eMachines/lspci-simple.log
> 
> 
> Complex lspci output (lspci -vvv)
> http://meowing.ccm.uc.edu/~ico/eMachines/lspi-complex.log
> 
> Recorded sound with the aforementioned distortion (towards the end of
> it, namely last second I actually change the sampling rate on-the-fly
> using hdspconf)(WARNING: the sound is normalized at 50% but was
> recorded clipping, so there is some artifacts just from the clipping,
> but they are simply an addon on top of what is already wrong):
> http://meowing.ccm.uc.edu/~ico/eMachines/test.wav (1.7MB)
> 
> TODO:
> 1) Log the Jack -R output (likely to be ridden with xrun's)
> 2) You tell me :-)
> 
> Any help is greatly appreciated!
> 
> Best wishes,
> 
> Ivica Ico Bukvic, composer & multimedia sculptor
> http://meowing.ccm.uc.edu/~ico/
> 
> 
> 
> 
> _______________________________________________
> Linux PCMCIA reimplementation list
> http://lists.infradead.org/mailman/listinfo/linux-pcmcia
> 



-------------------------------------------------------
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: [linux-audio-user] snd-hdsp+cardbus=distortion -- the sagacontinues (cardbus driver=culprit?) MORE UPDATE

[Paul Davis]

>mainly the alsa guys who wrote the driver and know, how they access the
>bus system and the hardware, have to tell the pcmcia guys, who know,
>what's going on in the bus ... i CC'd this mail to the thomas
>charbonnel, paul davis and winfried ritsch, who wrote or maintain this
>driver and the alsa-devel list ...
>i doubt that i'm able to understand either the cardbus or the alsa side
>of the driver in a reasonable time ... 

there is no "cardbus side" of the driver.

a cardbus device appears to an ALSA driver (and i suspect to the
kernel as well) as a completely regular PCI device. unless you go
"fishing" for evidence, there is no way to tell that the device is not
a regular PCI device.

there is nothing in the ALSA driver for the HDSP that is conditional
on the h/w being a cardbus device or not, because we don't (and likely
can't) know that it is.

sorry. FWIW, i have an ENE 1411 and it works OK with my hdsp at period
sizes below a certain threshold. i don't know if its the same problem
or not.

--p


-------------------------------------------------------
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: [linux-audio-user] snd-hdsp+cardbus=distortion -- the sagacontinues (cardbus driver=culprit?) MORE UPDATE

[Tim Blechmann]

On Sun, 04 Apr 2004 10:53:28 -0400
Paul Davis <paul@linuxaudiosystems.com> wrote:

> >mainly the alsa guys who wrote the driver and know, how they access
> >the bus system and the hardware, have to tell the pcmcia guys, who
> >know, what's going on in the bus ... i CC'd this mail to the thomas
> >charbonnel, paul davis and winfried ritsch, who wrote or maintain
> >this driver and the alsa-devel list ...
> >i doubt that i'm able to understand either the cardbus or the alsa
> >side of the driver in a reasonable time ... 
> 
> there is no "cardbus side" of the driver.
> a cardbus device appears to an ALSA driver (and i suspect to the
> kernel as well) as a completely regular PCI device. unless you go
> "fishing" for evidence, there is no way to tell that the device is not
> a regular PCI device.
> 
> there is nothing in the ALSA driver for the HDSP that is conditional
> on the h/w being a cardbus device or not, because we don't (and likely
> can't) know that it is.
i think the pcmcia guys need to know, how you access the hardware no
matter if it's a cardbus or a pci device ... but they have no idea, what
the driver is actually doing, so if it's their problem or not...

quote from russell king:
> As I say, what needs to happen is that the driver author needs to
> work out what is happening from his drivers point of view, and from
> the hardware point of view.
> 
> Once we know that, we can start looking at whether it is related to
> the cardbus bridge or not.
> 
> Until then, as far as I'm concerned, it's an unknown driver operating
> using unknown methods doing something unknown.  That's far too many
> unknowns to even start to guess at the cause.
quote end.

i hope you can help us with that. 


> sorry. FWIW, i have an ENE 1411 and it works OK with my hdsp at period
> sizes below a certain threshold. i don't know if its the same problem
> or not.
if it's working on certain settings, it's definitely not the problem
ico, timothy and i are experiencing ... in the last 3 monthes i tried
nearly every combination of settings ... at least ico's and my problem
is very well documented by us, but since we have no idea of what the
driver is actually doing, we can't do anything more ... except buy a new
laptop. but at least i would be quite happy if we can track this problem
down ...
and it HAS do be a software issue, since at least on ico's and my
machine, the hdsp works flawless with winxp ... 
the problem you have, is that a linux only problem or do you experience
the same problems with windows?

thanks a lot...

 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: [linux-audio-user] snd-hdsp+cardbus=distortion -- the sagacontinues (cardbus driver=culprit?) MORE UPDATE

[Paul Davis]

>and it HAS do be a software issue, since at least on ico's and my
>machine, the hdsp works flawless with winxp ... 

agreed. but its much more likely to be something about the cardbus
support under linux than the hdsp driver, and neither side (the
cardbus people or us hdsp people) knows the other side at all.

>the problem you have, is that a linux only problem or do you experience
>the same problems with windows?

i have never run windows. sorry.

--p


-------------------------------------------------------
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: [linux-audio-user] snd-hdsp+cardbus=distortion -- the sagacontinues (cardbus driver=culprit?) MORE UPDATE

[Tim Blechmann]

> agreed. but its much more likely to be something about the cardbus
> support under linux than the hdsp driver, and neither side (the
> cardbus people or us hdsp people) knows the other side at all.
to figure that out, someone who knows what's going on in the hdsp driver
has to tell the pcmcia guys, how they access the hardware, so they have
an idea what they have to look for ... 

if someone, who is actually familiar with the driver would do that, it
would be very kind, since it would take me weeks or monthes to
understand what's going on in the driver ... 

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: [linux-audio-user] snd-hdsp+cardbus+M6807 notebook=distortion -- First good news!

[Ivica Ico Bukvic]

Hi all!

I've just achieved a first milestone in fixing (fighting?) this issue. I've
been in close correspondence with the notebook manufacturer (Arima --
notebook is eMachines M6807) and here's what I found out so far.

(this should be especially valuable for the linux-pcmcia people, Russel are
you there? :-)

Arima provided me with the hex editor (real-time DOS-like app that allows
monitoring of various "registers" of every particular controller/hw on the
notebook, including the dreaded pcmcia). After tinkering with it for some
time in Windows XP, I finally fixed the issue where I had the distortion
after resume (the fix needs to be applied manually at this point in time
using this app, although I am hoping a BIOS update will soon fix this in a
much more elegant way). The issues I learned are as follows:

1) Accroding to Matthias (RME), the hdsp multiface is limited to bursts of
16 (bytes?) of data via cardbus controller.

2) The Windows driver automatically adjusts any pcmcia controller's latency
from (in my case default, yours could vary) 0x20 (or 32) to 0xFF (or 255).
This always happens except in one case where the card remains plugged-in
during the suspend/resume cycle which Matthias acknowledged it may be an
overlook in their drivers, but is no big deal as the card works ok even with
0x20 latency. The higher latency simply ensures that if the PCI is snagged
by something else that the audio packets are never late.

3) In my case the distortion of the sound after "resume" came from the fact
that when the computer is resumed, 2 registers on the pcmcia controller got
slightly altered (whose function is yet to be determined -- Arima is in
process of dealing with this) and always to the same value (there are other
values that also change but are of no importance in this case). By changing
them to the previous state the soundcard works just fine! Yay!

So what does all this mean in Linux?

Well, if there is a way of monitoring these hex registers for various
hardware in Linux I could try to compare their state upon initialization in
Linux to that one in Windows (since in both situations they share the same
IRQ, at least on my notebook) and forward this info to you guys.

So my question at this point is, is there such hex-editor in Linux that
allows this kind of monitoring and if so where can I obtain it?

More info on the Windows version (uses DOS-like commandline):

It's called "System Explorer v.1.00"
Screenshot of the pcmcia controller's state while card is disconnected:
http://meowing.ccm.uc.edu/~ico/eMachines/SE-before_suspend.jpg
Written by Danny Liu (AMI) and it's free (supposedly, haven't looked for it
on the Internet just yet, too tired right now)

On the screenshot you can see position (ROW,COL) 00,0D the value for setting
the latency (FWIW at this point this does not seem to be the problem but I
am pointing it out just to let the pcmcia and RME driver maintainers that it
does get bumped-up when the RME card is connected to 0xFF). In my case after
resume 2 values get altered (among other things) which cause the distortion
in Windows, but as of right now I do not know their exact function (see:
http://meowing.ccm.uc.edu/~ico/eMachines/SE-after_suspend_problem_highlighte
d.jpg). Once these 2 values are changed to their old ones (90 to D0, 06 to
04) the card works just fine even after resume. Both values need to be fixed
for the card to work properly. The 04/06 value is especially important as it
adjusts the distortion timbre and/or speed of the sound so this should be
one to be watched closely. Yet it by itself does not fix the issue and the
other register also needs to be reverted to D0 value before the card works
properly.

This is in a nutshell the likely culprit for Linux (in my case at least) and
this may very well help trace the problem down. Please bear in mind that in
Linux I am not using any power management and the sound is trashed even upon
first init. It would be great to see how its hex state looks when compared
with Windows as this could shed some light as to how to fix the problem.

In Linux I am using MDK Community 10.0, patched 2.6.3 kernel (with patches
for M6807 notebook to make its pcmcia work).

Apologies for the long blurb.

Best wishes,

Ivica Ico Bukvic, composer & multimedia sculptor
http://meowing.ccm.uc.edu/~ico/

RE: [linux-audio-user] snd-hdsp+cardbus+M6807 notebook=distortion -- First good news!

[Ivica Ico Bukvic]

Hi all!

I've just achieved a first milestone in fixing (fighting?) this issue. I've
been in close correspondence with the notebook manufacturer (Arima --
notebook is eMachines M6807) and here's what I found out so far.

(this should be especially valuable for the linux-pcmcia people, Russel are
you there? :-)

Arima provided me with the hex editor (real-time DOS-like app that allows
monitoring of various "registers" of every particular controller/hw on the
notebook, including the dreaded pcmcia). After tinkering with it for some
time in Windows XP, I finally fixed the issue where I had the distortion
after resume (the fix needs to be applied manually at this point in time
using this app, although I am hoping a BIOS update will soon fix this in a
much more elegant way). The issues I learned are as follows:

1) Accroding to Matthias (RME), the hdsp multiface is limited to bursts of
16 (bytes?) of data via cardbus controller.

2) The Windows driver automatically adjusts any pcmcia controller's latency
from (in my case default, yours could vary) 0x20 (or 32) to 0xFF (or 255).
This always happens except in one case where the card remains plugged-in
during the suspend/resume cycle which Matthias acknowledged it may be an
overlook in their drivers, but is no big deal as the card works ok even with
0x20 latency. The higher latency simply ensures that if the PCI is snagged
by something else that the audio packets are never late.

3) In my case the distortion of the sound after "resume" came from the fact
that when the computer is resumed, 2 registers on the pcmcia controller got
slightly altered (whose function is yet to be determined -- Arima is in
process of dealing with this) and always to the same value (there are other
values that also change but are of no importance in this case). By changing
them to the previous state the soundcard works just fine! Yay!

So what does all this mean in Linux?

Well, if there is a way of monitoring these hex registers for various
hardware in Linux I could try to compare their state upon initialization in
Linux to that one in Windows (since in both situations they share the same
IRQ, at least on my notebook) and forward this info to you guys.

So my question at this point is, is there such hex-editor in Linux that
allows this kind of monitoring and if so where can I obtain it?

More info on the Windows version (uses DOS-like commandline):

It's called "System Explorer v.1.00"
Screenshot of the pcmcia controller's state while card is disconnected:
http://meowing.ccm.uc.edu/~ico/eMachines/SE-before_suspend.jpg
Written by Danny Liu (AMI) and it's free (supposedly, haven't looked for it
on the Internet just yet, too tired right now)

On the screenshot you can see position (ROW,COL) 00,0D the value for setting
the latency (FWIW at this point this does not seem to be the problem but I
am pointing it out just to let the pcmcia and RME driver maintainers that it
does get bumped-up when the RME card is connected to 0xFF). In my case after
resume 2 values get altered (among other things) which cause the distortion
in Windows, but as of right now I do not know their exact function (see:
http://meowing.ccm.uc.edu/~ico/eMachines/SE-after_suspend_problem_highlighte
d.jpg). Once these 2 values are changed to their old ones (90 to D0, 06 to
04) the card works just fine even after resume. Both values need to be fixed
for the card to work properly. The 04/06 value is especially important as it
adjusts the distortion timbre and/or speed of the sound so this should be
one to be watched closely. Yet it by itself does not fix the issue and the
other register also needs to be reverted to D0 value before the card works
properly.

This is in a nutshell the likely culprit for Linux (in my case at least) and
this may very well help trace the problem down. Please bear in mind that in
Linux I am not using any power management and the sound is trashed even upon
first init. It would be great to see how its hex state looks when compared
with Windows as this could shed some light as to how to fix the problem.

In Linux I am using MDK Community 10.0, patched 2.6.3 kernel (with patches
for M6807 notebook to make its pcmcia work).

Apologies for the long blurb.

Best wishes,

Ivica Ico Bukvic, composer & multimedia sculptor
http://meowing.ccm.uc.edu/~ico/

Re: [Alsa-devel] RE: [linux-audio-user] snd-hdsp+cardbus+M6807 notebook=distortion -- First good news!

[Paul Davis]

>Well, if there is a way of monitoring these hex registers for various
>hardware in Linux I could try to compare their state upon initialization in
>Linux to that one in Windows (since in both situations they share the same
>IRQ, at least on my notebook) and forward this info to you guys.
>
>So my question at this point is, is there such hex-editor in Linux that
>allows this kind of monitoring and if so where can I obtain it?

i would imagine that you have it already, though its cmdline: setpci
(and lspci -vv for the display side, so to speak).

not sure if this is really the equivalent, but i suspect that it is.

--p

RE: [Alsa-devel] RE: [linux-audio-user] snd-hdsp+cardbus+M6807 notebook=distortion -- First good news!

[Ivica Ico Bukvic]

Cool thanks!

Ivica Ico Bukvic, composer & multimedia sculptor
http://meowing.ccm.uc.edu/~ico/
 

> -----Original Message-----
> From: Paul Davis [mailto:paul@linuxaudiosystems.com]
> Sent: Friday, April 09, 2004 6:49 PM
> To: Ivica Ico Bukvic
> Cc: 'A list for linux audio users'; 'Russell King'; alsa-
> devel@lists.sourceforge.net; linux-kernel@vger.kernel.org; linux-
> pcmcia@lists.infradead.org; 'Thomas Charbonnel'; ccheney@debian.org; 'Tim
> Blechmann'
> Subject: Re: [Alsa-devel] RE: [linux-audio-user] snd-hdsp+cardbus+M6807
> notebook=distortion -- First good news!
> 
> >Well, if there is a way of monitoring these hex registers for various
> >hardware in Linux I could try to compare their state upon initialization
> in
> >Linux to that one in Windows (since in both situations they share the
> same
> >IRQ, at least on my notebook) and forward this info to you guys.
> >
> >So my question at this point is, is there such hex-editor in Linux that
> >allows this kind of monitoring and if so where can I obtain it?
> 
> i would imagine that you have it already, though its cmdline: setpci
> (and lspci -vv for the display side, so to speak).
> 
> not sure if this is really the equivalent, but i suspect that it is.
> 
> --p

RE: [Alsa-devel] RE: [linux-audio-user] snd-hdsp+cardbus+M6807 notebook=distortion -- First good news!

[Ivica Ico Bukvic]

Cool thanks!

Ivica Ico Bukvic, composer & multimedia sculptor
http://meowing.ccm.uc.edu/~ico/
 

> -----Original Message-----
> From: Paul Davis [mailto:paul@linuxaudiosystems.com]
> Sent: Friday, April 09, 2004 6:49 PM
> To: Ivica Ico Bukvic
> Cc: 'A list for linux audio users'; 'Russell King'; alsa-
> devel@lists.sourceforge.net; linux-kernel@vger.kernel.org; linux-
> pcmcia@lists.infradead.org; 'Thomas Charbonnel'; ccheney@debian.org; 'Tim
> Blechmann'
> Subject: Re: [Alsa-devel] RE: [linux-audio-user] snd-hdsp+cardbus+M6807
> notebook=distortion -- First good news!
> 
> >Well, if there is a way of monitoring these hex registers for various
> >hardware in Linux I could try to compare their state upon initialization
> in
> >Linux to that one in Windows (since in both situations they share the
> same
> >IRQ, at least on my notebook) and forward this info to you guys.
> >
> >So my question at this point is, is there such hex-editor in Linux that
> >allows this kind of monitoring and if so where can I obtain it?
> 
> i would imagine that you have it already, though its cmdline: setpci
> (and lspci -vv for the display side, so to speak).
> 
> not sure if this is really the equivalent, but i suspect that it is.
> 
> --p

Re: [linux-audio-user] snd-hdsp+cardbus+M6807 notebook=distortion -- First good news!

[Tim Blechmann]

> 2) The Windows driver automatically adjusts any pcmcia controller's
> latency from (in my case default, yours could vary) 0x20 (or 32) to
> 0xFF (or 255). This always happens except in one case where the card
> remains plugged-in during the suspend/resume cycle which Matthias
> acknowledged it may be an overlook in their drivers, but is no big
> deal as the card works ok even with 0x20 latency. The higher latency
> simply ensures that if the PCI is snagged by something else that the
> audio packets are never late.
thomas added this to the linux driver, too, although i don't know if
it's already included in the recent alsa version ... he sent me a
patched source file some times ago ... anyway, it didn't help on my
machine...

> It's called "System Explorer v.1.00"
> Screenshot of the pcmcia controller's state while card is
> disconnected:
> http://meowing.ccm.uc.edu/~ico/eMachines/SE-before_suspend.jpg
i haven't had a look at this screenshot, yet, but can you tell me which
registers have been altered in windows?

> This is in a nutshell the likely culprit for Linux (in my case at
> least) and this may very well help trace the problem down. Please bear
> in mind that in Linux I am not using any power management and the
> sound is trashed even upon first init. It would be great to see how
> its hex state looks when compared with Windows as this could shed some
> light as to how to fix the problem.
you can use scanpci to get the actual register settings from your
devices ... i'd be pretty curious if your windows register settings
differ from your linux register settings ... i'll have a look at your
screenshots tomorrow ... i'd appreciate if you could send me an output
of scanpci of your linux settings that i can compare it with mine ... 
and if some people with hdsps that are actually working on their
machines would provide us with their register settings, we might be able
to figure out, where the problem could come from ...

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

Re: [linux-audio-user] snd-hdsp+cardbus+M6807 notebook=distortion -- First good news!

[Tim Blechmann]

> 2) The Windows driver automatically adjusts any pcmcia controller's
> latency from (in my case default, yours could vary) 0x20 (or 32) to
> 0xFF (or 255). This always happens except in one case where the card
> remains plugged-in during the suspend/resume cycle which Matthias
> acknowledged it may be an overlook in their drivers, but is no big
> deal as the card works ok even with 0x20 latency. The higher latency
> simply ensures that if the PCI is snagged by something else that the
> audio packets are never late.
thomas added this to the linux driver, too, although i don't know if
it's already included in the recent alsa version ... he sent me a
patched source file some times ago ... anyway, it didn't help on my
machine...

> It's called "System Explorer v.1.00"
> Screenshot of the pcmcia controller's state while card is
> disconnected:
> http://meowing.ccm.uc.edu/~ico/eMachines/SE-before_suspend.jpg
i haven't had a look at this screenshot, yet, but can you tell me which
registers have been altered in windows?

> This is in a nutshell the likely culprit for Linux (in my case at
> least) and this may very well help trace the problem down. Please bear
> in mind that in Linux I am not using any power management and the
> sound is trashed even upon first init. It would be great to see how
> its hex state looks when compared with Windows as this could shed some
> light as to how to fix the problem.
you can use scanpci to get the actual register settings from your
devices ... i'd be pretty curious if your windows register settings
differ from your linux register settings ... i'll have a look at your
screenshots tomorrow ... i'd appreciate if you could send me an output
of scanpci of your linux settings that i can compare it with mine ... 
and if some people with hdsps that are actually working on their
machines would provide us with their register settings, we might be able
to figure out, where the problem could come from ...

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

Re: [linux-audio-user] snd-hdsp+cardbus+M6807 notebook=distortion -- First good news!

[Tim Blechmann]

> It's called "System Explorer v.1.00"
> Screenshot of the pcmcia controller's state while card is
> disconnected:
> http://meowing.ccm.uc.edu/~ico/eMachines/SE-before_suspend.jpg
> Written by Danny Liu (AMI) and it's free (supposedly, haven't looked
> for it on the Internet just yet, too tired right now)
i'm confused ... the bytes that got altered are no members of the pci
configuration space ... could you try to do the same tests with the
hdsp? maybe there's a register in the configuration space of the hdsp
that's getting altered as well...

... and we should try to figure out, what these registers are actually
doing ... 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

Re: [linux-audio-user] snd-hdsp+cardbus+M6807 notebook=distortion -- First good news!

[Tim Blechmann]

> It's called "System Explorer v.1.00"
> Screenshot of the pcmcia controller's state while card is
> disconnected:
> http://meowing.ccm.uc.edu/~ico/eMachines/SE-before_suspend.jpg
> Written by Danny Liu (AMI) and it's free (supposedly, haven't looked
> for it on the Internet just yet, too tired right now)
i'm confused ... the bytes that got altered are no members of the pci
configuration space ... could you try to do the same tests with the
hdsp? maybe there's a register in the configuration space of the hdsp
that's getting altered as well...

... and we should try to figure out, what these registers are actually
doing ... 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