From: Cyril V. <cyr...@me...> - 2004-11-15 18:50:58
|
> Cyril VELTER wrote: > > >Regarding thread priority, it is better to set the thread priority directly. On > >windows, scheduling is done thread by thread and SetPriorityClass influence > >every thread in a process which is not good. It would be better to replace > > > > SetPriorityClass > > > >by > > > > SetThreadPriority(GetCurrentThread(),THREAD_PRIORITY_TIME_CRITICAL) > > > >this will only change the priority of the thread servicing audio and not any > >other threads (user interface ...) > > > > > It depends on what you're actually trying to do, or if your UI threads > can end up blocking your audio/network threads or now. I think that in > practice, it shouldn't make too much difference, because the UI thread > for a softphone will generally be simple enough that it won't use much > CPU anyway. However, if your UI thread can block processing in some way > (i.e. it might hold a mutex that the callbacks need to get), then having > it also run with elevated priority will prevent the audio/network thread > from blocking on that mutex. (I suppose, that a smart scheduler _might_ > be smart enough to see that a high-priority thread is blocking on a > mutex held by a lower-priority thread, and it could increase the > lower-priority thread's priority until it drops the mutex or something). > > In my application, I actually increase the priority of the whole > application when I launch it from another application, so this priority > stuff is redundant, and I just added it for the community. I'm more > than open to making it thread-specific if others agree.. I agree it depends on the application. iaxclient is a library and should not IMHO modify the process priorityclass because it has no knowledge of what the application do. Modifying the thread priority is OK because the library know what the the thread is doing and that it needs a high priority to service audio. > > >Is there any plan ta support Alaw (I'm in france, and it's the native pstn > >codec here) ? I've hacked some support base on asterisk code, but there might > >be licencing issues. > > > > > > I don't plan on writing it, but it's pretty simple, so someone could if > they had a few hours and some motivation. If it's based on asterisk > code, that's not OK licensing wise, unless you get a disclaimer from > digium to relicense it LGPL. I have a patch for alaw support (I just reworted it from scratch, inspired by the ulaw codec and some sun free code). Is it possible to include this in CVS ? and where should I post the patch ? cyril velter |