Re: x86_64 problem - solved
"Jack O'Quin" <[email protected]>
| Newsgroups | gmane.comp.audio.jamin.devel |
|---|---|
| Message-ID | <[email protected]> |
On 6/11/06, John Rigg <[email protected]> wrote: > On Sun, Jun 11, 2006 at 09:00:26PM +0100, John Rigg wrote: > > Something else I notice is that with pcm_multi the CPU load is about > > 24% when jamin is idling (and doesn't change much when processing > > audio). > > Just using hw:0 reduces CPU load to 2.5% when idling. > > It turns out that indicated CPU load is related to period size, > not number of channels. At -p32 it's around 2.5%, at -p64 it's 2.2% and > at -p128 it fluctuates between 23% and 60%, then settles down to around > 22% for bigger period sizes. This is regardless of whether I use one > card or three. > Of course those small periods wouldn't be any good for processing audio > due to xruns. This is an artifact of the way jamin handles smaller period sizes. When the JACK period is smaller than jamin's natural FFT window (256 frames), we run the FFT in a helper thread. The time taken does not go away, but it no longer shows up on the JACK CPU load, because it is done outside the JACK process thread. This is done to make it work, otherwise the CPU load would be too high to tolerate on most machines. There is typically no reason to run low-latency period sizes during mastering, and running jamin with a period size below -p256 is not recommended. The other problem you reported is almost surely an ALSA driver issue with multicard support. Jamin has nothing to do with that layer of operation. -- joq