[Bug 29585] New: wineoss.drv audio renderer not on par with others
wine-bugs at winehq.org
wine-bugs at winehq.org
Tue Jan 10 14:10:45 CST 2012
Bug #: 29585
Summary: wineoss.drv audio renderer not on par with others
AssignedTo: wine-bugs at winehq.org
ReportedBy: hoehle at users.sourceforge.net
CC: aeikum at codeweavers.com
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:
It has two flaws:
+ *pos = 0;
this should be at least the position of the last Start (I highly recommend
+ 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
- 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;
>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.
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
Do not reply to this email, post in Bugzilla using the
above URL to reply.
------- You are receiving this mail because: -------
You are watching all bug changes.
More information about the wine-bugs