Major mmdevapi and winmm audio bugs

[Joerg-Cyril.Hoehle at t-systems.com]

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