I would like to know what the best way is to allow csound to run with 
lower latency in a host where csound is one thread and fltk another, on 
linux. The fltk thread has quite a lot of potential drawing going on. I 
can't use --sched with the csd in an api host.

Can I lower the fltk thread priority somehow? I am using the csound 
threads but I could revert to raw pthreads. Should I lower the priority 
of the X server? Istvan, I remember you posting an example of how to add 
the --sched code to an app. Is it possible to add that to only one 
thread? Could you repost that if you have time? ( I tried looking but 
can't find it. ) I would prefer not to have to have the fltk stuff 
running a seperate process, though that is an option.

Thanks
Iain


-------------------------------------------------------
This SF.Net email is sponsored by the JBoss Inc.  Get Certified Today
Register for a JBoss Training Course.  Free Certification Exam
for All Training Attendees Through End of 2005. For more info visit:
http://ads.osdn.com/?ad_id=7628&alloc_id=16845&op=click
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

On Nov 22, 2005, at 6:10 PM, Iain Duncan wrote:

> Can I lower the fltk thread priority somehow?

I usually find the *nix command "nice" useful to suit this purpose.

For users of any Macintosh system running OS 10, there is a freeware 
graphical front end for this purpose made by La Chose Interactive 
called "Process Wizard"

http://www.lachoseinteractive.net/en/products/processwizard/

Users can expect to see a roughly 30% increase in speed just by using 
this app which is ultimately a front-end for the nice command. See the 
man page for nice in your csh of choice on any *nix.


-David



-------------------------------------------------------
This SF.Net email is sponsored by the JBoss Inc.  Get Certified Today
Register for a JBoss Training Course.  Free Certification Exam
for All Training Attendees Through End of 2005. For more info visit:
http://ads.osdn.com/?ad_id=7628&alloc_id=16845&op=click
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

> Here is a simplified version of the --sched code in Csound.
> Just add this to your build as a separate .c file, and declare
> and call the following function:
> 
>   int set_rt_priority(int priority, int cpuMax, int secs);
> 
> 'priority' is the scheduling priority (-20 to -1 for nice only, 0 for
> SCHED_OTHER with normal priority, and 1 to 99 for SCHED_RR with the
> specified priority - 99 is the same as --sched with no additional
> parameters; on all settings, memory is locked). If 'cpuMax' and 'secs'
> are non-zero, a watchdog thread is created which will terminate the
> program if the CPU usage exceeds 'cpuMax' (1 to 99) over a time period
> of 'secs' (1 to 60).

Thanks Istvan. Is this something that must be called for the whole 
process from main, or can it be called in each thread? The architecture 
of the host is basically the same as my examples, so main spawns several 
threads, one handles fltk stuff and one calls csound. Do I call the 
above from the main or the csound thread? And do I then call this stuff:

 > #ifdef LINUX
 >   {
 >     struct sched_param  sp;
 >     // IV - Aug 27 2002: widget thread is always run with normal priority
 >     memset(&sp, 0, sizeof(struct sched_param));
 >     pthread_setschedparam(pthread_self(), SCHED_OTHER, &sp);
 >   }
 > #endif

from the fltk thread?

Thanks again
Iain


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

> It was originally intended to be used in the main thread at start-up.
> However, you can make the child threads inherit the real-time scheduling
> policy with something like:
> 
> uintptr_t csound_thread_func(void *userData);

Istvan, does this mean that in order to have the rest of the app at 
lower priority then the csound thread I must use pthreads instead of the 
csoundThread functions? I'm a bit confused here. Would it be easiest to 
just revert all my thread creation calls to pthread native library 
calls, or can I combine them with the csound api thread calls? Would it 
make sense to use pthread native calls for only the fltk thread? I think 
that is the only one that critically needs to be lowered, but ideally I 
would like the csound thread to be higher priority than keyboard and 
midi input as well. On the other hand, keyboard and midi input is going 
to be coming in so slowly relatively speaking, that maybe the simplest 
solution is to keep the rest of the app in csoundThreads and pthread 
only the fltk thread.

So what happens if from main I set_rt_priority high, and then spawn a 
pthread for the fltk thread and set it lower as you suggest?

Sorry I'm confused here, and thanks again for the help.
Iain


> 
> int main(int argc, char **argv)
> {
>   void *csound_thread, *userData;
>   ...
> #ifdef LINUX
>   if (set_rt_priority(98, 97, 10) != 0)
>     error();  /* fail in some way */
> #endif
>   ...
> #ifdef LINUX
>   {
>     pthread_attr_t attr;
>     pthread_t th;
>     pthread_attr_init(&attr);
>     pthread_attr_setinheritsched(&attr, PTHREAD_INHERIT_SCHED);
>     pthread_create(&th, &attr, (void *(*)(void*)) csound_thread_func,
>                    userData);
>     csound_thread = (void*) th;
>     pthread_attr_destroy(&attr);
>   }
> #else
>   csound_thread = csoundCreateThread(csound_thread_func, userData);
> #endif

> 
>>And do I then call this stuff: 
>> > #ifdef LINUX
>> >   {
>> >     struct sched_param  sp;
>> >     // IV - Aug 27 2002: widget thread is always run with normal
>> > priority memset(&sp, 0, sizeof(struct sched_param));
>> >     pthread_setschedparam(pthread_self(), SCHED_OTHER, &sp);
>> >   }
>> > #endif
>>
>>from the fltk thread?
> 
> 
> Yes.
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
> for problems?  Stop!  Download the new AJAX search engine that makes
> searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
> http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel
> 


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

Thanks for all the help and the awesome scheduling code Istvan, it seems 
to do a great job. I was able to get my buffers down to ksmp=8, -b4 -b16 
with no breakup while the fltk window twirled 128 knobs around reading 
them csound tables! Switching tabs in the gui and dragging the window 
around was no problem at all. Even better, the cpu use was only a few 
percent higher for the gui, and the buffer settings seem to be only very 
nominally worse than I can get without the gui, if at all. This bodes 
very well for high performance real time front ends on linux at least!

Rather than get confused casting pointers between csoundthreads and 
pthreads, I just reverted all the thread calls to pthreads for this 
version. Seems to be ok, and not really much more complicated. One 
question, instead of doing your suggestion for the fltk thread, I made 
two thread attributes, and told one ( for the fltk thread ) to use 
SCHED_OTHER, like so:

pthread_attr_t attr_high, attr_low;
pthread_attr_init(&attr_high);
pthread_attr_init(&attr_low);
pthread_attr_setinheritsched(&attr_high, PTHREAD_INHERIT_SCHED);
pthread_attr_setschedpolicy(&attr_low, SCHED_OTHER);

int ret_cs_t = pthread_create( &cs_thread, &attr_high, 
cs_thread_routine, (void *)cs_inter );

int ret_fltk_t = pthread_create( &fltk_thread, &attr_low, 
fltk_thread_routine, ( void *)cs_inter );

As far as I can tell, this is working ok, because if I push the system 
to max cpu limits, the fltk thread is noticeably lagging while audio 
still is ok ( ie the dials appear slowly across the screen ). Is there 
anything wrong with the above solution? Any situations in which it will 
not be adequate? All the above is contained within main, which uses your 
set_rt_priority() function, so my hope was that this way only the csound 
thread would inherit the high priority scheduling and the fltk would use 
normal priority.

Thanks again
Iain

Istvan Varga wrote:
> On Friday 25 November 2005 07:21, Iain Duncan wrote:
> 
> 
>>>It was originally intended to be used in the main thread at start-up.
>>>However, you can make the child threads inherit the real-time scheduling
>>>policy with something like:
>>>
>>>uintptr_t csound_thread_func(void *userData);
>>
>>Istvan, does this mean that in order to have the rest of the app at
>>lower priority then the csound thread I must use pthreads instead of the
>>csoundThread functions?
> 
> 
> The csoundThread functions are based on pthreads, so you can use
> pthreads to create the thread and set priority on Linux only, and
> use csoundCreateThread() on other systems for portability (obviously,
> you will not have priority control, but at least it works). You can
> join a thread created by pthread_create() with csoundJoinThread(),
> just cast the function to void *(*)(void*), and cast the resulting
> pthread_t to void*.
> However, if you do not care about non-POSIX systems like Win32, then
> you do not really need the csoundThread functions for anything at all.
> 
> 
>>I'm a bit confused here. Would it be easiest to 
>>just revert all my thread creation calls to pthread native library
>>calls, or can I combine them with the csound api thread calls? Would it
> 
> 
> You can combine the Csound API thread functions with native pthreads
> on Linux where the Csound interface is based on pthreads, with the
> following simple casts:
> 
>   void *(*)(void*) -> uintptr_t (*)(void*)
>   pthread_t        -> void*
>   pthread_mutex_t  -> void*
> 
> 
>>make sense to use pthread native calls for only the fltk thread? I think
>>that is the only one that critically needs to be lowered, but ideally I
>>would like the csound thread to be higher priority than keyboard and
>>midi input as well. On the other hand, keyboard and midi input is going
>>to be coming in so slowly relatively speaking, that maybe the simplest
>>solution is to keep the rest of the app in csoundThreads and pthread
>>only the fltk thread.
> 
> 
> Again, you can use code like this for creating a thread with the
> same high priority as main (replace the names csound_thread_func,
> userData, and csound_thread as needed):
> 
> uintptr_t csound_thread_func(void *);
> ...
> #ifdef LINUX
>   {
>     pthread_attr_t attr;
>     pthread_t th;
>     pthread_attr_init(&attr);
>     pthread_attr_setinheritsched(&attr, PTHREAD_INHERIT_SCHED);
>     pthread_create(&th, &attr, (void *(*)(void*)) csound_thread_func,
>                    userData);
>     csound_thread = (void*) th;
>     pthread_attr_destroy(&attr);
>   }
> #else
>   csound_thread = csoundCreateThread(csound_thread_func, userData);
> #endif
> 
> The resulting csound_thread (of type void*) can be joined with
> csoundJoinThread() on all platforms.
> Also, for low priority threads, just add this at the beginning
> of the thread function:
> 
> #ifdef LINUX
>   {
>     struct sched_param  sp;
>     memset(&sp, 0, sizeof(struct sched_param));
>     pthread_setschedparam(pthread_self(), SCHED_OTHER, &sp);
>   }
> #endif
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
> for problems?  Stop!  Download the new AJAX search engine that makes
> searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
> http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel
> 


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net