Re: [Iaxclient-devel] Setting output level on windows

[Steve K. <st...@st...>]

Cyril VELTER wrote:

>	While evaluating iaxclient, I noticed a small bug in px_win_wmme.c line 735 
>(_Px_InitOutputVolumeControls). 
>
>mixerOpen( 
>		( LPHMIXER )( &mixer->hInputMixer ), 
>		hWaveOut, 0, 0,
>		MIXER_OBJECTF_HWAVEOUT 
>	) ;
>
>
>should be 
>
>mixerOpen( 
>		( LPHMIXER )( &mixer->hOutputMixer ), 
>		hWaveOut, 0, 0,
>		MIXER_OBJECTF_HWAVEOUT 
>	) ;
>
>
>	the cirrent code does not set the output volume of the right interface (in the 
>case the current device is not the first one)
>  
>
I didn't write that code, but AFAIK it seemed to be working correctly 
for us.  I'll ask the original author, who knows this code better than I do.

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

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

-SteveK