[LAU] : jack CPU % is going crazy !
Mysth-R
mysthr21 at gmail.com
Tue Apr 8 08:27:07 EDT 2008
2008/4/7, Pieter Palmers <pieterp at joow.be>:
>
> Mysth-R wrote:
>
> >
> >
> > 2008/4/7, Pieter Palmers <pieterp at joow.be <mailto:pieterp at joow.be>>:
> >
> > Mysth-R wrote:
> >
> >
> >
> > 2008/4/7, Pieter Palmers <pieterp at joow.be
> > <mailto:pieterp at joow.be> <mailto:pieterp at joow.be
> > <mailto:pieterp at joow.be>>>:
> >
> >
> > Mysth-R wrote:
> >
> > I forgot to precise that my sound card is a Presonus
> > Firebox and
> > run with Freebob.
> > I got the idea to test with my U-control Uca202
> > (Behringer) Usb
> > sound-card, and there is no problems. The cpu percent is
> > quite
> > stable around 2,1%.
> > It is a bit strange because I got the rtirq script
> > congiured for
> > my firewire card. So it should not work better than my
> > firewire ...
> >
> > I am a bit lost !! :O[
> >
> >
> > Is the 'real' cpu time (e.g. from top) also that high? It
> > could be
> > that there is a bug in the time reporting of the freebob
> > backend,
> > resulting in a bad calculation of the cpu time.
> >
> > Greets,
> >
> > Pieter
> >
> >
> >
> > Hi,
> > It is very strange. I can't see a real correlation between cpu
> > load displayed by htop and the DSP load displayed by qjackctl.
> > In htop the cpu is quite unstable too, but it doesn'tt change at
> > the same time as the dsp load in qjackctl. Perhaps it is due to
> > a latency. but I can't say if is linked.
> > I have made some more test :
> >
> > 1- runing qjackctl with freebob backend : both dsp load
> > (qjackctl) and cpu load (htop) are unstable but not really
> > linked.
> > 2- runing qjackctl with alsa backend : dsp load is quite stable
> > but cpu load is unstable.
> > 3- running jackdmp in a console with Freebob then alsa : cpu
> > load is unstable.
> > 4- when jackdmp or qjackctl are killed : cpu load is normal
> > around 2% and stable.
> >
> > So :
> > Is it normal that the cpu load displayed in htop is unstable ?
> > If it is, then as you said pieter, could it be a bug with
> > freebob ??? I never saw this before, on the same laptop but with
> > 32bits OS.
> >
> > FreeBoB is guaranteed 110% bug-free.
> >
> >
> >
> > héhé :D
> >
> > Is there a problem in my kernel config ?
> > Is there a something wrong with jack or freebob with the 64bits
> > arch ?
> >
> > It could very well be a 64bit issue somewhere. I haven't tested
> > freebob on 64bit yet.
> >
> >
> >
> > Well, if someone as some idea for me to make more tests ... I
> > would be happy ;)
> >
> >
> > It might be interesting if you could figure out exactly what the
> > differences are between your setups. Mainly software versions etc...
> >
> >
> > well, on the same laptop I got a 32bits openSuse system and a gentoo
> > 64bits in dual boot.
> > I have tested on OpenSuse, with both Kde3.5 and Fvwm, just using
> > qjackctl 0.3.2 with jackd 0.109 and it works perfectly.
> > Now on my gentoo 64 bits I tryed on both Kde4.0 and Fvwm-crystal, just
> > using qjackctl 0.3.2 and jackdmp0.70. I also tryed with qjackctl 0.2.23 (in
> > case it was due to QT4 library) and jackdmp-svn and jackd 0.109 : in all the
> > case I got the cpu load problem.
> >
> > Do you think this is a firewire problem ? perhaps I forgot an important
> > option when I compiled my kernel (2.6.24-rt1)
> > I think I will try with another kernel. Will see if there is new kernel
> > available. otherwise I will try with an older (2.6.22 ...)
> >
> > Thank you for your answer.
> >
> > ps : pieter if you haven't tested freebob in 64 bits, perhaps you could
> > give me some guidelines, to test it and make a report for you ?
> >
>
> I don't really have a clue about what's going on, so it's pretty difficult
> to do so.
>
> Can you try running jack/freebob with a very high priority (e.g. -P99) to
> see if this changes things?
Hello,
I ran jackdmp/freebob with -P99 priority but nothing changed. But there is
something Strange. I can't give a -P99 priority directly in Qjackctl. The
max is 89. So I had to run jackdmp in a terminal, then run qjackctl in
"Active" mode.
Well sorry, after some more tests, it is a bit better with -P99 priority. It
is more stable around 3.5% and there are few peaks up to 28% or 53% whereas
with a lower priority (-P80) it is "stable" around 5% and there are many
more peaks up to 13, 22 or 28% and some up to 53%
Perhaps it is a problem with my configurations files
Here are my configuration files :
******************************* rtirq conf script
***************************************
# IRQ thread service names
# (space separated list, from higher to lower priority).
RTIRQ_NAME_LIST="rtc ohci1394 i8042"
# Highest priority.
RTIRQ_PRIO_HIGH=99
# Priority decrease step.
RTIRQ_PRIO_DECR=5
# Whether to reset all IRQ threads to SCHED_OTHER.
RTIRQ_RESET_ALL=0
# On kernel configurations that support it,
# which services should be NOT threaded
# (space separated list).
RTIRQ_NON_THREADED="rtc ohci1394"
# Process names which will be forced to the
# highest realtime priority range (99-91)
# (space separated list, from highest to lower priority).
# RTIRQ_HIGH_LIST="softirq-timer"
************************** /etc/init.d/limits.conf
****************************
@audio - rtprio 99
@audio - nice -15
@audio - memlock 512000
****************************** cat /proc/interrupts
*********************************
CPU0 CPU1
0: 16448905 0 IO-APIC-edge timer
1: 1922 0 IO-APIC-edge i8042
8: 1 0 IO-APIC-edge rtc
9: 1 0 IO-APIC-fasteoi acpi
12: 801 0 IO-APIC-edge i8042
14: 18261 0 IO-APIC-edge ide0
15: 74104 0 IO-APIC-edge ide1
16: 270629 0 IO-APIC-fasteoi nvidia
17: 4022 0 IO-APIC-fasteoi eth0
19: 1564191 0 IO-APIC-fasteoi ohci1394, ohci1394
20: 24 0 IO-APIC-fasteoi ehci_hcd:usb1, uhci_hcd:usb2
21: 113 0 IO-APIC-fasteoi uhci_hcd:usb3, HDA Intel
22: 12548 0 IO-APIC-fasteoi uhci_hcd:usb4
23: 0 0 IO-APIC-fasteoi uhci_hcd:usb5
NMI: 0 0 Non-maskable interrupts
LOC: 138113 8271422 Local timer interrupts
RES: 943079 1904284 Rescheduling interrupts
CAL: 86 54 function call interrupts
TLB: 890 700 TLB shootdowns
TRM: 0 0 Thermal event interrupts
THR: 0 0 Threshold APIC interrupts
SPU: 0 0 Spurious interrupts
ERR: 0
************************************* /etc/init.d/rtirq status
*******************************
* status: started
PID CLS RTPRIO NI PRI %CPU STAT COMMAND
352 FF 95 - 135 0.0 S< IRQ-8 rtc
426 FF 90 - 130 0.3 S< IRQ-19 ohci1394, ohci1394
491 FF 85 - 125 0.0 S< IRQ-1 i8042
490 FF 84 - 124 0.0 S< IRQ-12 i8042
5 FF 50 - 90 0.0 S< softirq-high/0
6 FF 50 - 90 0.7 S< softirq-timer/0
7 FF 50 - 90 0.0 S< softirq-net-tx/
8 FF 50 - 90 0.0 S< softirq-net-rx/
9 FF 50 - 90 0.0 S< softirq-block/0
10 FF 50 - 90 0.0 S< softirq-tasklet
11 FF 50 - 90 0.0 S< softirq-sched/0
12 FF 50 - 90 0.0 S< softirq-hrtimer
13 FF 50 - 90 0.0 S< softirq-rcu/0
17 FF 50 - 90 0.0 S< softirq-high/1
18 FF 50 - 90 0.4 S< softirq-timer/1
19 FF 50 - 90 0.0 S< softirq-net-tx/
20 FF 50 - 90 0.0 S< softirq-net-rx/
21 FF 50 - 90 0.0 S< softirq-block/1
22 FF 50 - 90 0.1 S< softirq-tasklet
23 FF 50 - 90 0.0 S< softirq-sched/1
24 FF 50 - 90 0.0 S< softirq-hrtimer
25 FF 50 - 90 0.0 S< softirq-rcu/1
99 FF 50 - 90 0.0 S< IRQ-9 acpi
395 FF 50 - 90 0.7 S< IRQ-14 ide0
396 FF 50 - 90 0.0 S< IRQ-15 ide1
446 FF 50 - 90 0.0 S< IRQ-20 ehci_hcd:usb1, uhci_hcd:usb2
461 FF 50 - 90 0.0 S< IRQ-21 uhci_hcd:usb3, HDA Intel
468 FF 50 - 90 0.0 S< IRQ-22 uhci_hcd:usb4
479 FF 50 - 90 0.0 S< IRQ-23 uhci_hcd:usb5
3452 FF 50 - 90 0.0 S< IRQ-17 eth0
3685 FF 50 - 90 0.1 S< IRQ-16 nvidia
Thank you again for your help.
greets,
Mysth-R
--
*
***************************************************************************************
* {^_^} Mysth-R {^_^}
* <= Aide Auditive =>
*
* http://myspace.com/mysthr
* http://myspace.com/aideauditive
* http://mysthr.free.fr/Joomla => Site dédié à l'audio sous
Fedora/PlanetCCRMA.
*
***************************************************************************************
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.linuxaudio.org/pipermail/linux-audio-user/attachments/20080408/dd0c45fc/attachment.htm
More information about the Linux-audio-user
mailing list