So, here's my feedback, my apologies if these facilities already exist, 
please say how. My intent is to be able to write a host that will 
absolutely not break up audio even under overloaded conditions of 
input/diskio/visual feedback. So far things are looking good, two issues 
for me:

a) I need a way to schedule events from both the api or within csound 
into the future that are reliably in sync with the score, regardless of 
tempo changes from either beat mode or score tempo changes. I guess 
"event" doesn't do this. Does something else? If not, can we do that 
somewhow? This is, IMHO, critical for getting high performance real time 
environments working in tandem with scores.

b) How can we get csound engine to somehow pre-empt the rest of the host 
when it is time to calculate more audio? ( same issue I wrote about 
recently ). If the csound performing loop uses csoundPerformKmsps() and 
then does other stuff, how can we reliably control how much other stuff 
can be done without missing a csound deadline? assuming a potentially 
limitless queue of other stuff. I figure a worst case scenario would be 
something like ( assuming real time playing as we do this )

- host has allowed user to select and load a large audio sample file 
from disk
- this file is being copied into a csound table for use on the fly, it 
is loaded and selected in a seperate lower priority thread, and then all 
audio samples are put on to a queue for the interface to load into 
csound table via csoundTableSet()
- the interface takes messages off the queue that consist of a direction 
to load one sample in to one place in a table, and then keeps doing that 
until csoundPerformKsmps() needs to run again

So, some thoughts by me:

- could we somehow somehow generate an interrupt when it's time to 
render audio? then the host uses the interrupt vector to render another 
ksmps? I've only done this with microcontrollers so I could be out to 
lunch on that idea

- could csound signal that it wants the cpu back somehow? somesort of 
function that allows the loop dealing with messages to check before each 
message whether csound is actively waiting for cpu again?

- how does csoundsetyieldcallback work? could it be used to signal that 
csound does NOT need the cpu right now? could the interface code try to 
grab a mutex before each message pass, the mutex being locked by csound 
before performing, and unlocked repeatedly by a yeild callback? so if 
the mutex is free, we know there are still cycles left to deal with 
messages?

- any other ideas for how to deal with the above?

If I could deal with the above elegantly, I think I'd say the api is 
good to go for me at least.

Thanks
Iain


-------------------------------------------------------
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads, discussions,
and more. http://solutions.newsforge.com/ibmarch.tmpl
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

On Oct 13, 2005, at 6:21 PM, Iain Duncan wrote:

> So, here's my feedback, my apologies if these facilities already  
> exist, please say how. My intent is to be able to write a host that  
> will absolutely not break up audio even under overloaded conditions  
> of input/diskio/visual feedback. So far things are looking good,  
> two issues for me:

you are talking real-time right?  if you max out the cpu, you max out  
the cpu.
there is nothing you can do other than increase buffer size/latency -  
and that is only going to help so much..

> a) I need a way to schedule events from both the api or within  
> csound into the future that are reliably in sync with the score,  
> regardless of tempo changes from either beat mode or score tempo  
> changes. I guess "event" doesn't do this. Does something else? If  
> not, can we do that somewhow? This is, IMHO, critical for getting  
> high performance real time environments working in tandem with scores.

afaik, event handles tempo changes, if that's what you are asking.   
remember note start/dur resolution is at kr, so even
your score might not be synced to the sample you are thinking it is.

> b) How can we get csound engine to somehow pre-empt the rest of the  
> host when it is time to calculate more audio? ( same issue I wrote  
> about recently ). If the csound performing loop uses  
> csoundPerformKmsps() and then does other stuff, how can we reliably  
> control how much other stuff can be done without missing a csound  
> deadline? assuming a potentially limitless queue of other stuff. I  
> figure a worst case scenario would be something like ( assuming  
> real time playing as we do this )

> - host has allowed user to select and load a large audio sample  
> file from disk
> - this file is being copied into a csound table for use on the fly,  
> it is loaded and selected in a seperate lower priority thread, and  
> then all audio samples are put on to a queue for the interface to  
> load into csound table via csoundTableSet()
> - the interface takes messages off the queue that consist of a  
> direction to load one sample in to one place in a table, and then  
> keeps doing that until csoundPerformKsmps() needs to run again
>
> So, some thoughts by me:
>
> - could we somehow somehow generate an interrupt when it's time to  
> render audio? then the host uses the interrupt vector to render  
> another ksmps? I've only done this with microcontrollers so I could  
> be out to lunch on that idea
>
> - could csound signal that it wants the cpu back somehow? somesort  
> of function that allows the loop dealing with messages to check  
> before each message whether csound is actively waiting for cpu again?
>
> - how does csoundsetyieldcallback work? could it be used to signal  
> that csound does NOT need the cpu right now? could the interface  
> code try to grab a mutex before each message pass, the mutex being  
> locked by csound before performing, and unlocked repeatedly by a  
> yeild callback? so if the mutex is free, we know there are still  
> cycles left to deal with messages?
>
> - any other ideas for how to deal with the above?
>
> If I could deal with the above elegantly, I think I'd say the api  
> is good to go for me at least.

