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
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.