On re-reading your message I see you are concerned about control events and signals, not audio. But the same logic applies in either case. Whenever the host is reading audio out of spout, it can be reading control values from Csound. Just before the host releases Csound's monitor or calls csoundPerformKsmps, it can write control values.

Regards,
Mike

-----Original Message-----
From: Michael Gogins 
Sent: Aug 20, 2005 1:40 PM
To: csound-devel@lists.sourceforge.net
Subject: Re: [Cs-dev] Problems with csoundTableGet()

First of all do you really need different threads? It may simpler for the host to call csoundCompile, then call csoundPerformKsmps and read the audio out of the spout buffer each time. In this mode, there is only one thread, the host thread, and the host drives the Csound performance. If the host buffer and the Csound buffer are different sizes, you can use 2 sets of buffer indexes and only call csoundPerformKsmps whenever spout has been consumed. This is how CsoundVST works (see CsoundVST::process()).

If you do need threads, then let Csound run in 1 thread and the host run in 1 thread. Two monitors (or mutexes) can be used to synchronize on the audio buffer. The host waits on the host monitor. Csound writes spout, releases the host monitor, and waits on the Csound monitor. The host proceeds, does whatever it is doing to consume spout, and then releases the Csound monitor and waits on the host monitor again. This causes the 2 threads to take turns producing and consuming spout.

If the host buffer and the Csound buffer are different sizes, again you can use 2 sets of indexes, one set for the host and one set for Csound. or you can copy spout into a queue and have the host copy audio out of the queue. In either case Csound will not release the host monitor until it has enqueued enough audio for the host's buffer.

The first method is simpler to write but the second method is practically as efficient since on contemporary operating systems switching threads, locking and unlocking monitors, etc., are very efficient.

Regards,
Mike

-----Original Message-----
From: Iain Duncan 
Sent: Aug 20, 2005 12:54 PM
To: csound-devel@lists.sourceforge.net
Subject: Re: [Cs-dev] Problems with csoundTableGet()

Istvan, ( or anyone else ), would it require less in the way of 
protection to get results out of csound using the inchannel and 
outchannel callback routines? Or will I still be in the same boat as far 
as getting result values from csound in other threads?

In general, what would be the recommended way of getting a given number 
of values in and out on every kpass given a multi-threaded app?

Thanks
iain

Istvan Varga wrote:
> Iain Duncan wrote:
> 
>> I've managed to get some simple threading working with the api, but 
>> can't get csoundTableGet() to work. The app compiles but csound exits 
>> as  soon as I try to use csoundTabelGet()
>>
>> - the pointer to csound is global
>> - i try calling it from the main thread after spawning a csound 
>> thread, dies
>> - i try calling it from the yield call back routine, dies also
>>
>> If anyone can tell me what is wrong here that would be great.
> 
> 
> Beware that the yield callback may be called at a time when the table
> does not exist. Before accessing the table, use csoundTableLength to
> find out if the table exists (has length >= 1).
> Another (not related) issue is that accessing the same instance of
> Csound from multiple threads is unsafe, and you may get occasional
> crashes unless using locks around calls of Csound API functions.
> 
> 
> -------------------------------------------------------
> SF.Net email is Sponsored by the Better Software Conference & EXPO
> September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
> Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
> Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel
> 


-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/csound-devel





-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/csound-devel





-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

Michael Gogins wrote:
> On re-reading your message I see you are concerned about control events and signals, not audio. But the same logic applies in either case. Whenever the host is reading audio out of spout, it can be reading control values from Csound. Just before the host releases Csound's monitor or calls csoundPerformKsmps, it can write control values.

Yes, for now it's control variables, but audio will probably be used later.

Iain

> 
> Regards,
> Mike
> 
> -----Original Message-----
> From: Michael Gogins 
> Sent: Aug 20, 2005 1:40 PM
> To: csound-devel@lists.sourceforge.net
> Subject: Re: [Cs-dev] Problems with csoundTableGet()
> 
> First of all do you really need different threads? It may simpler for the host to call csoundCompile, then call csoundPerformKsmps and read the audio out of the spout buffer each time. In this mode, there is only one thread, the host thread, and the host drives the Csound performance. If the host buffer and the Csound buffer are different sizes, you can use 2 sets of buffer indexes and only call csoundPerformKsmps whenever spout has been consumed. This is how CsoundVST works (see CsoundVST::process()).
> 
> If you do need threads, then let Csound run in 1 thread and the host run in 1 thread. Two monitors (or mutexes) can be used to synchronize on the audio buffer. The host waits on the host monitor. Csound writes spout, releases the host monitor, and waits on the Csound monitor. The host proceeds, does whatever it is doing to consume spout, and then releases the Csound monitor and waits on the host monitor again. This causes the 2 threads to take turns producing and consuming spout.
> 
> If the host buffer and the Csound buffer are different sizes, again you can use 2 sets of indexes, one set for the host and one set for Csound. or you can copy spout into a queue and have the host copy audio out of the queue. In either case Csound will not release the host monitor until it has enqueued enough audio for the host's buffer.
> 
> The first method is simpler to write but the second method is practically as efficient since on contemporary operating systems switching threads, locking and unlocking monitors, etc., are very efficient.
> 
> Regards,
> Mike
> 
> -----Original Message-----
> From: Iain Duncan 
> Sent: Aug 20, 2005 12:54 PM
> To: csound-devel@lists.sourceforge.net
> Subject: Re: [Cs-dev] Problems with csoundTableGet()
> 
> Istvan, ( or anyone else ), would it require less in the way of 
> protection to get results out of csound using the inchannel and 
> outchannel callback routines? Or will I still be in the same boat as far 
> as getting result values from csound in other threads?
> 
> In general, what would be the recommended way of getting a given number 
> of values in and out on every kpass given a multi-threaded app?
> 
> Thanks
> iain
> 
> Istvan Varga wrote:
> 
>>Iain Duncan wrote:
>>
>>
>>>I've managed to get some simple threading working with the api, but 
>>>can't get csoundTableGet() to work. The app compiles but csound exits 
>>>as  soon as I try to use csoundTabelGet()
>>>
>>>- the pointer to csound is global
>>>- i try calling it from the main thread after spawning a csound 
>>>thread, dies
>>>- i try calling it from the yield call back routine, dies also
>>>
>>>If anyone can tell me what is wrong here that would be great.
>>
>>
>>Beware that the yield callback may be called at a time when the table
>>does not exist. Before accessing the table, use csoundTableLength to
>>find out if the table exists (has length >= 1).
>>Another (not related) issue is that accessing the same instance of
>>Csound from multiple threads is unsafe, and you may get occasional
>>crashes unless using locks around calls of Csound API functions.
>>
>>
>>-------------------------------------------------------
>>SF.Net email is Sponsored by the Better Software Conference & EXPO
>>September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
>>Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
>>Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
>>_______________________________________________
>>Csound-devel mailing list
>>Csound-devel@lists.sourceforge.net
>>https://lists.sourceforge.net/lists/listinfo/csound-devel
>>
> 
> 
> 
> -------------------------------------------------------
> SF.Net email is Sponsored by the Better Software Conference & EXPO
> September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
> Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
> Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel
> 
> 
> 
> 
> 
> -------------------------------------------------------
> SF.Net email is Sponsored by the Better Software Conference & EXPO
> September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
> Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
> Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel
> 
> 
> 
> 
> 
> -------------------------------------------------------
> SF.Net email is Sponsored by the Better Software Conference & EXPO
> September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
> Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
> Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel
> 


-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net