12 Feb
2006
12 Feb
'06
12:18 a.m.
Hi,
I am working with this kernel right now. I compiled it into my
GNU Linux box (Musix 0.30) following:
http://ubuntustudio.com/wiki/index.php/Breezy:Vanilla_Kernel_With_Realtime_…
And it works fine, but with a few "bugs" or problems.
You can download it from:
http://www.k-maleon.com/musix/deb
Tests:
PC Duron 1800Mhz, 120Mb RAM, HD 7200 RPM, SB Live!
sáb feb 11 18:34:03 CET 2006
Kernel: Musix GNU/Linux, kernel 2.6.15.3-rt-musix-2006-11-02
*rtirq works normally
*Normal users can use RT
*With:
/usr/bin/jackd -R -P89 -t1000 -m -dalsa -dhw:0 -r44100 -p512 -n2 -s -S
-i1
* Good: Ardour with 7 tracks and a lot of LADSPA FX: it worked well
enough, using jackd in duplex and play only mode (with a 512 buffer,
44100Hz)
* BAD: into this session, I opened JAMIN and all the system went
very slow. Then I restarted jack into play only mode and it worked
well: I could master the tracks connected to Jamin from Ardour outputs.
lesser buffer size:
* Regular: JAMIN, jackd duplex, buffer 256, it works fine, but whe i
opened ardour: 4 (28) xruns while the hard disk was reading/writing. I
think that with more ram than my little 120Mb it can do it much better.
* Fine: jack: 48000 Hz, 1024 or 128 buffer (46ms latency or 5ms
latency), play only mode, Ardour with 7 tracks: NO XRUNs at all.
I opened Jamin and all goes well with 1024 buffer, but with the 128
buffer the system just got paralyzed.
Hope it can help or serve you.
Musix uses the DeMuDi kernel (when installed on HD).
I'm needing to make a RT kernel that could boot from the Live-CD out of
the box, so I am experimenting with it. I could not compile unionfs,
but I will try again in these days.
Cheers,
--
Marcos Guglielmetti
Coordinador del desarrollo de Musix GNU+Linux
(www.musix.org.ar)
Mirrors: (www.musix.distrux.net) (www.pc-musica.com.ar/musix)
(www.k-maleon.com/musix)
________________________________________________
¡Llamá a todo el mundo con las mejores tarifas!
Comprá tus tarjetas de llamadas en tres simples pasos
en Yahoo! Telefonía: http://yahoo.tarjetastelefonicas.com
12 Feb
12 Feb
8:04 a.m.
Just to say that I repeated the same tests with 2.6.13-1-multimedia-386
from DeMuDi and the results are the same, but the system did not got
_totally_ paralyzed when i used ardour+jamin with jackd's 128 buffer:
it went super slow, unusable, but it did not got paralyzed in this
situation.
El Domingo, 12 de Febrero de 2006 01:15, Marcos Guglielmetti escribió:
Hi,
I am working with this kernel right now. I compiled it into
my GNU Linux box (Musix 0.30) following:
http://ubuntustudio.com/wiki/index.php/Breezy:Vanilla_Kernel_With_Rea
ltime_Preemption
And it works fine, but with a few "bugs" or problems.
You can download it from:
http://www.k-maleon.com/musix/deb
Tests:
PC Duron 1800Mhz, 120Mb RAM, HD 7200 RPM, SB Live!
sáb feb 11 18:34:03 CET 2006
Kernel: Musix GNU/Linux, kernel 2.6.15.3-rt-musix-2006-11-02
*rtirq works normally
*Normal users can use RT
*With:
/usr/bin/jackd -R -P89 -t1000 -m -dalsa -dhw:0 -r44100 -p512 -n2 -s
-S -i1
* Good: Ardour with 7 tracks and a lot of LADSPA FX: it worked
well enough, using jackd in duplex and play only mode (with a 512
buffer, 44100Hz)
* BAD: into this session, I opened JAMIN and all the system went
very slow. Then I restarted jack into play only mode and it worked
well: I could master the tracks connected to Jamin from Ardour
outputs.
lesser buffer size:
* Regular: JAMIN, jackd duplex, buffer 256, it works fine, but
whe i opened ardour: 4 (28) xruns while the hard disk was
reading/writing. I think that with more ram than my little 120Mb it
can do it much better.
* Fine: jack: 48000 Hz, 1024 or 128 buffer (46ms latency or 5ms
latency), play only mode, Ardour with 7 tracks: NO XRUNs at all.
I opened Jamin and all goes well with 1024 buffer, but with the 128
buffer the system just got paralyzed.
Hope it can help or serve you.
Musix uses the DeMuDi kernel (when installed on HD).
I'm needing to make a RT kernel that could boot from the Live-CD out
of the box, so I am experimenting with it. I could not compile
unionfs, but I will try again in these days.
Cheers,
--
Marcos Guglielmetti
Coordinador del desarrollo de Musix GNU+Linux
(www.musix.org.ar)
Mirrors: (www.musix.distrux.net) (www.pc-musica.com.ar/musix)
(www.k-maleon.com/musix)
___________________________________________________________
1GB gratis, Antivirus y Antispam
Correo Yahoo!, el mejor correo web del mundo
http://correo.yahoo.com.ar
10 a.m.
On 2/12/06, Marcos Guglielmetti <marcospcmusica(a)yahoo.com.ar> wrote:
Just to say that I repeated the same tests with
2.6.13-1-multimedia-386
from DeMuDi and the results are the same, but the system did not got
_totally_ paralyzed when i used ardour+jamin with jackd's 128 buffer:
it went super slow, unusable, but it did not got paralyzed in this
situation.
El Domingo, 12 de Febrero de 2006 01:15, Marcos Guglielmetti escribió:
>
> * BAD: into this session, I opened JAMIN and all the system went
> very slow. Then I restarted jack into play only mode and it worked
> well: I could master the tracks connected to Jamin from Ardour
> outputs.
<AND...>
>
> I opened Jamin and all goes well with 1024 buffer, but with the 128
> buffer the system just got paralyzed.
Jamin is very CPU intensive and this machine is probably of about
average or slightly slow CPU speed these days.
If you open a terminal and run top what do you see when it slows to a
crawl? Look with Jack operating in both play/record and play modes to
see what happens.
Good luck,
Mark
2:13 p.m.
El Domingo, 12 de Febrero de 2006 15:00, Mark Knecht escribió:
Thanks Mark: here there are the tests: (i forgot to overclock the cpu to
2000Mhz, I will do it again later, but:)
Reporting:
processor : 0
vendor_id : AuthenticAMD
cpu family : 6
model : 8
model name : AMD Duron(tm)
stepping : 1
cpu MHz : 1800.247
cache size : 64 KB
fdiv_bug : no
hlt_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 1
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 sep mtrr pge mca
cmov pat pse36 mmx fxsr sse syscall mmxext 3dnowext 3dnow
bogomips : 3604.15
MemTotal: 111164 kB
uname -a
Linux 030users 2.6.15.3-rt-musix #1 PREEMPT Sun Feb 12 12:24:53 CET 2006
i686 GNU/Linux
-----------
Only Jamin:
cat /root/.jackdrc
/usr/bin/jackd -R -P89 -t1000 -m -dalsa -dhw:0 -r48000 -p128 -n2 -P -s
-S
It works fine
--------
Only Jamin:
cat /root/.jackdrc
/usr/bin/jackd -R -P89 -t1000 -m -dalsa -dhw:0 -r48000 -p256 -n2 -s -S
-i1
Now, that's ok, ir works fine too
------
(Now jacks did not let me -p128)
creating alsa driver ... hw:0|hw:0|128|2|48000|1|0|nomon|swmeter|
soft-mode|16bit
control device hw:0
configuring for 48000Hz, period = 128 frames, buffer = 2 periods
ALSA: cannot set period size to 128 frames for capture
ALSA: cannot configure capture channel
cannot load driver module alsa
---------
Ardour + Jamin + JACK -p256 duplex mode
cat /root/.jackdrc
/usr/bin/jackd -R -P89 -t1000 -m -dalsa -dhw:0 -r48000 -p256 -n2 -s -S
-i1
Opening Ardour with a 7 tracks session with a lot of LADSPA plugins, I
got 1 (2) xruns
TOP:
5557 root 15 0 122m 41m 7544 S 46.0 38.0 1:19.84 ardour
5546 root 19 0 35732 1252 1088 S 3.6 1.1 0:03.49 jackd
When y press play, it gives 3 (22) xruns
Now I open Jamin and the system goes super slow (unusable)
TOP:
5557 root 15 0 122m 44m 7696 R 55.4 40.9 2:48.33 ardour
5863 root 16 0 44492 11m 7276 R 30.0 10.6 0:17.10 jamin
5546 root 19 0 35736 1292 1104 S 3.1 1.2 0:06.71 jackd
741 root -81 -5 0 0 0 S 1.5 0.0 0:08.70 IRQ 10
4146 root 5 -10 115m 6328 2100 S 1.2 5.7 0:27.87 Xorg
xruns 5 (25)
--------
Ardour + Jamin + JACK -p256 play mode
cat /root/.jackdrc
/usr/bin/jackd -R -P89 -t1000 -m -dalsa -dhw:0 -r48000 -p256 -n2 -P -s
-S
Opening Ardour with a 7 tracks session with a lot of LADSPA plugins, I
got again 1 (2) xruns
With Ardour playing:
xruns: 3 (17)
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
6221 root 16 0 122m 38m 7312 S 61.3 35.6 0:50.28 ardour
4146 root 5 -10 114m 6624 1708 S 3.6 6.0 0:35.86 Xorg
4645 root 15 0 32320 5800 4404 S 3.0 5.2 0:06.99 konsole
6186 root 18 0 35720 1336 1092 S 2.7 1.2 0:01.78 jackd
741 root -81 -5 0 0 0 S 1.3 0.0 0:12.08 IRQ 10
Now I open Jamin and the system goes super slow again (unusable), but
not as slow it was before: a little less slow
TOP:
6221 root 16 0 122m 38m 7336 R 47.7 35.6 1:56.07 ardour
6433 root 17 0 44516 11m 7208 R 23.6 10.4 0:03.60 jamin
4146 root 5 -10 115m 7200 2068 S 2.6 6.5 0:37.93 Xorg
741 root -81 -5 0 0 0 S 1.4 0.0 0:13.07 IRQ 10
6186 root 18 0 35724 1372 1116 S 1.4 1.2 0:03.72 jackd
xruns: 4 (19)
-------------
Ardour + Jamin + JACK -p512 play mode
cat /root/.jackdrc
/usr/bin/jackd -R -P89 -t1000 -m -dalsa -dhw:0 -r48000 -p512 -n2 -P -s
-S
Opening Ardour with a 7 tracks session with a lot of LADSPA plugins, I
got again 1 (1) xruns
TOP:
6614 root 15 0 122m 44m 9088 S 56.7 40.7 0:30.05 ardour
4146 root 5 -10 114m 5316 1412 S 1.3 4.8 0:42.23 Xorg
6560 root 15 0 28912 7452 5800 S 1.3 6.7 0:01.63 qjackctl
741 root -81 -5 0 0 0 S 0.3 0.0 0:14.04 IRQ 10
4645 root 16 0 32320 5452 4100 R 0.3 4.9 0:08.01 konsole
Now I open Jamin and the system goes a little slower, but usable
TOP (without playing)
6614 root 15 0 122m 44m 9108 S 51.0 40.8 1:20.63 ardour
6734 root 15 0 44620 11m 7272 S 32.0 10.6 0:21.35 jamin
4146 root 5 -10 115m 6068 2012 S 2.4 5.5 0:44.65 Xorg
6580 root 20 0 35848 1272 1072 S 2.1 1.1 0:01.98 jackd
4645 root 15 0 32320 5856 4332 S 1.5 5.3 0:08.55 konsole
6560 root 15 0 28912 7544 5832 S 0.6 6.8 0:02.26 qjackctl
108 root 15 0 0 0 0 S 0.3 0.0 0:00.12 pdflush
189 root -60 -5 0 0 0 S 0.3 0.0 0:01.64 IRQ 12
741 root -81 -5 0 0 0 S 0.3 0.0 0:14.51 IRQ 10
6797 root 16 0 2196 1092 848 R 0.3 1.0 0:00.04 top
1 root 16 0 2036 416 388 S 0.0 0.4 0:00.12 init
TOP (playing from ardour connected to jamin)
6614 root 16 0 122m 44m 9144 R 55.3 40.8 2:25.51 ardour
6734 root 16 0 44744 11m 7332 R 38.5 10.7 1:02.06 jamin
4146 root 5 -10 115m 6200 2044 S 2.2 5.6 0:48.64 Xorg
6560 root 15 0 28912 7772 6020 S 1.1 7.0 0:03.47 qjackctl
741 root -81 -5 0 0 0 S 0.8 0.0 0:15.16 IRQ 10
3 root -2 0 0 0 0 S 0.6 0.0 0:00.93
softirq-timer/0
6580 root 20 0 35848 1272 1072 S 0.6 1.1 0:03.47 jackd
110 root 15 0 0 0 0 D 0.3 0.0 0:00.37 kswapd0
257 root -47 -5 0 0 0 S 0.3 0.0 0:02.97 IRQ 14
4129 root 30 15 3592 1976 500 R 0.3 1.8 0:02.55 preload
6897 root 16 0 2200 1092 848 R 0.3 1.0 0:00.07 top
xruns 4 (4)
--
Marcos Guglielmetti
Coordinador del desarrollo de Musix GNU+Linux
(www.musix.org.ar)
Mirrors: (www.musix.distrux.net) (www.pc-musica.com.ar/musix)
(www.k-maleon.com/musix)
___________________________________________________________
1GB gratis, Antivirus y Antispam
Correo Yahoo!, el mejor correo web del mundo
http://correo.yahoo.com.ar
On 2/12/06, Marcos Guglielmetti
<marcospcmusica(a)yahoo.com.ar> wrote:
> Just to say that I repeated the same tests with
> 2.6.13-1-multimedia-386 from DeMuDi and the results are the same,
> but the system did not got _totally_ paralyzed when i used
> ardour+jamin with jackd's 128 buffer: it went super slow, unusable,
> but it did not got paralyzed in this situation.
>
> El Domingo, 12 de Febrero de 2006 01:15, Marcos Guglielmetti
escribió:
> * BAD:
into this session, I opened JAMIN and all the system went
> very slow. Then I restarted jack into play only mode and it
> worked well: I could master the tracks connected to Jamin from
> Ardour outputs.
<AND...>
> I opened Jamin and all goes well with 1024
buffer, but with the
> 128 buffer the system just got paralyzed.
Jamin is very CPU intensive and this machine is probably of about
average or slightly slow CPU speed these days.
If you open a terminal and run top what do you see when it slows to a
crawl? Look with Jack operating in both play/record and play modes to
see what happens.
Good luck, 
1:24 p.m.
Marcos Guglielmetti <marcospcmusica(a)yahoo.com.ar> writes:
I am working with this kernel right now (2.6.15.3-rt)
The rt patches are not supposed to be compiled against such versions
as .1, .2 or .3, as far as I know, unless the patch is called f.ex
2.6.15.3-rt1. In most cases this will work, but it's not guaranteed
and therefor you should not report any issues you have.
This is how I understand it.
--
Esben Stien is b0ef@e s a
http://www. s t n m
irc://irc. b - i . e/%23contact
[sip|iax]: e e
jid:b0ef@ n n
2:29 p.m.
El Domingo, 12 de Febrero de 2006 20:14, Esben Stien escribió:
Marcos Guglielmetti
<marcospcmusica(a)yahoo.com.ar> writes:
Are you sure?
maybe!
I am using
http://people.redhat.com/mingo/realtime-preempt/patch-2.6.15-rt16
--
Marcos Guglielmetti
Coordinador del desarrollo de Musix GNU+Linux
(www.musix.org.ar)
Mirrors: (www.musix.distrux.net) (www.pc-musica.com.ar/musix)
(www.k-maleon.com/musix)
___________________________________________________________
1GB gratis, Antivirus y Antispam
Correo Yahoo!, el mejor correo web del mundo
http://correo.yahoo.com.ar
I am working with this kernel right now
(2.6.15.3-rt)
The rt patches are not supposed to be compiled against such versions
as .1, .2 or .3, as far as I know, unless the patch is called f.ex
2.6.15.3-rt1. In most cases this will work, but it's not guaranteed
and therefor you should not report any issues you have.
This is how I understand it. 
3:17 p.m.
On Sun, 2006-02-12 at 20:14 +0100, Esben Stien wrote:
Marcos Guglielmetti
<marcospcmusica(a)yahoo.com.ar> writes:
Yes but it's not like it's going to compile, run, then give you a ton of
xruns - it will either work fine, or fail to build/boot.
If it seems to be working this is not a problem.
I am working with this kernel right now
(2.6.15.3-rt)
The rt patches are not supposed to be compiled against such versions
as .1, .2 or .3, as far as I know, unless the patch is called f.ex
2.6.15.3-rt1. In most cases this will work, but it's not guaranteed
and therefor you should not report any issues you have.
This is how I understand it.
6:13 p.m.
El Domingo, 12 de Febrero de 2006 20:17, Lee Revell escribió:
On Sun, 2006-02-12 at 20:14 +0100, Esben Stien wrote:
Ok, so I think I will not try with
http://kernel.org/pub/linux/kernel/v2.6/linux-2.6.15.tar.bz2 because I
will have the same behaviorals. Am I right?
--
Marcos Guglielmetti
Coordinador del desarrollo de Musix GNU+Linux
(www.musix.org.ar)
Mirrors: (www.musix.distrux.net) (www.pc-musica.com.ar/musix)
(www.k-maleon.com/musix)
___________________________________________________________
1GB gratis, Antivirus y Antispam
Correo Yahoo!, el mejor correo web del mundo
http://correo.yahoo.com.ar
Marcos Guglielmetti
<marcospcmusica(a)yahoo.com.ar> writes:
Yes but it's not like it's going to compile, run, then give you a ton
of xruns - it will either work fine, or fail to build/boot.
If it seems to be working this is not a problem. I am working with this kernel right now
(2.6.15.3-rt)
The rt patches are not supposed to be compiled against such
versions as .1, .2 or .3, as far as I know, unless the patch is
called f.ex 2.6.15.3-rt1. In most cases this will work, but it's
not guaranteed and therefor you should not report any issues you
have.
This is how I understand it.
6:32 p.m.
On Sun, 2006-02-12 at 19:10 +0100, Marcos Guglielmetti wrote:
El Domingo, 12 de Febrero de 2006 20:17, Lee Revell
escribió:
Yes exactly. You will see the same behavior.
Lee
On Sun, 2006-02-12 at 20:14 +0100, Esben Stien
wrote:
Ok, so I think I will not try with
http://kernel.org/pub/linux/kernel/v2.6/linux-2.6.15.tar.bz2 because I
will have the same behaviorals. Am I right?
Marcos Guglielmetti
<marcospcmusica(a)yahoo.com.ar> writes:
Yes but it's not like it's going to compile, run, then give you a ton
of xruns - it will either work fine, or fail to build/boot.
If it seems to be working this is not a problem. I am working with this kernel right now
(2.6.15.3-rt)
The rt patches are not supposed to be compiled against such
versions as .1, .2 or .3, as far as I know, unless the patch is
called f.ex 2.6.15.3-rt1. In most cases this will work, but it's
not guaranteed and therefor you should not report any issues you
have.
This is how I understand it.
6920
days inactive
6921
days old
linux-audio-user@lists.linuxaudio.org
8 comments
4 participants
participants (4)
-
Esben Stien -
Lee Revell -
Marcos Guglielmetti -
Mark Knecht