[LAU] dualcore and audio software

Dan S danstowell+lxau at gmail.com
Fri May 1 14:52:51 EDT 2009


Maybe your softwares support load-sharing over multiple processors (a
good thing, no?) and therefore all the work is being neatly divided
between the processors. Any reason that should be bad?

Dan

2009/5/1, Atte André Jensen <atte.jensen at gmail.com>:
> Arnold Krille wrote:
>
>  > I don't understand your question?
>
>
> Ok.
>
>
>  > chuck and ams are independant applications, there is no reason why they
>  > shouldn't run in parallel on different cores.
>
>
> We agree on that.
>
>
>  > Both use threads to split their work, again there is no reason they have all
>  > their threads running on the same core. In fact one of the reasons to use
>  > threads is to make use of multiple cores within one app.
>
>
> But doubling the load (for instance by adding more voices to ams) makes
>  *both* threads rise by (about) 100%. Wouldn't you expect for instance
>  gui threads to stay the same. Other cpu heavy processes seem to use only
>  one core, for instance building stuff from source. Also...
>
>
>  > With standard jack it *should* be that all jack-related threads run on one
>  > core, in your case leaving the second core for gui- and disk-threads. jackdmp
>  > makes use of multiple cores as far as I know.
>
>
> ...chuck is non gui and the code I'm running in chuck (my own) doesn't
>  use disk i/o. Starting ams with -n (nogui) it still takes up two
>  threads. It looks like this in htop:
>
>  http://atte.dk/download/ams_nogui.png
>
>  So one thread with prio 20 and one with -76 chewing away at the same 27%.
>
>  It might be totally normal and totally unavoidable, but I'm just curious
>  and doubtful :-)
>
>
>  --
>  Atte
>
>  http://atte.dk    http://modlys.dk
>  _______________________________________________
>  Linux-audio-user mailing list
>  Linux-audio-user at lists.linuxaudio.org
>  http://lists.linuxaudio.org/mailman/listinfo/linux-audio-user
>


-- 
http://www.mcld.co.uk



More information about the Linux-audio-user mailing list