Re: USB Audio driver and THREAD_TIME_CONSTRAINT_POLICY
Re: USB Audio driver and THREAD_TIME_CONSTRAINT_POLICY
- Subject: Re: USB Audio driver and THREAD_TIME_CONSTRAINT_POLICY
- From: Vyacheslav Matyushin <email@hidden>
- Date: Mon, 19 Dec 2011 10:23:06 -0800 (PST)
Hi Ross,
Thanks for your ideas!
You will lose real-time priority if for some reason you violate the
constraint. You could try setting constraint higher just to see if that
helps.
After setting .computation to 250 and .constraint to 450 (with .period 500) in driver nothing changed.
Actually (time2 - time1)/1000 is rarely more than 100 and almost never more than 150.
Are you sure clock_get_uptime() is what you want? Seems like
clock_get_system_nanotime() would be more appropriate if you're trying
to reliably get values in nanoseconds, see:
After replacing clock_get_uptime() with clock_get_system_nanotime() nothing changed also.
Btw clock_get_uptime() is used in IOAudioEngine::takeTimeStamp().
On 20/12/2011 12:15 AM, Vyacheslav Matyushin wrote:
> ret = nanosleep(&rqt, NULL); // sleep for SLEEP_NS seconds
Have you tried testing against mach_wait_until instead?
Tried that and still observed this strange behavior:
more than 10 errors in average when not under load and 0-5 errors when under load.
> #define ERROR_THRESH_NS ((double)50000) // 50 us
Personally I would expect more like 150us jitter in userspace -- but
this is just based on a few rough tests I've done.. nothing scientific.
After setting this to 150 there are almost no errors even with ordinary priority (not realtime)
so it hides THREAD_TIME_CONSTRAINT_POLICY strangeness.
Thanks,
Vyacheslav Matyushin.
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Coreaudio-api mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden