20 Mar
2004
20 Mar
'04
1:40 a.m.
First off I would like to extend my sincere apologies for my atrocious
cross-posting. I am currently in a rather desperate situation and would
highly appreciate any help I can get in this matter.
<Begin long blurb>
I recently got my hands on the eMachines M6807 64-bit Athlon 3000+ and I
must say that the notebook is very nice. The gripes I do have about it are
mostly of cosmetic nature. The performance is in many ways unmatched. After
owning the notebook for just about a month I finally found some free time to
install the Multiface/HDSP on it. I was immediately very unpleasantly
surprised by the fact that the sound output using the ASIO drivers (and
Linux ALSA drivers) yielded similar results -- distorted audio.
Now here's the catch. When I use the soundcard in mme, DirectX, or any other
driver form, the soundcard works perfectly (albeit no multichannel
capability). But when I use ALSA in Linux or ASIO in Windoze (XP Home
version), the sound plays as if it's interpreted slower than it should be (2
whole steps, or 4 semitones lower and comparably slower) with a bad
distortion, as if one is using a very lousy vocoder. There are no drop-outs
or choppiness (I did not try JACK, though, so I don't know about the
explicit xruns) which leads me to believe that the throughput is not the
culprit, but the output simply is useless.
Here's some additional info/problems I am aware of:
1) The manufacturer of the notebook is Arima (company that supplies many
other companies with the same chipset/chasis) has shipped this notebook with
a crappy BIOS (Linux at boot time complains about DSDT being all fubared and
fails to properly allocate IRQ's with the acpi turned on; also apic seems to
be fubared as well). Some of these issues have been addressed in the 2.6.2
kernels via several patches with a spotty success and currently I need to
boot with no acpi or apic to get everything working properly (otherwise
almost no peripheral works properly). So, I know for a fact that BIOS is
sucking rather bad... Contacting support so far has only suggested that
there should be some bios updates coming up soon, but I'll believe it when I
see it (OTOH this model is supposedly selling rather well as it has been
apparently licensed by at least 6 different companies across the world
including the voodoopc, so I guess that should provide some leverage).
2) I am using Mdk 10.0 Community release. No problems there that I can
notice. Installed the hdsp utils and everything worked like a charm, except
of course for the sound output.
3) The pcmcia card in XP is detected as the generic pcmcia and is using
default XP drivers without any conflicts and/or apparent problems.
4) The pcmcia card (at least in Windows) is sharing its IRQ only with the
HDSP when plugged in (IRQ 17 -- there are total of 24 due to APIC being
enabled in XP), but I don't think that should be considered a conflict
(please correct me if I am wrong).
5) In Linux due to fact that the computer boots without APCI and APIC
enabled, my guess is that it is using only first 15 IRQ's (like the old
APM-based PC), although I need to further investigate this. To the best of
my knowledge no IRQ conflicts have been reported by the syslog when using
this setup.
6) The pcmcia cardbus is using the yenta_socket driver in Linux, but
curiously cannot be used with the APCI (most likely due to fubared BIOS), as
that immediately freezes the system.
7) In Windows, I tried 2.53 and 2.62 drivers, with the latest firmware (11).
Using different drivers made no difference. I tried several ASIO-capable
applications in order to make sure this was the case.
8) No errors during use of Multiface are reported in either Linux nor
Windows.
Finally, having used Multiface on Inspiron laptops, I am quite familiar with
the sound that is being generated by the lousy throughput (crackly stuff)
and I must say that while this sounds very similar, there are couple of
things that make this sound different:
1) No matter which latency I select in hdsp configuration tool, the sound
remains the same.
2) When overclocking the laptop (this beast that runs at 1.8GHz oc's via
software without a hitch to 2GHz with no overheating and no instability
whatsoever), the pitch and the speed of the output rises (wtf?). At 2GHz
it's about 2 semitones higher (and comparably faster). I am having a feeling
that if I could oc it for another 200MHz, I would have the right playback
speed :-). OTOH, when the laptop downclocks to preserve battery (800MHz) the
sound playback remains at approx. the same speed but with a timbrally
somewhat different artifacts like the one at 1800MHz.
3) When using mme, or DirectX or any other non-ASIO playback format in
Windows, no matter what the latency in the hdsp config tool, the sound
output is flawless.
4) I also read that some of the 2.6.2 Linux kernel patches were incorporated
to fix the fact that Bios represents the CPU speed (via ACPI?) as 1600MHz
which is apparent in the Windows if one right-clicks on the My Computer icon
and clicks on Properties. However, programs like CpuID read the frequency
properly as 1800MHz.
5) FSB on this beast to the best of my knowledge should be plenty fast
(200MHz x ? -- I heard it's like 1600MHz (8x), but I find that hard to
believe). Hence, I would be seriously surprised that it is a case of a lousy
cardbus implementation... Although, I guess everything is possible...
<end long blurb>
Whew! That should be about it. If you need any syslogs or any other info,
please contact me and I will gladly provide them. I would simply appreciate
any insight at this point as I have purchased this laptop primarily for the
music-making purposes and not being able to use it with the expensive
Multiface makes either this laptop or the Multiface an expensive brick (I
say this as I did hear that M-Audio Firewire 410 runs just fine in
combination with this notebook).
Cc: RME support US/international
LAD/LAU
Alsa-dev/user
I would also appreciate any help from the RME tech department as this may
potentially stem from the fact that the system is 64-bit (although I am NOT
running 64-bit versions of either Windows or Linux) and that the drivers are
somehow not taking that into account.
Best wishes,
Ivica Ico Bukvic, composer & multimedia sculptor
http://meowing.ccm.uc.edu/~ico/
20 Mar
20 Mar
5:19 a.m.
<snip>
Could it be something to do with playback frequency? Like playing back
at 44100 instead of 48000 or vice versa?
James
10:08 a.m.
On Fri, 2004-03-19 at 21:35, Ivica Ico Bukvic wrote:
First off I would like to extend my sincere apologies
for my atrocious
cross-posting. I am currently in a rather desperate situation and would
highly appreciate any help I can get in this matter.
<Begin long blurb>
I recently got my hands on the eMachines M6807 64-bit Athlon 3000+ and I
must say that the notebook is very nice.
I had been trying very hard over the last two weeks to buy one of these
or its little brother the M6805, but couldn't get it here in California
or online. I finally contacted eMachines and was told they no longer
make these models. The M6805 works very well under Win XP with the Pro
Tools software and 002/002R hardware. People who own the machine swear
by it, however no one I know is using its cardbus interface.
The gripes I do have about it are
mostly of cosmetic nature. The performance is in many ways unmatched. After
owning the notebook for just about a month I finally found some free time to
install the Multiface/HDSP on it. I was immediately very unpleasantly
surprised by the fact that the sound output using the ASIO drivers (and
Linux ALSA drivers) yielded similar results -- distorted audio.
Now here's the catch. When I use the soundcard in mme, DirectX, or any other
driver form, the soundcard works perfectly (albeit no multichannel
capability). But when I use ALSA in Linux or ASIO in Windoze (XP Home
version), the sound plays as if it's interpreted slower than it should be (2
whole steps, or 4 semitones lower and comparably slower) with a bad
distortion, as if one is using a very lousy vocoder. There are no drop-outs
or choppiness (I did not try JACK, though, so I don't know about the
explicit xruns) which leads me to believe that the throughput is not the
culprit, but the output simply is useless.
Very strange that one set of Windows drivers would work well and the
other would fail the same way as Alsa.
I think you should try Jack as a measure of the cardbus performance. At
least it will help you know if packets are getting across the controller
in a timely manner.
<SNIP>
2) I am using Mdk 10.0 Community release. No problems there that I can
notice. Installed the hdsp utils and everything worked like a charm, except
of course for the sound output.
32-bit kernel on a 64-bit processor...
3) The pcmcia card in XP is detected as the generic pcmcia and is using
default XP drivers without any conflicts and/or apparent problems.
4) The pcmcia card (at least in Windows) is sharing its IRQ only with the
HDSP when plugged in (IRQ 17 -- there are total of 24 due to APIC being
enabled in XP), but I don't think that should be considered a conflict
(please correct me if I am wrong).
No, it's fine as far as I know.
<SNIP>
5) FSB on this beast to the best of my knowledge
should be plenty fast
(200MHz x ? -- I heard it's like 1600MHz (8x), but I find that hard to
believe). Hence, I would be seriously surprised that it is a case of a lousy
cardbus implementation... Although, I guess everything is possible...
Who's cardbus controller is it? (lspci should say) Tim Blechmann was
having similar troubles with the same RME product and his O2 Micro
cardbus controller. In his case Windows operation was fine, but he
wasn't using a 64-bit processor.
<end long blurb>
Whew! That should be about it. If you need any syslogs or any other info,
please contact me and I will gladly provide them. I would simply appreciate
any insight at this point as I have purchased this laptop primarily for the
music-making purposes and not being able to use it with the expensive
Multiface makes either this laptop or the Multiface an expensive brick (I
say this as I did hear that M-Audio Firewire 410 runs just fine in
combination with this notebook).
Yeah, but no one does 1394 support under Linux yet. Bummer.
I would also appreciate any help from the RME tech department as this may
potentially stem from the fact that the system is 64-bit (although I am NOT
running 64-bit versions of either Windows or Linux) and that the drivers are
somehow not taking that into account.
RME has an AMAZINGLY good support system through their newsgroup.
Sometimes answers from the company are almost real-time, but they don't
support Linux. If you try that forum, I'd concentrate on your equivalent
Windows problems.
- Mark
11:47 a.m.
On Sat, 2004-03-20 at 07:21, sigir wrote:
Mark Knecht <markknecht(a)comcast.net> a écrit :
It sees it as both.
PCMCIA (cardbus) is a 'physical' interface, if you will. You system
would load a driver for that controller, but mostly it's a bridge to
whatever cardbus device you plug in.
If you plug in a cardbus 1394 adapter, then the system needs 1394
drivers. If you plug in a cardbus Ethernet adapter, then it needs
Ethernet drivers. If you plug in a cardbus USB 2.0 adapter, then the
system needs USB drivers.
Mostly the system should not card about the cardbus controller, but not
all of these controllers work real well, and they do use different
drivers.
The problem with 1394 under Linux that I was speaking of was really
support for devices like the Firewire 410 that was mentioned earlier.
That's not happening. To the best of my knowledge no one is writing
drivers for that. The conversation was had recently on the Linux1394
lists. One guy has written M-Audio asking for info so that possibly
someone could, but I don't think there's anything happening.
Chicken and egg. Why buy one if there's no support?
- Mark
Yeah, but no one does 1394 support under Linux
yet. Bummer.
What about an adapter PCMCIA (in the laptop) ==> firewire? Does
Linux see it as PCMCIA or as firewire ? 
21 Mar
21 Mar
7:05 a.m.
New subject: [linux-audio-user] Re: [linux-audio-dev] Major problem with RME HDSP/Multiface and a 64-bit AMD laptop
On Sat, 20 Mar 2004 00:35:02 -0500
"Ivica Ico Bukvic" <ico(a)fuse.net> wrote:
First off I would like to extend my sincere apologies
for my atrocious
cross-posting. I am currently in a rather desperate situation and
would highly appreciate any help I can get in this matter.
<Begin long blurb>e
wait ... this seems to be similar to the problem i have with my hdsp ...
i can't run it on my linux system at all, althouth it works fine with
windows xp:
can you try jack as super user with -R flag?
if you use an input signal, some of the input gets copied to the output
if a sound application is running, which results some distortion ...
could you start jack / pd, and try to use any of the input channels try
several settings of hdspmixer...
the problem with my hdsp is definitely a cardbus driver issue ... from
what i heard from people who tried to help me is, that there are some
problems in mapping the memory from the kernel to the buffer inside the
cardbus bridge ...
the problem with the kernel driver for the yenta socket is, that it's
not properly supported ... thomas charbonnel, who maintains the hdsp
driver and i wrote a message to both the kernel and the pcmcia-cs
mailing-list, but didn't get any answer...
of course, it could be a problem of the cardbus controller hardware,
that the windows driver may handle differently than the yenta-socket
module for linux my machine has an o2micro cardbus controller, that,
conserning rme's support may produce problems ...
i'm able to sell my notebook to my mother ;-) and get a new one, soon...
the only reason, why i won't get an amd64 is that the notebooks that are
equipped with this chip, have either ene or ricoh cardbus controllers,
controllers rme warns against ... that's why i'll order a p4 inspiron,
soon...
anyway, when i talked to thomas a short time ago, he considered going to
the lad conference, i'll go there, and concerning the schedule, you'll
be there, too ... maybe we could try to track this problem down and try
to contact the kernel mailinglist again...
i hope that you will be more luck than i was ...
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
22 Mar
22 Mar
1:32 p.m.
FSB on this beast to the best of my knowledge should
be plenty fast
(200MHz x ?
As I understand it, the AMD64 architecture doesn't have a front side
bus. AMD are promoting the chips on the basis that they don't have
the memory bottleneck of the 32-bit Intel architecture.
I'm currently researching a piece on AMD64 for Sound on Sound, so I'd
be glad to hear about any real-world experiences. I'm waiting for a
case to be delivered, so I can build an Opteron 240 machine based on
an Asus SK8V board.
Cheers
Daniel
1:50 p.m.
New subject: [linux-audio-user] Major problem with RME HDSP/Multiface and a 64-bit AMD laptop
Daniel James wrote:
no no no no no no nooooooo ;-)
ALL microprocessors have a 'Front Side Bus'. This is the physical bus
between the processor and the chipset. It has to exist unless you get a
processor built into the chipset itself.
*Most* processors get to memory by going through the FSB to the north
bridge of the chipset, and then from the chipset to the memory chips.
Historically this has been one of the bottlenecks in getting better
system performance.
*Some* processors can actually connect memory directly to the processor
on a private memory bus.
AMD are promoting the chips on the basis that they don't have
FSB on this
beast to the best of my knowledge should be plenty fast
(200MHz x ?
As I understand it, the AMD64 architecture doesn't have a front side
bus. the memory bottleneck of the 32-bit Intel
architecture.
Well, this may be partially true, in the sense that AMD has added a lot
more bandwidth on their buses in recent processors so the bottlenexk is
less of an issue than on most Intel systems today, but ALL systems have
a memory bottleneck, in the sense that it's not unlimited bandwidth. It
just may be less of a problem than other parts of the system.
I'm currently researching a piece on AMD64 for Sound on Sound, so I'd
be glad to hear about any real-world experiences. I'm waiting for a
case to be delivered, so I can build an Opteron 240 machine based on
an Asus SK8V board.
The eMachines M6805 laptop have been an excellent performer under
Windows XP running Pro Tools, but eMachines tells me they've stopped
making it. Very little in-depth data (yet) under Linux though. Ivica is
working with the M6807 I think.
The entry level price on these AMD-64 machines is phenominal - HP has
one at only a few dollars over $1K.
Cheers
Daniel
23 Mar
23 Mar
5:44 a.m.
New subject: [linux-audio-user] Major problem with RME HDSP/Multiface and a64-bit AMD laptop
ALL microprocessors have a 'Front Side Bus'.
This is the physical
bus between the processor and the chipset. It has to exist unless
you get a processor built into the chipset itself.
According to the diagram I have from AMD, there is a DDR controller
built into the Opteron itself.
but ALL systems have a memory bottleneck, in the sense
that it's
not unlimited bandwidth. It just may be less of a problem than
other parts of the system.
Sure - if you remove one bottleneck, you discover another in the
chain. I suspect hard disc access will be the limiting factor on
these machines.
The entry level price on these AMD-64 machines is
phenominal - HP
has one at only a few dollars over $1K.
It's got to be the most accessible 64-bit chip, especially here since
the dollar is weak at the moment. A 200 series Opteron (the SMP
capable type) is no more expensive than a 32 bit P4, let alone a Xeon
or a G5. And of course Linux users have a head start since we can
compile native code or use an off the shelf AMD64 distribution.
Cheers
Daniel
7690
days inactive
7693
days old
linux-audio-user@lists.linuxaudio.org
9 comments
7 participants
participants (7)
-
Daniel James -
Ivica Ico Bukvic -
James Stone -
Mark Knecht -
Mark Knecht -
sigir -
Tim Blechmann