[Bug 28622] alsa under pulseaudio no longer produce sound

[wine-bugs at winehq.org]

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

--- Comment #34 from Gilboa Davara <gilboad at gmail.com> 2012-03-05 00:47:34 CST ---
Created attachment 39202
  --> http://bugs.winehq.org/attachment.cgi?id=39202
Render test on Audigy 2 (default, multi-channel w/PA, multi-channel w/o PA)

(In reply to comment #32)
> If we want to make progress, you must be very precise.  What does no go mean?

(Sorry for giving partial information)
Selected the actual device "Audigy 2sz" and "Intel HDA" instead of "default".

> Ok, but what did you hear from the render test? Occasional crackling?
> Continuous crackling? No sound at all?

A 5 second long cracking.
... Then short clicks ~10-15 seconds apart.

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

I understand the frustration. As a long time Fedora user, I took me ages until
I got Pulse to work reliably on my machine.
Have you considered trying to contact Lennart Poettering himself? At least in
my experience, he's very cooperative.

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

OK.
The reason I find the all thing odd, is that both Intel HDA and Audigy 2sx
exhibit the exact same behavior under wine, but not under other alsa-plugin
applications.
Granted, wine use-case may be exercising different code-paths compared to say,
Flash player.

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

Again, the title of this bugzilla is misleading. ( I tried changing it but I
was requested to revert the change ).
I get highly distorted sound, full of crackling and clicks. (Enough so the
original wav cannot be identified).

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

On the Intel HDA, selecting "Intel HDA" instead of system default, produced the
same results under winecfg sound test - crackling sound.
On the Audigy 2, selecting "Audigy 2ZS - Multi-channel" didn't produce sound or
produced the same distorted sound.
However, when I killed pulse and used the same winecfg configuration ("Audigy
2zs - Multi-channel") the render test gave me 90% clean sound with some
crackling.

Either way:
3 files attached:


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

OK, I'll try and free some time to build wine by hand w/ the suggested change.

- Gilboa

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