http://bugs.winehq.org/show_bug.cgi?id=29585
Chris Purnell cjp@lost.org.uk changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |cjp@lost.org.uk
--- Comment #52 from Chris Purnell cjp@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:
- 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.
- 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?