Hi,
Maarten Lankhorst wrote (partly in a former thread):
R. thread priority -- no "Pro Audio" / Real-Time priority
Not going to happen, ever. AJ nuked all my attempts at it, [...] Or just fix things properly and use rtkit for time critical threads
and now:
I would say using rtkit for setting threads to realtime would be an aid for this.
I can understand AJ's reluctance to RT code in Wine. I wouldn't feel comfortable either. I believe few people realize that RT is a gifted gift. Bear in mind that RT processes work at a priority above any root or user process. Do something wrong there, consume 100% CPU and you can press the single core machine's power down button. I would not accept RT code in a system without a very careful code review and think twice about the consequences, and require a design that keeps the RT part of the app as small as possible, better separated.
OTOH, RT is the means to provide reliable ticks, and that's why PA as a sound server wants that. Now one can argue that Wine's mmdevapi plays sound server for all w32 apps, so it has the same needs.
I'm just using a simple mainloop thread
That's my plan for past 1.4 too. Get rid of CreateTimerQueue as callback source in mmdevapi, use a thread for the feeder and poll() to wait 10ms, like all devices used to do. I believe that's too big a change for code freeze.
W.r.t. to 1.4.0, I believe the following path should be taken: - Write CreateTimerQueue tests to verify whether native behaves like: a) sleep(Xms) /* what Wine does now */ or b) sleep(Xms - elapsed) /* what winmm:timeSetEvent does */ - If b), fix CreateTimerQueue. - If a), CreateTimerQueue is unusable for the purposes of Wine's mmdevapi and something else must be sought...
Regards, Jörg Höhle