I'm working in a DSP project with four channels doing processing in real time
on a dual core ARM board running Linux in RT.

The processing in each channel will be: phaser, delay, compress, noise gate,
equalizer(4band) and a hipass filter.

I'm planing to develop the software by using C++ csound's API with the
following features:
-> Live interaction: OSC messages
-> Mixing: Software bus
-> Channel Design: A .orc of instruments(Each one in mono mode)
-> Threads: One thread per channel, one thread for mixing outputs, and a
last one for live interaction

The question is whether this design above is a good choice. I could build an
entire .orc containig all channels doing mixing in a single thread for
example.

I'd appreciate advices

Thanks.




--
View this message in context: http://csound.1045644.n5.nabble.com/Design-for-a-multi-channel-Embedded-DSP-project-tp5720738.html
Sent from the Csound - General mailing list archive at Nabble.com.

Where are the OSC messages coming from?

On 4 March 2013 23:43, imaia  wrote:
> I'm working in a DSP project with four channels doing processing in real time
> on a dual core ARM board running Linux in RT.
>
> The processing in each channel will be: phaser, delay, compress, noise gate,
> equalizer(4band) and a hipass filter.
>
> I'm planing to develop the software by using C++ csound's API with the
> following features:
> -> Live interaction: OSC messages
> -> Mixing: Software bus
> -> Channel Design: A .orc of instruments(Each one in mono mode)
> -> Threads: One thread per channel, one thread for mixing outputs, and a
> last one for live interaction
>
> The question is whether this design above is a good choice. I could build an
> entire .orc containig all channels doing mixing in a single thread for
> example.
>
> I'd appreciate advices
>
> Thanks.
>
>
>
>
> --
> View this message in context: http://csound.1045644.n5.nabble.com/Design-for-a-multi-channel-Embedded-DSP-project-tp5720738.html
> Sent from the Csound - General mailing list archive at Nabble.com.
>
>
> Send bugs reports to the Sourceforge bug tracker
>             https://sourceforge.net/tracker/?group_id=81968&atid=564599
> Discussions of bugs and features can be posted here
> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"
>

I'll receive OSC messages from a local network; A client will generate OSC
commands from the other side.



--
View this message in context: http://csound.1045644.n5.nabble.com/Design-for-a-multi-channel-Embedded-DSP-project-tp5720738p5720740.html
Sent from the Csound - General mailing list archive at Nabble.com.

I would tend to try to write a single orchestra that looked after
everything. I would use the software bus within the instrument for
mixing and things like that. OSC messages can be used to route audio
within the csd file.



On 4 March 2013 23:49, imaia  wrote:
> I'll receive OSC messages from a local network; A client will generate OSC
> commands from the other side.
>
>
>
> --
> View this message in context: http://csound.1045644.n5.nabble.com/Design-for-a-multi-channel-Embedded-DSP-project-tp5720738p5720740.html
> Sent from the Csound - General mailing list archive at Nabble.com.
>
>
> Send bugs reports to the Sourceforge bug tracker
>             https://sourceforge.net/tracker/?group_id=81968&atid=564599
> Discussions of bugs and features can be posted here
> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"
>

I worry about the CPU workload running everything from a single orchestra
file. I thought distribute the work amongst CPUs. Can I do that using a
single orcherstra file? I mean: A single orcherstra file modeling four
channels using a thread for each channel? It would be simpler this way
because I could use mixing opcodes in a simple manner.

Thanks.



--
View this message in context: http://csound.1045644.n5.nabble.com/Design-for-a-multi-channel-Embedded-DSP-project-tp5720738p5720755.html
Sent from the Csound - General mailing list archive at Nabble.com.

I guess it's a case of trying it out and seeing. I've never tried
running things on different threads so I can't say. Maybe others have
more experience..

It's a great news about csound 6.

Looking at 'Top/threads.c' in cs5,  I can see that everything is done with
mutexes and condition variables.  I don't know if I'm looking at the right
file, but the problem with mutexes is the context switch overhead, it wastes
a lot of time to switch threads in this way.

I've been working with  multi-thread implementations. In fine grained
processing like synthesis I think spinlocks are better and faster for thread
synchronization.  

Another good feature in cs6 could be "CPU affinity". In this way users could
associate instruments to certain CPU set. It improves locality and cache
utilisation leading better performance. 
System tasks like interrupts and syscalls(printf) could use a specific CPU. 
These features would be great in embedded environments.

I'm tuning my implementation in this way, but it's a lot of work. 
I'm planning to write an article at the end to report my experience.

Thanks.



--
View this message in context: http://csound.1045644.n5.nabble.com/Design-for-a-multi-channel-Embedded-DSP-project-tp5720738p5720760.html
Sent from the Csound - General mailing list archive at Nabble.com.

The Csound 6 multicore implementation delivers substantial gains, and the way it has been designed, context-switching is not problematic. You
can check the code in csound6 GIT. The multicore code is in Top/csound.c. 

Victor
On 5 Mar 2013, at 19:18, imaia wrote:

> It's a great news about csound 6.
> 
> Looking at 'Top/threads.c' in cs5,  I can see that everything is done with
> mutexes and condition variables.  I don't know if I'm looking at the right
> file, but the problem with mutexes is the context switch overhead, it wastes
> a lot of time to switch threads in this way.
> 
> I've been working with  multi-thread implementations. In fine grained
> processing like synthesis I think spinlocks are better and faster for thread
> synchronization.  
> 
> Another good feature in cs6 could be "CPU affinity". In this way users could
> associate instruments to certain CPU set. It improves locality and cache
> utilisation leading better performance. 
> System tasks like interrupts and syscalls(printf) could use a specific CPU. 
> These features would be great in embedded environments.
> 
> I'm tuning my implementation in this way, but it's a lot of work. 
> I'm planning to write an article at the end to report my experience.
> 
> Thanks.
> 
> 
> 
> --
> View this message in context: http://csound.1045644.n5.nabble.com/Design-for-a-multi-channel-Embedded-DSP-project-tp5720738p5720760.html
> Sent from the Csound - General mailing list archive at Nabble.com.
> 
> 
> Send bugs reports to the Sourceforge bug tracker
>            https://sourceforge.net/tracker/?group_id=81968&atid=564599
> Discussions of bugs and features can be posted here
> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"
> 

Dr Victor Lazzarini
Senior Lecturer
Dept. of Music
NUI Maynooth Ireland
tel.: +353 1 708 3545
Victor dot Lazzarini AT nuim dot ie

Yes I have. Inside maxmsp. I use one instance of Csound per channel,
distributed amongst CPUs and it makes a big difference.

P

On 5 March 2013 17:41, Rory Walsh  wrote:
> I guess it's a case of trying it out and seeing. I've never tried
> running things on different threads so I can't say. Maybe others have
> more experience..
>
>
> Send bugs reports to the Sourceforge bug tracker
>             https://sourceforge.net/tracker/?group_id=81968&atid=564599
> Discussions of bugs and features can be posted here
> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"
>

Hello Victor.
I didn't find the address of csound 6 git repo.
This version is already usable? 

Thanks.



--
View this message in context: http://csound.1045644.n5.nabble.com/Design-for-a-multi-channel-Embedded-DSP-project-tp5720738p5720769.html
Sent from the Csound - General mailing list archive at Nabble.com.

git clone git://git.code.sf.net/p/csound/csound6-git csound-csound6-git

We're at alpha stage.
On 5 Mar 2013, at 20:25, imaia wrote:

> Hello Victor.
> I didn't find the address of csound 6 git repo.
> This version is already usable? 
> 
> Thanks.
> 
> 
> 
> --
> View this message in context: http://csound.1045644.n5.nabble.com/Design-for-a-multi-channel-Embedded-DSP-project-tp5720738p5720769.html
> Sent from the Csound - General mailing list archive at Nabble.com.
> 
> 
> Send bugs reports to the Sourceforge bug tracker
>            https://sourceforge.net/tracker/?group_id=81968&atid=564599
> Discussions of bugs and features can be posted here
> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"
> 

Dr Victor Lazzarini
Senior Lecturer
Dept. of Music
NUI Maynooth Ireland
tel.: +353 1 708 3545
Victor dot Lazzarini AT nuim dot ie

If you look at Engine/cs_new_dispatch.c you will see that the design is
not to use mutex as they cause delay.  We use atomic swap and similar. 
Read the code?  Or I could send you the draft technical note.

Affinity would be good when available generally.

==John

> It's a great news about csound 6.
>
> Looking at 'Top/threads.c' in cs5,  I can see that everything is done with
> mutexes and condition variables.  I don't know if I'm looking at the right
> file, but the problem with mutexes is the context switch overhead, it
> wastes
> a lot of time to switch threads in this way.
>
> I've been working with  multi-thread implementations. In fine grained
> processing like synthesis I think spinlocks are better and faster for
> thread
> synchronization.
>
> Another good feature in cs6 could be "CPU affinity". In this way users
> could
> associate instruments to certain CPU set. It improves locality and cache
> utilisation leading better performance.
> System tasks like interrupts and syscalls(printf) could use a specific
> CPU.
> These features would be great in embedded environments.
>
> I'm tuning my implementation in this way, but it's a lot of work.
> I'm planning to write an article at the end to report my experience.
>
> Thanks.
>
>
>
> --
> View this message in context:
> http://csound.1045644.n5.nabble.com/Design-for-a-multi-channel-Embedded-DSP-project-tp5720738p5720760.html
> Sent from the Csound - General mailing list archive at Nabble.com.
>
>
> Send bugs reports to the Sourceforge bug tracker
>             https://sourceforge.net/tracker/?group_id=81968&atid=564599
> Discussions of bugs and features can be posted here
> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
> csound"
>
>
>
>

I analysed the code(cs_new_dispatch.c) a bit. I can see atomic functions 
__sync_fetch... and spinlocks
but I didn't understand the logic and the state machine you are implementing
on the dispatch.  I would like to see the draft, thanks
In some functions like moveWatch I can see clearly what you are doing but
I'm lost in understanding the global logic.

CPU affinity is quite simple with "sched_setaffinity" function on linux:
http://www.ibm.com/developerworks/library/l-affinity/index.html



--
View this message in context: http://csound.1045644.n5.nabble.com/Design-for-a-multi-channel-Embedded-DSP-project-tp5720738p5720837.html
Sent from the Csound - General mailing list archive at Nabble.com.

Hi,

Are the atomic operations supported in llvm? I think Apple is moving
in that direction. I think there are atomic operations as part of C11
but I'm not sure we want to go there yet...

Cheers,
Andrés

On Thu, Mar 7, 2013 at 9:27 AM, Victor Lazzarini
 wrote:
> yes, but Csound is not only for Linux. On OSX10.6 for instance, affinity is
> not implemented afaik (beyond 'hints').
>
> On 7 Mar 2013, at 17:14, imaia wrote:
>
> CPU affinity is quite simple with "sched_setaffinity" function on linux:
> http://www.ibm.com/developerworks/library/l-affinity/index.html
>
>
> Dr Victor Lazzarini
> Senior Lecturer
> Dept. of Music
> NUI Maynooth Ireland
> tel.: +353 1 708 3545
> Victor dot Lazzarini AT nuim dot ie
>
>
>