[Bug 29585] wineoss.drv audio renderer not on par with others

[wine-bugs at winehq.org]

http://bugs.winehq.org/show_bug.cgi?id=29585

Chris Purnell <cjp at lost.org.uk> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |cjp at lost.org.uk

--- Comment #52 from Chris Purnell <cjp at lost.org.uk> 2012-04-13 23:40:59 CDT ---
(In reply to comment #51)
> Chris, I don't understand parts of what you wrote. Could you please elaborate?

> >In fact it existed in the data that was being written.

I added some debugging code to write a copy the audio data to a file and on
playing that file I heard the exact same crackling.

> >It was doing this because the value from GetPosition was
> >jumping ahead to exactly 10 dsound fragments beyond the dsound's saved value
> ??

The way wine's dsound currently works is it initially gives mmdevapi 10
fragments. Then is sends more fragments as the mmdevapi GetPosition increases.

When held_frames is zero, the oss mmdevapi GetPosition jumps to maximum.

Dsound sees this and sends 10 more fragments.

> >wineoss.drv should definitely not be reporting the position of
> >an underrun event that has not happened yet.
> Definitely.  But where/how do you diagnose this in wineoss?

By looking at the value from GetPosition over time and seeing it suddenly jump
to a value that corresponds to all the data passed to mmdevapi thus far.

> Part of what I don't understand about what you write is what DSound is doing
> wrong and what mmdevapi is doing wrong.

I don't know what, if anything, dsound is doing wrong.  I've not looked at
dsound beyound its interaction with mmdevapi.

> What I want:
> 1. Have mmdevapi produce sound values.
> Here you patch is incorrect, because GetPosition should a priori not bump to
> maximum when held_frames is zero.  That point is debatable and debated[*].

What you said there is kind of confusing, even after I looked up "priori".

The thing is GetPosition should not suddenly jump ahead. I was seeing it jump
forward by as much as 90ms.

Also, don't confuse held_frames with GetCurrentPadding. GetCurrentPadding may
currently return held_frames but that may not be the correct thing to do.

But dsound is currently using GetPosition and not GetCurrentPadding so I don't
care about GetCurrentPadding.

> 2. Have DSound deal with huge latencies.
> >This delay was hovering around a little under 3-4 device fragments.
> >That is about 7 dsound fragments.
> What you write sounds to me as if DSound does not work well when the latency is
> almost as large as its buffer.  I think this is a known bug in Wine's DSound,
> that has become apparent since the switch to mmdevapi.  Former code used to lie
> about latency.
> Is what you mean point L in my list:
> http://www.winehq.org/pipermail/wine-devel/2012-January/093982.html

Latency does not appear to be a problem.

For example, one thing I tried was "max_period = This->period_frames" and
ignoring bi.fragsize there. This ment that less was written to the device so
held_frames never hit 0 and avoided the problem.

Another thing I tired was removing the SNDCTL_DSP_GETODELAY from GetPosition
entirely. This adds a lot of latency to dsound playback but other than that is
seemed to work fine.

It just seems to be a simple case of inconsistant values of GetPosition
depening upon whether held_frames is 0 or not.  Something the other mmdevdrvs
don't do.

That said they may be other problems with wine's dsound if you really do have
unavoidably large audio latancies.

There are some things I don't get:
Why not write as much as possible to the device?
Why no SNDCTL_DSP_SETFRAGMENT?

-- 
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.