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