[Bug 28622] alsa under pulseaudio no longer produce sound

[wine-bugs at winehq.org]

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

--- Comment #41 from Jörg Höhle <hoehle at 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#L1013
     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#L397
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.

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