Re: [LAU] : jack CPU % is going crazy !

From: Mysth-R <mysthr21@email-addr-hidden>
Date: Tue Apr 08 2008 - 15:27:07 EEST

2008/4/7, Pieter Palmers <pieterp@email-addr-hidden>:
>
> Mysth-R wrote:
>
> >
> >
> > 2008/4/7, Pieter Palmers <pieterp@email-addr-hidden <mailto:pieterp@email-addr-hidden>>:
> >
> > Mysth-R wrote:
> >
> >
> >
> > 2008/4/7, Pieter Palmers <pieterp@email-addr-hidden
> > <mailto:pieterp@email-addr-hidden> <mailto:pieterp@email-addr-hidden
> > <mailto:pieterp@email-addr-hidden>>>:
> >
> >
> > 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.
*
***************************************************************************************

_______________________________________________
Linux-audio-user mailing list
Linux-audio-user@email-addr-hidden
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-user
Received on Tue Apr 8 16:15:04 2008

This archive was generated by hypermail 2.1.8 : Tue Apr 08 2008 - 16:15:05 EEST