For a long time, I have been annoyed by a faint crackling that can be heard on the sound output of any DirectSound program when full hardware acceleration is enabled on the ALSA driver. Even after a patch I sent earlier (which corrected a bigger artifact), this crackling remained. Last night, I finally set upon removing this crackling, based on a comment in IDsDriverBufferImpl_GetPosition() in dlls/winmm/winealsa/audio.c, line 3302:
//* /*FIXME*/: snd_pcm_mmap_hw_ptr() should not be accessed by a user app. *// //* It will NOT return what why want anyway. *// hw_ptr = _snd_pcm_mmap_hw_ptr(wwo->pcm);
I thought, maybe it is not returning the correct information for GetPosition, so that is why the crackling exists, since new samples are off-position from what they should be in order to guarantee a smooth sound. So I deduced, maybe the IDsDriverBufferImpl object can keep a simulation of a hardware pointer and use that instead of the (slightly incorrect) hardware pointer. My original intention was to remove entirely the need to reference _snd_pcm_mmap_hw_ptr(), since this is obviously an internal alsa-lib function and should not be used from inside the app (as the comment rightly indicates). However, I found out that the simulated hardware pointer tends to lag behind the real hardware pointer, and horrible mixups happen if the difference approaches or exceeds the length of the mmap buffer. So the simulated pointer is loosely kept close to the hardware pointer in the supplied patch.
The good news: the patch sort of works (in my setup, at least, with Fedora Core 4). All the games I have (Japanese RPGs) now have smooth sound, unless the CPU load is too high. The bad news: the patch does nothing to make the dsound tests pass in Wine (but they were already failing before the patch :-)
What I would like to know is the following: * Is there any ALSA user for which the DirectSound tests have *actually* passed? In full acceleration mode? * Can somebody check if the DirectSound tests actually pass in Windows? The test code seems very straightforward, but (in my setup at least) they trigger many more errors and FIXMEs than my RPGs, and that is even without taxing the CPU with graphics and bitmap manipulation, as the RPGs do. * Can somebody using the ALSA driver acknowledge whether they have the crackling problem too, and whether this patch actually solves it for them too? * Can somebody please test this patch (even if they don't have the crackling issue) and check whether any previously working game breaks because of it?
Also, can some ALSA or DirectSound guru comment on the specifics of *why* the patch actually works? I am not entirely convinced that a mere loose updating of the simulated pointer from the hardware pointer is enough to have a smooth sound, but it works. I also don't understand how did the crackling appear in the first place, even though the direct hardware pointer was used.
Any comments or reports are welcome (especially why the patch works).
Alex Villacís Lasso
Changelog: * Remove crackling in DirectSound/ALSA playback with full hardware acceleration
Hello.
Alex Villacís Lasso wrote:
- Can somebody check if the DirectSound tests actually pass in Windows?
You can check it here: http://test.winehq.org/data/
Jacek
Alex Villacís Lasso wrote:
For a long time, I have been annoyed by a faint crackling that can be heard on the sound output of any DirectSound program when full hardware acceleration is enabled on the ALSA driver. Even after a patch I sent earlier (which corrected a bigger artifact), this crackling remained. Last night, I finally set upon removing this crackling, based on a comment in IDsDriverBufferImpl_GetPosition() in dlls/winmm/winealsa/audio.c, line 3302:
//* /*FIXME*/: snd_pcm_mmap_hw_ptr() should not be accessed by a user app. *// //* It will NOT return what why want anyway. *// hw_ptr = _snd_pcm_mmap_hw_ptr(wwo->pcm);
I thought, maybe it is not returning the correct information for GetPosition, so that is why the crackling exists, since new samples are off-position from what they should be in order to guarantee a smooth sound. So I deduced, maybe the IDsDriverBufferImpl object can keep a simulation of a hardware pointer and use that instead of the (slightly incorrect) hardware pointer. My original intention was to remove entirely the need to reference _snd_pcm_mmap_hw_ptr(), since this is obviously an internal alsa-lib function and should not be used from inside the app (as the comment rightly indicates). However, I found out that the simulated hardware pointer tends to lag behind the real hardware pointer, and horrible mixups happen if the difference approaches or exceeds the length of the mmap buffer. So the simulated pointer is loosely kept close to the hardware pointer in the supplied patch.
The good news: the patch sort of works (in my setup, at least, with Fedora Core 4). All the games I have (Japanese RPGs) now have smooth sound, unless the CPU load is too high. The bad news: the patch does nothing to make the dsound tests pass in Wine (but they were already failing before the patch :-)
Alex Villacís Lasso
Changelog:
- Remove crackling in DirectSound/ALSA playback with full hardware
acceleration
Reading through my own previous explanation, I realized that the original crackling problem lies in the fact that the hardware pointer is ahead of the proper position for mixing. So, if the hardware pointer is set back by a fixed amount before reporting in GetPosition, this crackling could be fixed without resorting to the simulated pointer hack. The attached patch does just this. It is an one-line fix, and solves the problem just as well as the original patch, without being as sensitive to CPU usage as the first patch. So please ignore the previous patch and use this one instead.
Alex Villacís Lasso
Changelog: * Remove crackling in DirectSound/ALSA playback with full hardware acceleration