i don't think i quite follow all of what you are saying, but:

the way i do it in MacCsound, is i have maccsound do the handling of  
the CoreAudio routines, and i call csoundPerformBuffer() inside
my audio callback from the OS.  this seems to have the most reliable  
and lowest latency.   you could easily do the same from a thread
you spawn yourself.

i do most of my host graphics/controller/etc in its own separate  
threat entirely.   i try to use  yieldcallback() only as a way for
csound to ask my host if it wants to stop rendering.

i know i have always thought it would be nice to have some things  
like csound
doing file i/o in a separate threads to prevent real-time breakups.

Matt;
________________________
           matt  ingalls
http://sonomatics.com



-------------------------------------------------------
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads, discussions,
and more. http://solutions.newsforge.com/ibmarch.tmpl
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

>> So, here's my feedback, my apologies if these facilities already  
>> exist, please say how. My intent is to be able to write a host that  
>> will absolutely not break up audio even under overloaded conditions  
>> of input/diskio/visual feedback. So far things are looking good,  two 
>> issues for me:
> 
> you are talking real-time right?  if you max out the cpu, you max out  
> the cpu.
> there is nothing you can do other than increase buffer size/latency -  
> and that is only going to help so much..

Right, maybe I was not clear. What I mean is, certain host initiated 
chores should be possible to buffer out themselves, only sending the 
results to csound, so that csound can keep playing. For instance, say we 
need to load large file from disk and do something to it, normalize or 
what not. I'd like to have csound keep merrily playing, while the host 
takes as long as it needs to open the file, read in, process, and write 
the final data into a csound table. Then csound need only change what 
table number the sampler is playing to switch to that new chunk of audio.

That would be my benchmark for a good real time front end. They've done 
that kind of thing in Ableton Live and Reason, where you can really do 
quite an amazing amount of general disk i/o without audio break up.

Iain


-------------------------------------------------------
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads, discussions,
and more. http://solutions.newsforge.com/ibmarch.tmpl
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

seems like that is all on the host end, nothing needs to be changed  
with csound api?

On Oct 14, 2005, at 11:42 AM, Iain Duncan wrote:

>>> So, here's my feedback, my apologies if these facilities already   
>>> exist, please say how. My intent is to be able to write a host  
>>> that  will absolutely not break up audio even under overloaded  
>>> conditions  of input/diskio/visual feedback. So far things are  
>>> looking good,  two issues for me:
>>>
>> you are talking real-time right?  if you max out the cpu, you max  
>> out  the cpu.
>> there is nothing you can do other than increase buffer size/ 
>> latency -  and that is only going to help so much..
>>
>
> Right, maybe I was not clear. What I mean is, certain host  
> initiated chores should be possible to buffer out themselves, only  
> sending the results to csound, so that csound can keep playing. For  
> instance, say we need to load large file from disk and do something  
> to it, normalize or what not. I'd like to have csound keep merrily  
> playing, while the host takes as long as it needs to open the file,  
> read in, process, and write the final data into a csound table.  
> Then csound need only change what table number the sampler is  
> playing to switch to that new chunk of audio.
>
> That would be my benchmark for a good real time front end. They've  
> done that kind of thing in Ableton Live and Reason, where you can  
> really do quite an amazing amount of general disk i/o without audio  
> break up.
>
> Iain
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by:
> Power Architecture Resource Center: Free content, downloads,  
> discussions,
> and more. http://solutions.newsforge.com/ibmarch.tmpl
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel
>
>

-m@
________________________
           matt  ingalls
http://sfsound.org/matt.html



-------------------------------------------------------
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads, discussions,
and more. http://solutions.newsforge.com/ibmarch.tmpl
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

Matt Ingalls wrote:

