ok, I tested now again with shark, and the jack version really uses less cpu (thnks derek). also, shark adds both cpus, so when I measure 20% on one cpu, then shark only sees 10%. (don't know why I got more than 30% before, now it was back to "normal" (~20%)) according to shark with portaudio pd uses 9.8% and with jack pd uses 0.8% and jackdmp 4.4%. long live jack! ignore the shark output that I posted before, I think it was only the pd process alone and the percentage was related only to the pd process. marius.
Thomas Grill wrote:
here's the first 20 processes, is there anything that should worry me?
I don't think so... you could compare this to Max/MSP or other audio applications. In my experience using jack imposes additional load, since it will be just another layer between the application and coreaudio. gr~~~
14.7% 14.7% mach_kernel ml_set_interrupts_enabled 12.3% 12.3% AudioToolbox Resampler2::ConvertAltivec_SmallIntegerRatio(float*, float*, unsigned long, int) 6.1% 6.1% com.apple.driver.AppleHDA SInt16ToFloat32 5.0% 5.0% com.apple.driver.DspFuncLib DspFuncOrgEQ::_EQBoth(float*, float*, unsigned long, unsigned long) 3.5% 3.5% mach_kernel lo_mach_scall 1.9% 1.9% com.apple.driver.DspFuncLib DspFuncVolume::process(unsigned long, unsigned long) 1.4% 1.4% mach_kernel mutex_lock 1.2% 1.2% CoreAudio IOA_Time::GetCurrentTime(AudioTimeStamp&) const 1.2% 1.2% mach_kernel lo_alltraps 1.1% 1.1% IOKit iokit_user_client_trap 1.1% 1.1% commpage [libSystem.B.dylib] __spin_lock 1.1% 1.1% CoreAudio AUGenericOutputEntry 1.0% 1.0% libSystem.B.dylib semaphore_timedwait_signal_trap 0.9% 0.9% libSystem.B.dylib semaphore_wait_trap 0.9% 0.9% libSystem.B.dylib _pthread_cond_wait 0.9% 0.9% commpage [libSystem.B.dylib] __nanotime 0.9% 0.9% mach_kernel mutex_unlock 0.8% 0.8% commpage [libSystem.B.dylib] __memcpy 0.7% 0.7% mach_kernel lck_mtx_lock 0.7% 0.7% AudioToolbox Resampler2::PushConvert(float*, float*, float*, float*, unsigned long&, unsigned long&, unsigned long, unsigned long)