17 Nov
2005
17 Nov
'05
6:40 p.m.
Hi,
I'm looking for a device, mainly to get better audio quality as my
Aureon offers (16Bits only), and to record some acoustic guitar and
mics.
AFAIK the Edirol UA-25 works plug and play with snd_usb_audio, but still
some questions:
* I read it is bus powered; but I wonder how can it get 48V phantom
power from the USB bus?!?
* I read somewhere on the web that there was a little hiss on the
inputs. Can anyone confirm this, and is it OK or too much?
* Can I use both outputs at the same time to connect all of them to
different destinations? Do they appear in ALSA/JACK as 2 or 4 different
ports?
* Last but not least: Does it run at full duplex (2 ins and outs at the
same time), and what latency can it provide (the lower the better :) ?
Best regards
ce
17 Nov
17 Nov
9:25 p.m.
Hello there..
I'm also interested in this device, and some of the reading I've
done will allow me to answer a couple of your questions.. hopefully
the answers might even not be completely wrong :)
* I read it is bus powered; but I wonder how can it
get 48V phantom
power from the USB bus?!?
I think the phantom power is supplied at a few milliamps, hence not
much power is needed, just a resistor with the right value, since
V=IR, right? (Correction welcomed from actual EE's :)
* I read somewhere on the web that there was a little
hiss on the
inputs. Can anyone confirm this, and is it OK or too much?
If you read what I did,
( http://music.columbia.edu/pipermail/linux-audio-user/2005-October/027689.ht…
)
the hiss was from the components inside the unit, not on the input
channels, I think. Comments about the sound quality I've seen have
been positive.
* Can I use both outputs at the same time to connect
all of them to
different destinations? Do they appear in ALSA/JACK as 2 or 4 different
ports?
I'm pretty sure you can only run two output channels (or 1 stereo)
at one time, that is I think you'll get only 2 ports in alsa.
I'm not sure whether the different physical output ports on the device
run simultaneously, but it would seem strange not to. Don't know
about the digital output, though.
* Last but not least: Does it run at full duplex (2
ins and outs at the
same time), and what latency can it provide (the lower the better :) ?
From the info at edirol.net, it will run in full duplex
at up to 48KHz, and
"half duplex", either in or out, at 96KHz.
I gather from the downloadable manual that it will only do 16/44.1
with advanced mode switched to off, and only 24bits with advanced
mode on, at least under windows. I'd be interested to know whether
16/48 could be achieved under Linux, despite this (ie if it's a limitation
of the windows drivers).
A user on this list reported latencies around 5ms a few months ago
http://lalists.stanford.edu/lau/2005/07/1233.html
If ua-25 owners that happen to read this could make an entry
at http://www.qbik.ch/usb/devices/ it would be very helpful!
Now, not to hijack your thread, or anything, ... but ... ;)
I've also been looking at the UR-80 - which has similar features to
the UA-25, minus the limiters and the loopback feature, but with
a 43-control midi controller interface added (they are very cheap
at one online store I've looked at, about the same price as the UA-25,
which seems a good deal).
Clemens Ladisch was helping someone get this going, but (from
looking at the archives) the attempt fizzled out when a request to
provide lsusb -v output at the different settings went unanswered
(sort of). I'd guess it could be made to work. Apparently there is
an alsa patch especially for it, but I don't know if that means the
controller stuff will work, and how much of it.
Any info on this device under Linux would be very interesting to me.
Also any info on ua-25 alternatives, as in my (unanswered (sob) ) post
of a few days ago..
Cheers,
- Pete.
18 Nov
18 Nov
3:28 a.m.
Pete Leigh wrote:
The advanced mode is supported in Linux.
* Last but not
least: Does it run at full duplex (2 ins and outs at the
same time), and what latency can it provide (the lower the better :) ?
From the info at edirol.net, it will run in full duplex at up to 48KHz, and
"half duplex", either in or out, at 96KHz.
I gather from the downloadable manual that it will only do 16/44.1
with advanced mode switched to off, and only 24bits with advanced
mode on, at least under windows. I'd be interested to know whether
16/48 could be achieved under Linux, despite this (ie if it's a limitation
of the windows drivers). I've also been looking at the UR-80 - which has
similar features to
the UA-25, minus the limiters and the loopback feature, but with
a 43-control midi controller interface added (they are very cheap
at one online store I've looked at, about the same price as the UA-25,
which seems a good deal).
Clemens Ladisch was helping someone get this going, but (from
looking at the archives) the attempt fizzled out when a request to
provide lsusb -v output at the different settings went unanswered
(sort of). I'd guess it could be made to work.
Yes.
Apparently there is an alsa patch especially for it,
but I don't know
if that means the controller stuff will work, and how much of it.
The quirk is for the MIDI port, which means that probably _only_ the
controller stuff will work.
Regards,
Clemens
5:50 a.m.
On 18/11/05, Clemens Ladisch <clemens(a)ladisch.de> wrote:
Anyone know if the advanced mode can be coerced into 16 bits?
I mean, if I run jack with -S, to force 16 bit mode, will it fail, if the device
is set in advanced mode?
(I'm worried about hd bandwidth at 96/24 because I only have a slow
hd at the moment, and also I have this possibly useless idea to
use the onboard soundcard for a monitor, with the usb device only
sending input, while recording... since the onboard device is 16bits
only, it seems this would be easier with 16 bit input)
Right - I noticed the patch was for midi - I didn't know whether it was
just for the pass-through midi to work :)
[in another mail]
Pete Leigh wrote:
I gather from
the downloadable manual that it will only do 16/44.1
with advanced mode switched to off, and only 24bits with advanced
mode on, at least under windows. I'd be interested to know whether
16/48 could be achieved under Linux, despite this (ie if it's a limitation
of the windows drivers).
The advanced mode is supported in Linux. Apparently
there is an alsa patch especially for it, but I don't know
if that means the controller stuff will work, and how much of it.
The quirk is for the MIDI port, which means that probably _only_ the
controller stuff will work. All USB audio devices move data in one-millisecond
packets, so the achievable
latency depends _only_ on the software, not on what device you use.
Just to be clear, then, does "All USB" include USB 2.0, so that 1.1 and 2.0 are
equivalent for latency, and differ only in bandwidth?
Cheers,
- Pete.
7:56 a.m.
Pete Leigh wrote:
USB 2.0 uses 8000 microframes per second, but EHCI don't interrupt more often
than once per millisecond by default, so it doesn't make a difference.
Regards,
Clemens
On 18/11/05, Clemens Ladisch
<clemens(a)ladisch.de> wrote:
Anyone know if the advanced mode can be coerced into 16 bits?
Advanced mode has 24 bits only.
Pete Leigh wrote:
I gather
from the downloadable manual that it will only do 16/44.1
with advanced mode switched to off, and only 24bits with advanced
mode on, at least under windows. I'd be interested to know whether
16/48 could be achieved under Linux, despite this (ie if it's a
limitation of the windows drivers).
The advanced mode is supported in Linux. I mean, if I run jack with -S, to force 16 bit mode,
will it fail, if the
device is set in advanced mode?
No, jack just tries to use 16 bits first.
(I'm worried about hd bandwidth at 96/24 because I
only have a slow
hd at the moment,
This shouldn't matter.
and also I have this possibly useless idea to use the
onboard soundcard for
a monitor, with the usb device only sending input, while recording... since
the onboard device is 16bits only, it seems this would be easier with 16 bit
input)
Those devices won't use the same clock anyway.
All USB audio
devices move data in one-millisecond packets, so the
achievable latency depends _only_ on the software, not on what device you
use.
Just to be clear, then, does "All USB" include USB 2.0, so that 1.1 and 2.0
are equivalent for latency, and differ only in bandwidth?
8:14 a.m.
On 18/11/05, Clemens Ladisch <clemens(a)ladisch.de> wrote:
USB 2.0 uses 8000 microframes per second, but EHCI
don't interrupt more often
than once per millisecond by default, so it doesn't make a difference.
[and much other useful and clear information]
Thanks, Clemens! I think I might just take my chances on the UR-80, so
make sure your "please show the lsusb -v output for this device" keyboard
macro is up and running ;-)
Seriously, thanks for your input - much appreciated.
- Pete.
8:30 a.m.
Pete Leigh wrote:
On 18/11/05, Clemens Ladisch <clemens(a)ladisch.de>
wrote:
So latency doesn't improve over USB 2.0? That's interesting.
Thanks.
c.
USB 2.0 uses 8000 microframes per second, but EHCI
don't interrupt more often
than once per millisecond by default, so it doesn't make a difference.
[and much other useful and clear information]
Thanks, Clemens! I think I might just take my chances on the UR-80, so
make sure your "please show the lsusb -v output for this device" keyboard
macro is up and running ;-)
Seriously, thanks for your input - much appreciated.
- Pete.
4:11 p.m.
If ua-25 owners that happen to read this could make an
entry
at http://www.qbik.ch/usb/devices/ it would be very helpful!
Done ;-) .
Best regards
ce
17 Nov
17 Nov
9:45 p.m.
I'm using an UA-25 and it works plug and play, but having difficulties
with my gf UA-20 which doesn't get recognized by alsa, unless it is
switched in 16bit mode.
I can run it at 11.6ms (5.8+5.8) full duplex without any xrun. Lower
latencies work but I get some xrun every now and then. Anyway I doubt
you can get a greater bandwith with usb 1 at 24bit.
On jack you get 2 separate inputs and 2 outputs.
I get some hiss when I turn it on. It is not in the recording, you can
hear it coming from the interface itself, but it goes away after a
minute or two, when components are warmed up.
I successfully recorded with a phantom powered AKG3000b. Quality is awesome.
I strongly suggest it if you need an usb solution.
c.
-
www.cesaremarilungo.com
Christoph Eckert wrote:
Hi,
I'm looking for a device, mainly to get better audio quality as my
Aureon offers (16Bits only), and to record some acoustic guitar and
mics.
AFAIK the Edirol UA-25 works plug and play with snd_usb_audio, but still
some questions:
* I read it is bus powered; but I wonder how can it get 48V phantom
power from the USB bus?!?
* I read somewhere on the web that there was a little hiss on the
inputs. Can anyone confirm this, and is it OK or too much?
* Can I use both outputs at the same time to connect all of them to
different destinations? Do they appear in ALSA/JACK as 2 or 4 different
ports?
* Last but not least: Does it run at full duplex (2 ins and outs at the
same time), and what latency can it provide (the lower the better :) ?
Best regards
ce
18 Nov
18 Nov
3:37 a.m.
Cesare Marilungo wrote:
I can run it at 11.6ms (5.8+5.8) full duplex without
any xrun. Lower
latencies work but I get some xrun every now and then.
All USB audio devices move data in one-millisecond packets, so the achievable
latency depends _only_ on the software, not on what device you use.
Anyway I doubt you can get a greater bandwith with usb
1 at 24bit.
The theoretical limit of USB 1.x is 12 Mb/s (i.e., 1,500,000 bytes/s).
The Audigy 2 NX can do eight channels with 16 bits at 48 kHz (750 KB/s),
but full duplex stereo with 24 bits at 96 kHz would need 1125 KB/s which
is too much considering the protocol overhead.
Regards,
Clemens
4:09 a.m.
Clemens Ladisch wrote:
Cesare Marilungo wrote:
Is it true? I didn't know.
I can run it at 11.6ms (5.8+5.8) full duplex
without any xrun. Lower
latencies work but I get some xrun every now and then.
All USB audio devices move data in one-millisecond packets, so the achievable
latency depends _only_ on the software, not on what device you use.
Anyway I doubt
you can get a greater bandwith with usb 1 at 24bit.
The theoretical limit of USB 1.x is 12 Mb/s (i.e., 1,500,000 bytes/s).
The Audigy 2 NX can do eight channels with 16 bits at 48 kHz (750 KB/s),
but full duplex stereo with 24 bits at 96 kHz would need 1125 KB/s which
is too much considering the protocol overhead.
Regards,
Clemens
7:33 a.m.
Cesare Marilungo wrote:
Clemens Ladisch wrote:
I still have some doubts. 24bits at 48 kHz full duplex in stereo is
4.8Mb/s which is less than half the total theoretical bandwidth. But
we're talking about something that must be realtime without loosing
anything. How does latency relate to this? I'm not much into such
technical aspects but I believe that with more bandwidth and less
latency you need more processor time and speed. So, pratically with
current hw you can't go too far with usb 1.0. I achieved 5ms total
latency but the system was unstable, on a 2GHz AMD64.
Please correct me if I'm wrong. I just want to learn.
Anyway do you have experience with this Audigy NX? What about the
latency? My brother has an older Audigy (PCI not USB) and with the
original drivers he get 1sec of latency (300ms in + 700out).
Cesare Marilungo wrote:
Is it true? I didn't know.
I can run it at 11.6ms (5.8+5.8) full duplex
without any xrun. Lower
latencies work but I get some xrun every now and then.
All USB audio devices move data in one-millisecond packets, so the
achievable
latency depends _only_ on the software, not on what device you use.
Anyway I
doubt you can get a greater bandwith with usb 1 at 24bit.
The theoretical limit of USB 1.x is 12 Mb/s (i.e., 1,500,000 bytes/s).
The Audigy 2 NX can do eight channels with 16 bits at 48 kHz (750 KB/s),
but full duplex stereo with 24 bits at 96 kHz would need 1125 KB/s which
is too much considering the protocol overhead.
Regards,
Clemens
8:11 a.m.
Cesare Marilungo wrote:
Yes, at 48 kHz it would work.
Clemens
Ladisch wrote:
> The theoretical limit of USB 1.x is 12 Mb/s (i.e., 1,500,000 bytes/s).
> The Audigy 2 NX can do eight channels with 16 bits at 48 kHz (750 KB/s),
> but full duplex stereo with 24 bits at 96 kHz would need 1125 KB/s which
> is too much considering the protocol overhead.
I still have some doubts. 24bits at 48 kHz full duplex in stereo is
4.8Mb/s which is less than half the total theoretical bandwidth. But we're talking about something that must be
realtime without loosing
anything. How does latency relate to this?
The USB host controller will send one packet per millisecond in hardware.
The latency depends on whether the computer is able to schedule your program
with a delay small enough so that it can write more data to the buffer in time.
Anyway do you have experience with this Audigy NX?
No, only with the Audigy 2 NX. ;-)
What about the latency?
Like any other USB audio device. It depends on your computer.
On my machine, I can get about 2 ms (without anything else running), but I
didn't test much.
My brother has an older Audigy (PCI not USB)
PCI is completely different.
and with the original drivers he get 1sec of latency
(300ms in + 700out).
I hope you are not speaking about snd-emu10k1 here ...
Regards,
Clemens
4:18 p.m.
What about the
latency?
Like any other USB audio device. It depends on your computer.
On my machine, I can get about 2 ms (without anything else running),
but I didn't test much.
4:43 p.m.
On 18/11/05, Christoph Eckert <ce(a)christeck.de> wrote:
I wonder what I should try next. RT-LSM?
This might be a good start:
http://alsa.opensrc.org/TerratecAureonUSB5.1
- Pete.
4:55 p.m.
Hi,
thanks a lot.
OTOH, this is a page that I created myself ;-) .
As far as I have read, RT-LSM does not work on 2.6.14 kernels; but maybe
I'll just try it out.
Best regards
ce
I wonder what
I should try next. RT-LSM?
This might be a good start:
http://alsa.opensrc.org/TerratecAureonUSB5.1 
5:58 p.m.
On Fri, 2005-11-18 at 21:19 +0100, Christoph Eckert wrote:
well, just bought the UA-25, but the latency is horrible with the new
vanilla 2.6.14.2. I tried to build a second 2.6.14 with ingo's patch
applied, but my machine doesn't boot this kernel.
First, try to provide a useful bug report. "The latency is horrible" is
not much better than "it doesn't work".
Is this with JACK? Running in realtime mode? What settings? Which
clients? How bad is the latency?
What about the latency?
Like any other USB audio device. It depends on your computer.
On my machine, I can get about 2 ms (without anything else running),
but I didn't test much. I wonder what I should try next. RT-LSM?
No RT LSM only makes realtime scheduling available to users other than
root. It won't help you get "better latency" from your audio device.
Lee
6:48 p.m.
Hi Lee,
First, try to provide a useful bug report. "The
latency is horrible"
is not much better than "it doesn't work".
you're right, sorry for that.
Is this with JACK? Running in realtime mode? What
settings? Which
clients? How bad is the latency?
I just did my first tests with aeolus, the organ synth.
It runs on top of JACK which I run in conjunction with qjackctl.
I have a 2.6.14.2 vanilla kernel installed.
Additionally I have installed RT-LSM. The module is loaded and grants
any user access to it.
I now get much better results. I run JACK as
/usr/local/bin/jackd
-R -P83 -p64 -dalsa -r48000 -p256 -n3 -D -Chw:2 -Phw:2
qjackctl tells me about 16msecs latency with these settings. No prob
playing aeolus, but I plan to pipe audio material (playing the guitar
and the bass) through my computer so less latency would be great.
I also have edited /etc/security/limits.conf as found on the web. It now
contains something like
@audio - rt_priority 95
@audio - nice -10
@audio - memlock 300000
but to be honest I have no clue which app read or use this.
I have also a program installed which reads as set_rtlimits and one
which reads as setpcaps, but to be honest, I do not know at all how
these relate to each other and how to use them.
This means that any wee small hint that gives me a starting point is
much appreciated.
Thanks & best regards
ce
19 Nov
19 Nov
7:25 a.m.
I also have
edited /etc/security/limits.conf as found on the web.
It now contains something like
@audio - rt_priority 95
@audio - nice -10
@audio - memlock 300000
but to be honest I have no clue which app read or use this.
PAM.
3:01 p.m.
On Sat, 2005-11-19 at 12:25 +0100, Christoph Eckert wrote:
Thanks a lot.
I always denied to get familiar with PAM, but it looks like there's no
way around it ;-) .
There is, just ignore all this and use the realtime LSM until the
distros get it sorted out. It's insane to expect normal users to
modify /etc/security/limits.conf and understand PAM.
Lee
I also have edited /etc/security/limits.conf as found
on the web.
It now contains something like
@audio - rt_priority 95
@audio - nice -10
@audio - memlock 300000
but to be honest I have no clue which app read or use this.
PAM.
4:01 p.m.
There is, just ignore all this and use the realtime
LSM until the
distros get it sorted out. It's insane to expect normal users to
modify /etc/security/limits.conf and understand PAM.
OK, I have the RT-LSM installed, but I'd like to improve the latency of
my system. Any hints where to start tweaking the system?
Unfortunately, the patches of ingo produce a kernel which doesn't boot
on my machine, regardless that I codpied the .config from the vanilla
2.6.14.2.
I thought it needs tweaking PAM, but as I understand you correctly, PAM
only deals with permissions which I already achieved via RT-LSM.
I set
HZ_1000 [=y]
and
(X) Preemptible Kernel (Low-Latency Desktop)
in my kernel config, but I "only" get latencies around 16 msecs and
still some glitches from time to time.
Are there further tricks on a standard kernel I could try to improve
latency?
Thanks & best regards
ce
8:02 p.m.
I can get 11ms without issues or 5ms (sometimes even less when the setup
is simple) with this card. But on some distros I had to disable my
ethernet adapter. Are you sure you don't have some heavy process or
server running?
Also, I load the realtime module with the parameter any=1. I know this
could be less stable, but its worth if you need to record your music
without interruptions and with a low latency.
cesare
p.s. Please guys help me with my UA-20. :-(
Christoph Eckert wrote:
There is, just
ignore all this and use the realtime LSM until the
distros get it sorted out. It's insane to expect normal users to
modify /etc/security/limits.conf and understand PAM.
OK, I have the RT-LSM installed, but I'd like to improve the latency of
my system. Any hints where to start tweaking the system?
Unfortunately, the patches of ingo produce a kernel which doesn't boot
on my machine, regardless that I codpied the .config from the vanilla
2.6.14.2.
I thought it needs tweaking PAM, but as I understand you correctly, PAM
only deals with permissions which I already achieved via RT-LSM.
I set
HZ_1000 [=y]
and
(X) Preemptible Kernel (Low-Latency Desktop)
in my kernel config, but I "only" get latencies around 16 msecs and
still some glitches from time to time.
Are there further tricks on a standard kernel I could try to improve
latency?
Thanks & best regards
ce
8:21 p.m.
Hi,
I can get 11ms without issues or 5ms (sometimes even
less when the
setup is simple) with this card. But on some distros I had to disable
my ethernet adapter. Are you sure you don't have some heavy process
or server running?
No server or process is running, except for KDE ;-) .
It is likely that my interrupts cause problems. Thanks to the post of
"thewade" I found on my machine:
cat /proc/interrupts
CPU0
0: 1320101 XT-PIC timer
1: 3169 XT-PIC i8042
2: 0 XT-PIC cascade
8: 2 XT-PIC rtc
11: 1311823 XT-PIC Intel 82801CA-ICH3, Intel 82801CA-ICH3
Modem, uhci_hcd:usb1, uhci_hcd:usb2,eth0, yenta, yenta, ohci1394,
nvidia
12: 114 XT-PIC i8042
14: 51597 XT-PIC ide0
NMI: 0
LOC: 0
ERR: 0
MIS: 0
It seems that interrupt 11 is a bit overcrowded, but I have no clue how
to put the USB bus to another IRQ.
Also, I load the realtime module with the parameter
any=1. I know
this could be less stable, but its worth if you need to record your
music without interruptions and with a low latency.
If I understood correctly, the realtime module does nothing else than
grant non-root-users access to realtime priorities. It doesn't change
any further latency settigns on your machine.
p.s. Please guys help me with my UA-20. :-(
I'm sorry, but I really have no knowledge to help you on this issue.
Best regards
ce
»Wer Visionen hat, sollte zum Arzt gehen« (Helmut Schmidt)
9:16 p.m.
On 20/11/05, Christoph Eckert <ce(a)christeck.de> wrote:
11: 1311823 XT-PIC Intel 82801CA-ICH3,
Intel 82801CA-ICH3
Modem, uhci_hcd:usb1, uhci_hcd:usb2,eth0, yenta, yenta, ohci1394,
nvidia
It seems that interrupt 11 is a bit overcrowded, but I
have no clue how
to put the USB bus to another IRQ.
In a post at http://lalists.stanford.edu/lau/2005/03/0266.html someone else
with a UA-25 suggests using acpi_irq_balance kernel boot parameter
He was also sufferning stability problems, which, if I read and remembered
correctly, were fixed by unloading his NIC module...
- Pete.
21 Nov
21 Nov
1:28 p.m.
In a post at
http://lalists.stanford.edu/lau/2005/03/0266.html
someone else with a UA-25 suggests using acpi_irq_balance kernel boot
parameter
OTOH I heard that ACPI should be better disabled for audio kernels, so I
did.
Thanks anyway for the pointer!
Best regards
ce
2:04 p.m.
On Mon, 2005-11-21 at 18:28 +0100, Christoph Eckert wrote:
This doesn't really apply anymore, the kernel bugs in question are
thought to be fixed. I run with ACPI enabled now and have not had a
problem in months.
Lee
In a post at
http://lalists.stanford.edu/lau/2005/03/0266.html
someone else with a UA-25 suggests using acpi_irq_balance kernel boot
parameter
OTOH I heard that ACPI should be better disabled for audio kernels, so I
did.
2:13 p.m.
This doesn't really apply anymore, the kernel bugs
in question are
thought to be fixed. I run with ACPI enabled now and have not had a
problem in months.
Thanks a lot for the info.
Unfortunately, my Dell notebook (inspiron 8200) has some problems with
ACPI; but thanks to your info I'll try again.
Best regards
ce
3:27 p.m.
On 21/11/05, Lee Revell <rlrevell(a)joe-job.com> wrote:
On Mon, 2005-11-21 at 18:28 +0100, Christoph Eckert
wrote:
> OTOH I heard that ACPI should be better disabled
for audio kernels, so I
> did.
This doesn't really apply anymore, the kernel bugs
in question are
thought to be fixed. I run with ACPI enabled now and have not had a
problem in months.
I've been wondering about the 'acpi over smm' problems mentioned
on this list in Oct '04 for a while now - the problem doesn't seem to
get mentioned, yet I couldn't find a resolution in the list archives
(I could have missed it though).
(I mean the thread "Latency issues with laptops", at
http://music.columbia.edu/pipermail/linux-audio-user/2004-October/016545.ht… )
Does anyone know what the current state of play with this is?
Did the blacklist ever materialise, and is there any method of detecting
whether a particular laptop has the issue?
Cheers,
- Pete.
4:09 p.m.
On Mon, 2005-11-21 at 19:27 +0000, Pete Leigh wrote:
On 21/11/05, Lee Revell <rlrevell(a)joe-job.com>
wrote:
Not really. Acer laptops seem particularly bad. And, it turns out that
some chipsets have a way to disable SMM, which is used by RTAI, so maybe
this can be worked around. But, as the problem is broken hardware,
there will never be a real fix.
The best approach is probably to ask on this list whether anyone has
tried a particular laptop.
Lee
On Mon, 2005-11-21 at 18:28 +0100, Christoph
Eckert wrote:
> OTOH I heard that ACPI should be better
disabled for audio kernels, so I
> did.
This doesn't really apply anymore, the kernel
bugs in question are
thought to be fixed. I run with ACPI enabled now and have not had a
problem in months.
I've been wondering about the 'acpi over smm' problems mentioned
on this list in Oct '04 for a while now - the problem doesn't seem to
get mentioned, yet I couldn't find a resolution in the list archives
(I could have missed it though).
(I mean the thread "Latency issues with laptops", at
http://music.columbia.edu/pipermail/linux-audio-user/2004-October/016545.ht… )
Does anyone know what the current state of play with this is?
Did the blacklist ever materialise, and is there any method of detecting
whether a particular laptop has the issue?
6760
days inactive
6764
days old
linux-audio-user@lists.linuxaudio.org
30 comments
6 participants
participants (6)
-
Cesare Marilungo -
Christoph Eckert -
Clemens Ladisch -
Lee Revell -
Noah Roberts -
Pete Leigh