>> a) I need a way to schedule events from both the api or within  csound 
>> into the future that are reliably in sync with the score,  regardless 
>> of tempo changes from either beat mode or score tempo  changes. I 
>> guess "event" doesn't do this. Does something else? If  not, can we do 
>> that somewhow? This is, IMHO, critical for getting  high performance 
>> real time environments working in tandem with scores.
> 
> 
> afaik, event handles tempo changes, if that's what you are asking.   
> remember note start/dur resolution is at kr, so even
> your score might not be synced to the sample you are thinking it is.

p2 and p3 are in seconds for event, schedule, line events, and all the
other means of triggering score events in real time. This has nothing to
do with tempo.


-------------------------------------------------------
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads, discussions,
and more. http://solutions.newsforge.com/ibmarch.tmpl
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

On Oct 14, 2005, at 11:42 AM, Iain Duncan wrote:

>> That would be my benchmark for a good real time front end. They've 
>> done that kind of thing in Ableton Live and Reason, where you can 
>> really do quite an amazing amount of general disk i/o without audio 
>> break up.

On Oct 14, 2005, at 3:12 PM, matt wrote:

> seems like that is all on the host end, nothing needs to be changed 
> with csound api?

Try benchmarking these specific implementations. Steven Yi's 
"findPowerOfTwo" UDO is required for one of them.





sr		=	44100
kr		=	441
ksmps	=	100
nchnls	=	2

#define	TEHFILE	#"dl_break0.aif"#

/*--- disk i/o example 1 ---*/

		instr	1

a1	diskin	$TEHFILE, 1, 0, 1

	outs	a1, a1

		endin

/*--- ---*/


i1	0	30

e








sr		=	44100
kr		=	441
ksmps	=	100
nchnls	=	2

#include	"findPowerOfTwo.udo"

#define	TEHFILE	#"dl_break0.aif"#
#define	FULLSCALE	#32767#

/*--- disk i/o example 2 ---*/

		instr	1

gifn1	ftgen	1, 0, 0, 1, $TEHFILE, 0, 0, 0

ilen	filelen	$TEHFILE
isamps	findPowerOfTwo ilen
gifn2	ftgen	2, 0, isamps, 1, $TEHFILE, 0, 0, 0
itabsz	=	ftlen(1)

andx	phasor	1 / (itabsz / sr)
andx		=	(andx * itabsz)

atab	table	andx, 2
atab		=	atab * $FULLSCALE

	outs	atab, atab

		endin

/*--- ---*/


i1	0	30

e




Generally, I find table lookup to be faster than diskin; it's ideas 
like these which, in my experience, help bring Csound closer to the 
proprietary apps you mention. Anyway, these examples are simply food 
for thought.


-David



-------------------------------------------------------
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads, discussions,
and more. http://solutions.newsforge.com/ibmarch.tmpl
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

> seems like that is all on the host end, nothing needs to be changed  
> with csound api?

Well, only if the api gives us the facilities to schedule cpu use 
flexibly enough. That's what I'm trying to figure out. As it stands now, 
I see no easy solution to the issue of finding out how much work the 
host can safely do with api calls ( thus requiring locking the csound 
mutex ) between calls to csoundPerformKsmp(). I can queue up requests 
for the interface code ( the bit that locks the mutex and then makes 
table writes ), but I can't see a good way to determine how many times 
to call the interface function before it's time to run another 
csoundPerformKsmp(). I suppose I could pick an arbitrary number of 
requests to deal with, but it would be better if we could have some sort 
of mechanism by which the csound engine says, "Drop everything, time to 
make audio!" And I guess the problem is that how much time we have 
between ksmps to do other work all depends on how much load the csound 
files are giving csound. I am hoping to get this variable so that when 
csound is working hard, we back up on the request queue, and catch up 
when csound is not working so hard.

Istvan, any suggestions on dealing with that? All ideas welcome!

Iain


-------------------------------------------------------
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads, discussions,
and more. http://solutions.newsforge.com/ibmarch.tmpl
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

api doesnt need to give you that.  just spawn a low priority thread  
and do your file
reading or whatever you want to do

i myself would never block the csound rendering

     On Oct 14, 2005, at 1:42 PM, Iain Duncan wrote:

