interesting, bela uses this approach!
http://bela.io/#about
so it should not be that hard to adapt it for desktops and laptops
On 09/07/2016 08:01 PM, Giulio Moro wrote:
I believe the solution to these things lies in using Xenomai or other
RT extensions for Linux. With Xenomai you take control of the
scheduler and you can have one process taking up an entire CPU, while
the Linux kernel waits ( or uses other CPUs).
Giulio
------------------------------------------------------------------------
*From:* Jonathan Wilkes via Pd-list <[email protected]>
*To:* Simon Iten <[email protected]>; Pd-List
<[email protected]>
*Sent:* Wednesday, 7 September 2016, 18:50
*Subject:* Re: [PD] disable cores on linux to use as dedicated dsp
> On Wednesday, September 7, 2016 12:51 PM, Simon Iten
<[email protected] <mailto:[email protected]>> wrote:
> hi list,
> i recorded 3 times in a studio last year that uses a daw/pc
> interconnection by pyramix, basically it is a hacked windows
system,
> where one or two cores of a multicore cpu are completely hidden
from the
> system. these cores are then acessed directly by the daw and
used as a
> very powerful dsp. the system is incredible! lowest latencies, high
> trackcount, and the breakout to the adc/dac is a simple network
cable.
> see here for additional info:
> http://www.merging.ch/products/pyramix/masscore
> i since wondered if this would be a way to go for puredata? at
least on
> linux it seems very easy to deactivate a core (but i don't know
if it
> than can be used directly by a process) : echo 0 >
> /sys/devices/system/cpu/cpu1/online for core2 for example.
> is this a completely stupid idea? note that i have no idea how
hard it
> would be to implement something like this
> thanks for any insight
Hi Simon,
That quite an intriguing design.
It hurts my brain too much to try to assess the difficulty of such
an undertaking to
refactor Pure Data to this design.
So let me try a shortcut:
Inside d_ugen.c (which is essentially just dsp algos, so there
should be few if any
system calls) I see a t_getbytes call. t_getbytes calls calloc.
With the design you linked to, do Pd devs have to reimplement
malloc? If the answer
is yes, then I'd call this a massively difficult undertaking. If
d_* relies on the
system calls, then you can bet x_*, m_*, s_*, and g_* do, too, and
to a much greater
extent.
If the answer is no, I'd like to learn more about the design.
-Jonathan
_______________________________________________
[email protected] <mailto:[email protected]> mailing list
UNSUBSCRIBE and account-management ->
https://lists.puredata.info/listinfo/pd-list
_______________________________________________
[email protected] <mailto:[email protected]> mailing list
UNSUBSCRIBE and account-management ->
https://lists.puredata.info/listinfo/pd-list
_______________________________________________
[email protected] mailing list
UNSUBSCRIBE and account-management ->
https://lists.puredata.info/listinfo/pd-list
