Hi All,

Just a note I'm not keen on the instr_thread idea.  I had a chat with
Michael Gogins the other day and explained all the issues with threads
that currently exist and adding more possible issues is definitely not
good.  (BTW: There are mutex opcodes already in csound; I added them
but never documented as they are for the experimental "--num-threads="
implementation; can find more info on that in nabble I'm sure). Using
multiple threads already can not happen even in the naive
implementation I wrote with num-threads due to things like curevt in
the int CSOUND struct which goto's use to rewalk the opcode chain from
the beginning to find a label.  (since only one event can occupy the
curevt spot, you can see where the problem comes in when threading is
introduced).

steven


On 9/25/07, Greg Thompson <greg@rhythmicdesign.com> wrote:
> Hey guys -
>
> I'm working on the Csound Server for the xo and I'm trying to load audio
> files while Csound is running (allowing the user to choose a file to load
> and play it back).  This is okay if the file is small enough, but since I'm
> running all of my Csound instances in one thread, if one blocks I get a
> buffer under-run and so far ALSA is not forgiving me for this.  Naturally, I
> have a few options:
>
> 1 - I could run each instance of Csound in a separate thread
>  - but I will have to do a lot of buffer sync checking which will certainly
> add overhead ... how much .. I'm not sure ... If nothing else, it
> complicates the code (and it still would prevent the instance from making
> sound)
>
> 2 - I do have a separate thread for network events --
>  so when I want to load an audio file - I could have it skip processing
> (pause) in the Csound instance in my audio processing thread and load the
> audio file in the network thread (or spawn another thread to load the file
> so I don't block my network thread) - once its loaded, I could have it
> un-pause
>
>
> - OR -
>
>
> Someone could be kind enough to devise a means of having GEN routines
> processing in a low-priority thread.  It would be even cooler if once it
> loaded, it could send a signal back to the caller when it finished.  Or
> maybe someone could take it one step further and allow an entire instrument
> to be run on a separate thread.
>
> ideally something like:
>
> instr_thread   instrument_number, priority
>  do instr stuff
> endin
>
> Worry about synchronization later ... it would be assumed that whatever
> happens in the instrument doesn't care about synchronizing with the rest
> anyway .. OR you add mutex opcodes or something similar   ;^}
>
>
> - OR -
>
> Maybe there is another way that I haven't thought of ...
>
>
>
> To see how I'm currently loading the audio file.
>
>
> instr 110 ; load instrument
>
> kCounter init 0
>
>
>     Sfname      strget p4
>
>     Spathback       sprintf "%d/len", p5
>     Spathbackchan sprintf "%d/channels", p5
>     Spathbacksr     sprintf "%d/sr", p5
>
>
>     ichannels filenchnls Sfname
>     isr       filesr    Sfname
>
>
>     iftno ftgen p5, 0, 0, 1, Sfname, 0, 0, 1
>
> if kCounter >= 0 kgoto done
>             outvalue Spathback, ftlen(iftno)
>             outvalue Spathbackchan, ichannels
>             outvalue Spathbacksr, isr
> done:
>
>
> endin
>
>
>
>
>
>     def loadedCallback(self, message):
>         if message.currentPath() == '/len':
>             self._tableLength = message.argument(0)
>         elif message.currentPath() == '/channels':
>             self._channels = message.argument(0)
>         elif message.currentPath() == '/sr':
>             self._sampleRate = message.argument(0)
>
>
>         if self._tableLength > 0 and self._channels > 0 and self._sampleRate
> > 0:
>             self.isLoaded = True
>
>
>     def load(self):
>         """
>         Load the audio file as an f-table
>         The instrument will notify us when the table has loaded by calling
>         self.loadedCallback
>         """
>         self.loadCalled = True
>         self.csound.registerChannel(str(self._fTableIndex),
> self.loadedCallback)
>
>
>         fEvent = 'i110 0 1 "'+self._filename+'" '+str(self._fTableIndex)
>
>         self.csound.playEventAsString(fEvent)
>
>
> greg
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2005.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel
>
>

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net