If the host thread is running Csound in the same thread, that thread needs to do no locking. However, if that thread is sharing data with some other threads, then you will probably need to synchronize access to that data between the threads.

Regards,
Mike

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

Cool, I was kind of thinking of that, so maybe I'll try that out. 
Correct me if I'm wrong, I would:

- put csound in one thread
- make all in/out api calls in the same thread between calls to 
csoundPerformKsmps, in the same loop
- pass off any work or displaying that needs to be done using those 
control/result variables to other threads, using queues when necessary

If I do the above, do I still need to use the csound thread locking 
functions to do control i/o to csound? I will try my understanding of 
the above, and post when done.

Thanks again for all the input guys.
Iain


Michael Gogins wrote:
> You could have a single thread combining the host and Csound, with the host driving csoundPerformKsmps. Then, whenever the host needs to do something 'big' like load a WAV file, it could hand off that task to another thread (a lower priority worker thread) and not wait around for the task to complete, placing a description of the task in queue ("I'm not finished reading file X yet". When the task finishes, it updates the queue with its status ("I've finished reading file X").  Then, in its main loop (with Csound all), it can check a queue of finished tasks ("Is file X read yet - yes") and do what is appropriate in the Csound performance. This is a common design in real-time-type systems.
> 
> Regards,
> Mike
> 
> -----Original Message-----
> From: Iain Duncan 
> Sent: Aug 20, 2005 4:07 PM
> To: csound-devel@lists.sourceforge.net
> Subject: Re: [Cs-dev] Problems with csoundTableGet()
> 
> Thanks Michael. I believe I need threads, but I'm not 100% sure. I would 
> like to get the architecture to the point where we can do anything we 
> want with the host app and not hiccup csound, just have the host wait a 
> bit. I'd say we are on the right track if it were possible to select a 
> wave file from the OS, and dynamically drop it into a csound table on 
> the fly, as well as do the reverse. I realize this will be tricky 
> though, and I assumed it require spawning lower priority threads to do 
> the disk i/o.
> 
> Seems like there are a lot of options now, many of which are beyond me 
> yet. I'll continue posting my examples for comment if people have time. 
> Perhaps they can be useful eventually for a tutorial series on using the 
> api.
> 
> Thanks
> Iain
> 
> Michael Gogins wrote:
> 
>>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
> 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

Ok, If I understand you correctly, I should not have to do any locking 
if the csoundTableGet call is as follows:

> int csound_thread_routine(void *user_data)
> {
> 	// starting csound
> 	const char *argv[] = {"csound", "-+rtaudio=alsa", "-odac", "cs_simple.csd" };
> 	csoundCompile(csound, 4, (char **)argv);
> 	
> 	// cs_performing is set by Csound, and go is set by the user
> 	cs_performing = true;
> 	int index = 0;
> 	while( cs_performing ) 
> 	{
> 	    // Csound will call cb_thread_yield.
> 	    cs_performing = !csoundPerformKsmps(csound);
> 	
> 		// let's try putting the api calls here.
> 		table_value = csoundTableGet( csound, 2, 0 );
> 
> 		//result = float(table_value);
> 	}    
> 	// we are done, so clean up
> 	csoundCleanup(csound);

But this produces a segfault, which does not happen if I comment out the 
csoundTableGet() call. ( No other routines try to use table_value in 
this example.)  So I guess I'm at a loss as to how to use the table get 
function at all without locking. Am I missing something? Attached is the 
  whole file.

Thanks
Iain




Michael Gogins wrote:
> If the host thread is running Csound in the same thread, that thread needs to do no locking. However, if that thread is sharing data with some other threads, then you will probably need to synchronize access to that data between the threads.
> 
> Regards,
> Mike
> 
> -----Original Message-----
> From: Iain Duncan 
> Sent: Aug 20, 2005 7:39 PM
> To: csound-devel@lists.sourceforge.net
> Subject: Re: [Cs-dev] Problems with csoundTableGet()
> 
> Cool, I was kind of thinking of that, so maybe I'll try that out. 
> Correct me if I'm wrong, I would:
> 
> - put csound in one thread
> - make all in/out api calls in the same thread between calls to 
> csoundPerformKsmps, in the same loop
> - pass off any work or displaying that needs to be done using those 
> control/result variables to other threads, using queues when necessary
> 
> If I do the above, do I still need to use the csound thread locking 
> functions to do control i/o to csound? I will try my understanding of 
> the above, and post when done.
> 
> Thanks again for all the input guys.
> Iain
> 
> 
> Michael Gogins wrote:
> 
>>You could have a single thread combining the host and Csound, with the host driving csoundPerformKsmps. Then, whenever the host needs to do something 'big' like load a WAV file, it could hand off that task to another thread (a lower priority worker thread) and not wait around for the task to complete, placing a description of the task in queue ("I'm not finished reading file X yet". When the task finishes, it updates the queue with its status ("I've finished reading file X").  Then, in its main loop (with Csound all), it can check a queue of finished tasks ("Is file X read yet - yes") and do what is appropriate in the Csound performance. This is a common design in real-time-type systems.
>>
>>Regards,
>>Mike
>>
>>-----Original Message-----
>>From: Iain Duncan 
>>Sent: Aug 20, 2005 4:07 PM
>>To: csound-devel@lists.sourceforge.net
>>Subject: Re: [Cs-dev] Problems with csoundTableGet()
>>
>>Thanks Michael. I believe I need threads, but I'm not 100% sure. I would 
>>like to get the architecture to the point where we can do anything we 
>>want with the host app and not hiccup csound, just have the host wait a 
>>bit. I'd say we are on the right track if it were possible to select a 
>>wave file from the OS, and dynamically drop it into a csound table on 
>>the fly, as well as do the reverse. I realize this will be tricky 
>>though, and I assumed it require spawning lower priority threads to do 
>>the disk i/o.
>>
>>Seems like there are a lot of options now, many of which are beyond me 
>>yet. I'll continue posting my examples for comment if people have time. 
>>Perhaps they can be useful eventually for a tutorial series on using the 
>>api.
>>
>>Thanks
>>Iain
>>
>>Michael Gogins wrote:
>>
>>
>>>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
>>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
> 

Iain Duncan wrote:

> But this produces a segfault, which does not happen if I comment out the 
> csoundTableGet() call. ( No other routines try to use table_value in 
> this example.)  So I guess I'm at a loss as to how to use the table get 
> function at all without locking. Am I missing something? Attached is the 
> whole file.

Do not forget that the table may possibly not exist when you try to access
it. Use csoundTableLength() to find out if the table number is valid and
what is the maximum allowed table index.


-------------------------------------------------------
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

>> But this produces a segfault, which does not happen if I comment out 
>> the csoundTableGet() call. ( No other routines try to use table_value 
>> in this example.)  So I guess I'm at a loss as to how to use the table 
>> get function at all without locking. Am I missing something? Attached 
>> is the whole file.

> Do not forget that the table may possibly not exist when you try to access
> it. Use csoundTableLength() to find out if the table number is valid and
> what is the maximum allowed table index.

Aack, I'm an idiot, that was it. I got mixed up and forgot you'd already 
mentioned that. So now it works with the call in the same loop as
csoundPerformKsmps().

If I want to use the resulting values taken out of the tables in another 
thread, and the other thread is just going to read the values, do I 
still have to protect the variables with mutex's? Perhaps put all the 
output variables in a structure that is protected? I guess if I know 
ahead of time what I will be getting in and out I can have one data 
object for all output, and then on every kpass, lock it, fill it up, 
unlock. And then do the same in the other threads.

Thanks so much for answering all my pestering guys. =)

Iain


-------------------------------------------------------
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