>
>
>> seems like that is all on the host end, nothing needs to be  
>> changed  with csound api?
>>
>
> Well, only if the api gives us the facilities to schedule cpu use  
> flexibly enough. That's what I'm trying to figure out. As it stands  
> now, I see no easy solution to the issue of finding out how much  
> work the host can safely do with api calls ( thus requiring locking  
> the csound mutex ) between calls to csoundPerformKsmp(). I can  
> queue up requests for the interface code ( the bit that locks the  
> mutex and then makes table writes ), but I can't see a good way to  
> determine how many times to call the interface function before it's  
> time to run another csoundPerformKsmp(). I suppose I could pick an  
> arbitrary number of requests to deal with, but it would be better  
> if we could have some sort of mechanism by which the csound engine  
> says, "Drop everything, time to make audio!" And I guess the  
> problem is that how much time we have between ksmps to do other  
> work all depends on how much load the csound files are giving  
> csound. I am hoping to get this variable so that when csound is  
> working hard, we back up on the request queue, and catch up when  
> csound is not working so hard.
>
> Istvan, any suggestions on dealing with that? All ideas welcome!
>
> Iain
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by:
> Power Architecture Resource Center: Free content, downloads,  
> discussions,
> and more. http://solutions.newsforge.com/ibmarch.tmpl
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel
>
>

-m@
________________________
           matt  ingalls
http://sfsound.org/matt.html



-------------------------------------------------------
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads, discussions,
and more. http://solutions.newsforge.com/ibmarch.tmpl
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

> api doesnt need to give you that.  just spawn a low priority thread  and 
> do your file
> reading or whatever you want to do
> 
> i myself would never block the csound rendering

Ok, but how does it get into csound? I was already planning on doing the 
file reading in a low priority thread, I'm concerned about values that 
the host comes up with that need to go into a csound table, which 
requires a csound api call. If csound is also using that table, don't we 
have to do that in protected manner? I assume we can't just write into a 
csound table from anyold place if csound itself may be both reading and 
writing that same table.

Thanks
iain



-------------------------------------------------------
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads, discussions,
and more. http://solutions.newsforge.com/ibmarch.tmpl
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

if you are just writing to the same location in memory i would think  
it would be ok.
you'd be using csoundTableSet() or something?


On Oct 14, 2005, at 2:09 PM, Iain Duncan wrote:

>
>
>> api doesnt need to give you that.  just spawn a low priority  
>> thread  and do your file
>> reading or whatever you want to do
>> i myself would never block the csound rendering
>>
>
> Ok, but how does it get into csound? I was already planning on  
> doing the file reading in a low priority thread, I'm concerned  
> about values that the host comes up with that need to go into a  
> csound table, which requires a csound api call. If csound is also  
> using that table, don't we have to do that in protected manner? I  
> assume we can't just write into a csound table from anyold place if  
> csound itself may be both reading and writing that same table.
>
> Thanks
> iain
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by:
> Power Architecture Resource Center: Free content, downloads,  
> discussions,
> and more. http://solutions.newsforge.com/ibmarch.tmpl
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel
>
>

-m@
________________________
           matt  ingalls
http://sfsound.org/matt.html



-------------------------------------------------------
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads, discussions,
and more. http://solutions.newsforge.com/ibmarch.tmpl
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

> if you are just writing to the same location in memory i would think  it 
> would be ok.
> you'd be using csoundTableSet() or something?

Sure, but what if I am writing to the location in table memory, and 
there is the possibility of csound reading and/or writing to the same 
location at the same time? The csound table reading opcodes can't be 
atomic instructions so we risk data corruption there right? And given 
the way csound tends to handle table i/o errors ( killing instruments, 
segfaulting, etc ) I would think this would be a bad thing.

Iain

> 
> On Oct 14, 2005, at 2:09 PM, Iain Duncan wrote:
> 
>>
>>
>>> api doesnt need to give you that.  just spawn a low priority  thread  
>>> and do your file
>>> reading or whatever you want to do
>>> i myself would never block the csound rendering
>>>
>>
>> Ok, but how does it get into csound? I was already planning on  doing 
>> the file reading in a low priority thread, I'm concerned  about values 
>> that the host comes up with that need to go into a  csound table, 
>> which requires a csound api call. If csound is also  using that table, 
>> don't we have to do that in protected manner? I  assume we can't just 
>> write into a csound table from anyold place if  csound itself may be 
>> both reading and writing that same table.
>>
>> Thanks
>> iain
>>
>>
>>
>> -------------------------------------------------------
>> This SF.Net email is sponsored by:
>> Power Architecture Resource Center: Free content, downloads,  
>> discussions,
>> and more. http://solutions.newsforge.com/ibmarch.tmpl
>> _______________________________________________
>> Csound-devel mailing list
>> Csound-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>
>>
> 
> -m@
> ________________________
>           matt  ingalls
> http://sfsound.org/matt.html
> 
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by:
> Power Architecture Resource Center: Free content, downloads, discussions,
> and more. http://solutions.newsforge.com/ibmarch.tmpl
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel
> 


