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/
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/
>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
Cool thanks!
Ivica Ico Bukvic, composer & multimedia sculptor
http://meowing.ccm.uc.edu/~ico/
> -----Original Message-----
> From: Paul Davis [mailto:[email protected]]
> Sent: Friday, April 09, 2004 6:49 PM
> To: Ivica Ico Bukvic
> Cc: 'A list for linux audio users'; 'Russell King'; alsa-
> [email protected]; [email protected]; linux-
> [email protected]; 'Thomas Charbonnel'; [email protected]; '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
> 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:[email protected]
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
> 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:[email protected]
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
