[Bug 28622] alsa under pulseaudio no longer produce sound

[wine-bugs at winehq.org]

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

--- Comment #32 from Jörg Höhle <hoehle at users.sourceforge.net> 2012-03-04 15:10:43 CST ---
>Tried using winecfg to select another device (instead of default) - no go.
If we want to make progress, you must be very precise.  What does no go mean?
No sound at all from any device?  Did the AUDDRV_GetAudioEndpoint line in a
WINEDEBUG=+alsa log show that the requested device was opened successfully?

>I'll update second render log w/ PA 1.1 and Audigy 2 later today.
Ok, but what did you hear from the render test? Occasional crackling?
Continuous crackling? No sound at all?

>Please, please, please don't break pulse.
It is not our intent at all. I've spent hours, evenings, week-ends and nights
trying to figure out a way to make PA produce sound reliably. I failed. Even
simplest programs (without Wine) managed to see the PA server lose its ability
to play any sound from any program. Here's one bug I posted to PA's bugzilla:
https://bugs.freedesktop.org/show_bug.cgi?id=46296
PA is one of the reasons that I'm still using the now unsupported Ubuntu
Intrepid (there you can easily switch it off) and nothing newer. During the
last months, Wine cleaned up its useage of ALSA a lot. I now have a feeling
that it's PA's turn.

Let's have a look at the render.log:
>19.114:0026:trace:alsa:AUDDRV_GetAudioEndpoint Opening PCM device "default" with handle_underrun: 0
The handle_underrun shows PA is being used.
>19.124:AudioClient_Initialize ALSA period: 480 frames
>19.124:AudioClient_Initialize ALSA buffer: 1920 frames
>19.124:AudioClient_Initialize MMDevice period: 480 frames
>19.124:AudioClient_Initialize MMDevice buffer: 24000 frames
Nothing unusual
>19.124:AudioRenderClient_ReleaseBuffer (0x12fcf0)->(24000, 2)
This is the first place in the log where something is going to be played.
>19.124:AudioClock_GetPosition snd_pcm_delay failed in state 2: -5 (Input/output error)
That is known from PA when it has not started yet, harmless.
>19.124:AudioClient_Start (0x12fcf0)
>19.124:alsa_write_data pad: 0
Here the first snd_pcm_write occurs
>19.135:alsa_write_data XRun state avail -32, recovering
... and 11ms later, ALSA signals us an underrun...
>19.149:alsa_write_data XRun state avail -32, recovering
... from which it never recovers. The rest of the log looks like the render
test never managed to play a single tone.

To me it looks like PA with alsa_plugins is unable to produce the values that I
come to expect from a good ALSA citizen. In particular, after writing at least
1152 frames (24ms) into an ALSA buffer, I don't expect an underrun 11ms later.
That is a bug with either PA/alsa_plugins or Fedora, not Wine, so I'd like a
comment from these people. Hence you or I must open a bug on their side.

>I restarted PA manually on two machines, one of Intel-HDA and the other with
>Audigy 2, tried VLC and got the same results.
It's really puzzling that you get no sound on 2 machines. If it were only one,
I'd say that Raymond is right to highlight the hw parameters.  Perhaps
PA/alsa_plugins does not manage to cleanly separate the device's Xms period
from the 10ms period that it gave us? If it can't cope with it, PA should not
grant a 10ms period on that HW. Wine will be able to cope with a 200ms ALSA
period.

That's why again, I'd like to see you select every possible device in winecfg,
repeat the render test every time, listen and inspect the log to see whether
GetAudioEndpoint etc. were successful or not and what parameters ALSA delivered
-- even if using the low-level devices means that PA should be inactive for the
duration of the tests. Be aware that there are multiple occurrences of
GetAudioEndpoint in a render.log.

Another thing to check is to have dlls/winealsa.drv/mmdevdrv.c:
make_handle_underrun_config do nothing by inserting:
    return NULL;
above snd_config_update().

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