-------------------------------------------------------
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads, discussions,
and more. http://solutions.newsforge.com/ibmarch.tmpl
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

You're right, I think.  It is not easy to determine how much to do before
passing control back to the audio production code.  Matt's system in
MacCsound is VERY different because the OS butts in every time it needs more
audio and his audio callback directly calls csoundPerform*.  This is not
possible with the Csound 5 API though, AFAIK.

There were some functions in the API for profiling how much CPU power was
being used by Csound, but I think they were removed because they had not
been finished.  Something like this would allow your host to estimate how
much time Csound needs in real-time and try to respond flexibly.

But, then, I am no real-time expert ...  *shrug*

Anthony

Iain Duncan wrote on 10/14/05 4:42 PM:

> 
>> seems like that is all on the host end, nothing needs to be changed
>> with csound api?
> 
> Well, only if the api gives us the facilities to schedule cpu use
> flexibly enough. That's what I'm trying to figure out. As it stands now,
> I see no easy solution to the issue of finding out how much work the
> host can safely do with api calls



-------------------------------------------------------
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads, discussions,
and more. http://solutions.newsforge.com/ibmarch.tmpl
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

Anthony Kozar wrote:

> You're right, I think.  It is not easy to determine how much to do before
> passing control back to the audio production code.  Matt's system in
> MacCsound is VERY different because the OS butts in every time it needs more
> audio and his audio callback directly calls csoundPerform*.  This is not
> possible with the Csound 5 API though, AFAIK.

It should be possible, as long as the audio callback does not have
special requirements like not calling malloc() or other system functions,
or having a hard deadline on completing audio processing which if not met
would result in a crash, etc. I already tried this using PortAudio on
Linux, and it worked fine, but the Mac may be different.
In any case, it is likely that a host with special real-time requirements
would implement its own audio I/O with any necessary custom features like
monitoring CPU usage or using a host specific thread locking mechanism,
rather than using the rtaudio plugins included with Csound.


-------------------------------------------------------
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads, discussions,
and more. http://solutions.newsforge.com/ibmarch.tmpl
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

David Akbari wrote:

> Generally, I find table lookup to be faster than diskin; it's ideas like 
> these which, in my experience, help bring Csound closer to the 
> proprietary apps you mention. Anyway, these examples are simply food for 
> thought.

diskin and soundin are not really slow as far as average CPU usage
is concerned (note that you compared table which does not interpolate
audio with diskin that does), the more important problem is occasional
high peaks in CPU usage at opening the file or filling the input buffer,
potentially resulting in buffer underruns in real time audio output.
On a machine with lots of memory and an OS that allows for creating a
filesystem in memory, this may be worked around to some extent; for
example, on Linux you may try copying the files to tmpfs and reading
with soundin or diskin2 with a small buffer size.


-------------------------------------------------------
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads, discussions,
and more. http://solutions.newsforge.com/ibmarch.tmpl
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

>> You're right, I think.  It is not easy to determine how much to do before
>> passing control back to the audio production code.  Matt's system in
>> MacCsound is VERY different because the OS butts in every time it 
>> needs more
>> audio and his audio callback directly calls csoundPerform*.  This is not
>> possible with the Csound 5 API though, AFAIK.
> 
> 
> It should be possible, as long as the audio callback does not have
> special requirements like not calling malloc() or other system functions,
> or having a hard deadline on completing audio processing which if not met
> would result in a crash, etc. I already tried this using PortAudio on
> Linux, and it worked fine, but the Mac may be different.
> In any case, it is likely that a host with special real-time requirements
> would implement its own audio I/O with any necessary custom features like
> monitoring CPU usage or using a host specific thread locking mechanism,
> rather than using the rtaudio plugins included with Csound.

This sounds conceptually like what I was intending when I was going on 
about interrupts. If you have time to show us how one could could have 
the audio callback ask for csound to perform I would like to see it.

Thanks
Iain


-------------------------------------------------------
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads, discussions,
and more. http://solutions.newsforge.com/ibmarch.tmpl
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

On Oct 15, 2005, at 8:37 AM, Istvan Varga wrote:

> On a machine with lots of memory and an OS that allows for creating a
> filesystem in memory, this may be worked around to some extent; for
> example, on Linux you may try copying the files to tmpfs and reading
> with soundin or diskin2 with a small buffer size.

