20 Feb
2003
20 Feb
'03
10:07 p.m.
I'm trying to run a low latency kernel and audio applications on a
crusoe processor laptop.
Yes, I'm crazy.
I have patched a 2.4.20 kernel with the low latency, preemption, and
variable hz patches, as well as a modification to the alim15x3 DMA code
and an extra entry in the "unusual USB devices" list. I'm running recent
CVS checkouts of ALSA from Planet CCRMA.
The kernel works well, and the low latency patches really make the
system more responsive even under load. However, when I run
latencytest0.42/do_test blah blah, the system hangs while playing the
sound. It does not even display the xperf window. After a very long
time, Control-C stops the process.
When I run jack -R (jack 0.55) and freqtweak, freqtweak claims it gets
"shut down" by jack the first time I try to start it. The second time I
try to start it, it connects to jack and plays for a few seconds, but
then audio stops and the system hangs. I need to use sysrq or a power
cycle to restart.
I can send pretty good beer, the alim15x3 patch, and any other clues to
anyone who can help me with this.
--
(jfm3 2838 BCBA 93BA 3058 ED95 A42C 37DB 66D1 B43C 9FD0)
21 Feb
21 Feb
4:34 a.m.
On Thu, 2003-02-20 at 17:59, jfm3 wrote:
I'm trying to run a low latency kernel and audio
applications on a
crusoe processor laptop.
Yes, I'm crazy.
I have patched a 2.4.20 kernel with the low latency, preemption, and
variable hz patches, as well as a modification to the alim15x3 DMA code
and an extra entry in the "unusual USB devices" list. I'm running recent
CVS checkouts of ALSA from Planet CCRMA.
The kernel works well, and the low latency patches really make the
system more responsive even under load. However, when I run
latencytest0.42/do_test blah blah, the system hangs while playing the
sound. It does not even display the xperf window. After a very long
time, Control-C stops the process.
When I run jack -R (jack 0.55) and freqtweak, freqtweak claims it gets
"shut down" by jack the first time I try to start it. The second time I
try to start it, it connects to jack and plays for a few seconds, but
then audio stops and the system hangs. I need to use sysrq or a power
cycle to restart.
I can send pretty good beer, the alim15x3 patch, and any other clues to
anyone who can help me with this.
--
(jfm3 2838 BCBA 93BA 3058 ED95 A42C 37DB 66D1 B43C 9FD0)
Have you gotten things to work without the patches?
Something I have found really useful in these situations is to setup
another machine as a serial console, can't remember if you use a NULL
modem cable or not), (read Documentation/serial-console.txt in the
kernel source). You will then be able to get kernel output messages even
after all user space programs have died. You will most likely get an
oops output and can then save this to a file on the other machine,
reboot your crusoe and run the oops output through ksymoops. Hope that
helps. BTW, what kind of beer? :) Cheers.
Josh Green
5:35 a.m.
I'm trying to run a low latency kernel and audio
applications on a
crusoe processor laptop.
Yes, I'm crazy.
You might want to take a look at the following:
http://www.mindcontrol.org/~hplus/aes-2001
In slide 5/6 three different processors are compared and the 400 MHz
Transmeta Crusoe is said to have a 1000 us interrupt latency whereas
a 600 MHz Intel Celeron processor has a 80 us interrupts latency,
both running BeIA/BeOS. This is probably related to code morphing.
Maybe more recent Crusoes aren't affected.
--ms
10:14 a.m.
On Fri, 21 Feb 2003, Martijn Sipkema wrote:
In slide 5/6 three different processors are compared
and the 400 MHz
Transmeta Crusoe is said to have a 1000 us interrupt latency whereas
a 600 MHz Intel Celeron processor has a 80 us interrupts latency,
both running BeIA/BeOS. This is probably related to code morphing.
Maybe more recent Crusoes aren't affected.
I would think that Crusoes would inheiritly have greater latency than
traditional x86 CPUs. After all, important parts of the CPU are done in
software. It's almost like using an emulator.
Taybin
11:58 a.m.
On Fri, 2003-02-21 at 04:28, Martijn Sipkema wrote:
Hmm. I have a feeling he is couting sound card latency or perhaps other
things to come up with his 11 ms measurement.
My understanding of hardware is only rudimentary. Interrupt latency is
the time between a hardware event actually happening and code to service
that event beginning to run? If it is code morphing and the mindcontrol
guy's numbers are right, then I should have around 500 us interrupt
latency, since my processor is 872 MHz and the one in his presentation
is 400 MHz. There have also been a few revisions of the code morphing
software since those slides were made.
An additional 400 us of latency due to code morphing is something I can
live with for my applications. If I can get an upper bound of 5 ms from
MIDI hitting the interface to sound coming out of the headphone jack, I
will be satisfied. As things are, jack and it's first client hang the
system.
Further investigation has revealed that PD does not hang when it talks
directly to ALSA, even when it runs with realtime priority. Although I
do require 11 size 128 "frags" to do audio without dropouts, it is my
(again, limited) understanding that this can be mitigated somewhat by
using a lower latency (pcmcia) sound card. A curious problem is that
after you run PD a few times, the mixer starts behaving strangely. I now
suspect something is amiss in ALSA.
--
(jfm3 2838 BCBA 93BA 3058 ED95 A42C 37DB 66D1 B43C 9FD0)
I'm trying
to run a low latency kernel and audio applications on a
crusoe processor laptop.
Yes, I'm crazy.
You might want to take a look at the following:
http://www.mindcontrol.org/~hplus/aes-2001
In slide 5/6 three different processors are compared and the 400 MHz
Transmeta Crusoe is said to have a 1000 us interrupt latency whereas
a 600 MHz Intel Celeron processor has a 80 us interrupts latency,
both running BeIA/BeOS. This is probably related to code morphing.
Maybe more recent Crusoes aren't affected. 
12:07 p.m.
using a lower latency (pcmcia) sound card. A curious
problem is that
after you run PD a few times, the mixer starts behaving strangely. I now
suspect something is amiss in ALSA.
as i understand it, in ALSA CVS there is now a test for JACK that
disables certain code if JACK appears to be likely to be used jaroslav
doesn't understand why this code in combination with JACK should cause
a kernel oops.
--p
7747
days inactive
7748
days old
linux-audio-dev@lists.linuxaudio.org
5 comments
5 participants
participants (5)
-
jfm3 -
Josh Green -
Martijn Sipkema -
Paul Davis -
Taybin Rutkin