[Portaudio] use of timeBeginPeriod() in pa_win_ds.c

Theo Veenker theo.veenker at beexy.nl
Fri Aug 25 11:18:42 EDT 2017


On 04/05/2017 07:14 PM, Theo Veenker wrote:
> On 03/27/2017 03:51 PM, Ross Bencina wrote:
>> On 27/03/2017 11:07 PM, Theo Veenker wrote:
>>>>
>>>> Could you please outline why you want the flag as well as the check?
>>>
>>> I don't feel happy about loading DLL on Pa_OpenStream(). On my test
>>> system it was fast, but what if it takes 50ms or more in some
>>> configuration or what if it would somehow fail. Maybe I'm just blessed
>>> with a sense of paranoia.
>>
>> I see. I agree that loading a DLL in Pa_OpenStream() is not great. I don't like adding a
>> flag to the API just to avoid this though.
>>
>>
>>> Wild idea: Load the ntdll at Pa_initialize() and then you have both
>>> NtQueryTimerResolution() and NtSetTimerResolution() at your disposal for
>>> the windows APIs that need to check/adjust the system timer tick.
>>
>> I like this much better than adding a flag to the API.
>>
>> Given that you only need DirectSound support, perhaps start by doing the DLL load in the
>> PA/DirectSound init/terminate? This will make it execute at Pa_Initialize time, but
>> doesn't require going all the way to a PA global infrastructure (although if you want to
>> work on a global thing I'm ok with accepting a patch for it).
> 
> Ross, I took a shot at it, see attached patch for v19_20140130. I only looked at the 
> dsound case. AFAIK there's no way to access the PaWinDsHostApiRepresentation struct from
> PaWinDsStream so I ended up adding stuff to both structs.
> 
> Note, one could replace all calls to timeGetDevCaps() by NtQueryTimerResolution() and all 
> calls to timeBeginPeriod()/timeEndPeriod() by NtSetTimerResolution().

Hi Ross,

I know it has been a while, but did you manage to take a look at the patch I sent that 
prevents PA (for DirectSound) to select a worse system timer interval than is currently in 
use.

Best regards,
Theo


More information about the Portaudio mailing list