How very interesting. I was able to reproduce this idea on the mac os 
by creating a disk image file of samples (a filesystem in memory like 
you said, *.dmg, which contained linear PCM encoded samples (.aiff, 
.wav)) and buffersizes (-bx -Bx) of both x=128 and x=1024.

I noticed a marked decrease in CPU % (as reported by maccsound and 
top). This technique is very interesting and I look forward to 
experimenting with it and implementing it more. Thanks for sharing this 
idea!

> (note that you compared table which does not interpolate
> audio with diskin that does),

Would the comparison have been more accurate if tablei was used 
instead? (In other words, which type of interpolation is diskin2 using 
... linear?)

I think it may be useful to see how diskin2 performs without 
interpolation. Perhaps appending an o-arg to diskin2 which is a boolean 
(default=1) to whether or not to use interpolation ?

> the more important problem is occasional
> high peaks in CPU usage at opening the file or filling the input 
> buffer,
> potentially resulting in buffer underruns in real time audio output.

Typically, the table loading technique seems efficient when using 
multiple files, loading in and out (possibly just re-writing one 
table).

In what ways is it now possible to use S-variables and 
diskin2/soundin(s) to achieve a variable loading mechanism? Is it legal 
to just use:

Sfile    =  "filename"
aOut    diskin2   Sfile, 1, 0, 1

It would be nice because then of course you could be using reinit, if, 
then, goto, and other high level logical operations to manipulate 
S-variables which are ultimately loaded into one diskin2/soundin...

Are there currently any GEN routines that deal with the 
storage/retrieval of S-vars? Is it problematic to use GEN23 for this 
purpose?


-David



-------------------------------------------------------
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads, discussions,
and more. http://solutions.newsforge.com/ibmarch.tmpl
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

David Akbari wrote:

> How very interesting. I was able to reproduce this idea on the mac os by 
> creating a disk image file of samples (a filesystem in memory like you 
> said, *.dmg, which contained linear PCM encoded samples (.aiff, .wav)) 
> and buffersizes (-bx -Bx) of both x=128 and x=1024.

When referring to smaller buffer size, I meant the buffer size for
the soundin or diskin2 opcode, which is 2048 and 4096 mono samples
by default, respectively. Reducing the buffer size does not improve
the overall CPU usage, but makes it more evenly distributed and
possibly more friendly to low latency real time usage. However, on
a machine with very fast memory, this may not actually make a
significant difference.

> Would the comparison have been more accurate if tablei was used instead? 
> (In other words, which type of interpolation is diskin2 using ... linear?)

diskin2 can use several interpolation types, including linear, cubic,
and sinc (with anti-aliasing) with number of samples ranging from 8 to
1024, as well as no interpolation. The default is cubic interpolation.

> I think it may be useful to see how diskin2 performs without 
> interpolation. Perhaps appending an o-arg to diskin2 which is a boolean 
> (default=1) to whether or not to use interpolation ?

It already has the "window size" parameter that selects interpolation
type:

           1:  none
           2:  linear
           4:  cubic
   8 to 1024:  sinc

However, for simple, fast non-interpolated reading of sound files,
soundin is preferred, unless you need resampling or the "wrap" feature
of the diskin opcodes.

> In what ways is it now possible to use S-variables and 
> diskin2/soundin(s) to achieve a variable loading mechanism? Is it legal 
> to just use:
> 
> Sfile    =  "filename"
> aOut    diskin2   Sfile, 1, 0, 1

Yes. soundin, diskin, and diskin2 evaluate the file name at i-time only,
though, so if you change it at k-rate you may need to use reinit to
make the opcodes switch to the new file.
In general, you can use a string variable as input argument to any
opcode that would require a "quoted string" according to the manual,
just remember that some opcodes may not respond well to the string
being changed at k-rate and using reinit may be needed.

> Are there currently any GEN routines that deal with the 
> storage/retrieval of S-vars? Is it problematic to use GEN23 for this 
> purpose?

Not yet, but the idea sounds interesting. Do you mean loading and
storing characters of a string from/to a function table (that is,
"foo" would translate to the four table values 102, 111, 111, 0) ?
Of course, you already have strset that is basically a global table
(rather like ZAK) of string values which can be read and written
with strget and strset, and sound I/O opcodes can also access the
strset table by specifying a number index instead of a string name.



-------------------------------------------------------
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads, discussions,
and more. http://solutions.newsforge.com/ibmarch.tmpl
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net