http://bugs.winehq.org/show_bug.cgi?id=28622
--- Comment #41 from Jörg Höhle hoehle@users.sourceforge.net 2012-03-07 03:51:41 CST --- Hypothesis: although PulseAudio/alsa_plugins accepts a 10ms period, it is unable to cope with it.
Gilboa, this is your working package:
- in dlls/winealsa.drv/mmdevdrv.c: Initialize, add a multiplier: http://source.winehq.org/source/dlls/winealsa.drv/mmdevdrv.c?v=wine-1.4-rc5#... alsa_period_us = 3 * This->mmdev_period_rt / 10; 3 for 3*10ms, later try 5, 7 or even 12.
- in the same file, change TRACE about XRun pad in alsa_write_data to WARN. Perhaps too the "frames written:" line in GetPosition. With WINEDEBUG=warn+alsa,+timestamp, this will show the important lines without the flood of the full +alsa log.
- Optionally, apply my patch winealsa: Do not hardcode the ALSA buffer size to 4 periods http://www.winehq.org/pipermail/wine-patches/2012-February/111617.html
This will allow to easily play with the ALSA buffer size by setting BufferPeriods. I've used values from 2 to 30. Overall, both will have an effect on the lead-in, i.e. the number of samples that we prefill into the ALSA buffer. You may also play with EXTRA_SAFE_RT.
- Run the render test and listen to sound. On Ubuntu Lucid: o crackling disappears when using a period >= 30ms. o pad:1 can be constantly reported, but that doesn't matter for crackling; o snd_pcm_delay/GetPosition is too slow to indicate a real speaker position, but that doesn't matter for crackling. This causes a variabe amount of test failures, but doesn't matter for crackling in the XAudio2 scenario. o PA appears to drain the buffer using a period from 120-300ms.
- Play with the values. The larger you make them, the more latency you'll introduce, as PA will end up buffering over a second of audio data. Larger latencies will cause more and more problems with winmm and DSound. Try to find a good compromise. pad: >1 in the log is actually not good, as it means that PA's huge internal buffer is already full and PA continues to grab frames that start to fill the ALSA buffer visible to us.
period * 3 and the default BufferPeriods prevented crackling in my limited testing.
- In dlls/mmdevapi/tests/render.c, try frequencies other than 48000 in test_worst_case. Change nSamplesPerSec as in test_formats. Don't forget to update nAvgBytesPerSec as in: http://source.winehq.org/source/dlls/mmdevapi/tests/render.c?v=wine-1.4-rc5#... Here the goal is to assess whether the period + buffer pair you choose above also works when PA's resampler has to process other rates.
I've not assessed the stability of using a larger period, e.g. what if playing for 10000 seconds in test_worst_case. PA is(was?) known to loose sound after some time and need and restart here and then.