Major mmdevapi and winmm audio bugs

[Maarten Lankhorst]

Hey Joerg,

Op 27-02-12 19:22, Joerg-Cyril.Hoehle at t-systems.com schreef:
> 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.
Agreed, I've tried to keep it as small as possible for the thread itself,
the mainloop thread calls very few functions, I need to add a bit more,
but the only source of problems could come from the pulseaudio lib itself.

At this point my winepulse driver is very reliable for rendering, and capture
should be the same once I add the queue stuff, it would also be the only driver
to actually pass the tests.

For capture I plan to just add 2 queues, one for readable packets, and one
for packets that can be filled for reading. With that approach I should be
able to pass all tests in the most efficient way while keeping the metadata
mmdevapi adds for capture.

>> 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...
Even if so, it is unneeded for the pulse driver, I'm using the auto timing
update feature and the callback for when rendering is not running.
When the buffer is not underflowed, I'm using the write callback to
signal more data is available.

Timerqueue would be a lie, the driver should schedule when data can
actually be written and not based purely on ticks. Pulseaudio allows
this and I'm using this feature in my driver. It passes all the render
tests now except the volume related ones (they're a reminder,
and a nop on other drivers anyhow), and I'm working to complete
capture in a similar fashion as well.

I believe the event should be triggered when there is actual data
available, at least that's how I understood the event is supposed
to work. Doing it based on a timer that isn't tied to the state in
any way feels wrong. Having 2 threads for pulse feels wrong too,
especially since it can be done with just using the one pulse
provides, because you can set callbacks for when more data
can be read or written.

~Maarten