http://bugs.winehq.org/show_bug.cgi?id=29585
Bug #: 29585 Summary: wineoss.drv audio renderer not on par with others Product: Wine Version: 1.3.36 Platform: x86 URL: http://www.winehq.org/pipermail/wine-devel/2012-Januar y/093721.html OS/Version: Linux Status: NEW Severity: normal Priority: P2 Component: mmdevapi AssignedTo: wine-bugs@winehq.org ReportedBy: hoehle@users.sourceforge.net CC: aeikum@codeweavers.com Classification: Unclassified
The OSS4 mmdevapi audio renderer is not yet on par with developments in the two other ones in Wine.
Specific issues are: 1. handling underrun(?) 2. handling incomplete last (initial?) period 3. correct GetPosition 4. non-blocking mode or not needed? i.e. what's mostly covered by my renderer tests attached to bug #27937. Some of it was discussed in bug #28056.
This bug is *not* about mixer related issues, or failure to recognize an audio device at all, or recording. If your Linux or BSD system has such issues with Wine, please file another bug.
Andre Eikum proposed a patch to GetPosition in: http://www.winehq.org/pipermail/wine-devel/2012-January/093721.html It has two flaws: + *pos = 0; this should be at least the position of the last Start (I highly recommend This->last_pos_frames).
+ stopped/running/etc. state is not checked, yet GETODELAY can only be invoked while running (witness IIRC the logs attached to bug #28056).
The current ALSA driver is not the best, but here is how I believe several issues could be solved: - Decouple OSS buffer from mmdevapi buffer, a bit like winealsa;
- Hide at least one OSS period in that buffer, i.e. GetCurrentPadding yields 0 while OSPACE < oss_period and 1 with period+1. This will help with bug #28723.
That way, unreliable OSS padding < period won't bother GetCurrentPadding.
My preference goes to something like attached to bug #28723, comment #105, except it should try to hide less than the 3 periods winealsa hides in 1.3.35, i.e. somewhat of a breed of that attachment and Andrew's initial wine 1.3.25 code.
- At callback time, complete a partial mmdevapi period by adding trailing silence. We need to do that with ALSA too to ensure short sounds get played, as well as trailing samples on period-driven devices like dmix. This is the major ALSA bug #26878. Here I'd like to know how OSS behaves.
- Introduce This->last_pos_frames like I did with ALSA;
...Underrun GetPosition() must return `size'
Not immediately, according to bug #28723, comment #65. But if underrun can be defined as OSPACE < oss_period (not sure, presumably then 2 OSS periods need be hidden from GCP), then we can bump last_pos_frames.
Regarding non-blocking mode, I simply don't know whether OSS may block in open(), waiting for another process. While playing, now that GETOSPACE is used, blocking may be prevented (I've some doubts since I saw ALSA return EAGAIN with nearly full buffers in non-blocking mode).
For now, I believe it would be enough to behave like an exclusive-mode renderer and not bother with decrementing padding in mmdevapi-period-size chunks -- I still don't know how to best do that.