[Bug 28622] alsa under pulseaudio no longer produce sound

[wine-bugs at winehq.org]

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

Jörg Höhle <hoehle at users.sourceforge.net> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |hoehle at users.sourceforge.ne
                   |                            |t
          Component|-unknown                    |winealsa.drv

--- Comment #27 from Jörg Höhle <hoehle at users.sourceforge.net> 2012-03-03 02:31:46 CST ---
Am I wrong or is Fedora involved with every PulseAudio bug in Wine, e.g. bug
#28856?
Maybe it's time for a bug in their bugtracker?

>AUDDRV_GetAudioEndpoint Opening PCM device "default" with handle_underrun: 0
That line proves PulseAudio is being used. Let's have a look.

>AudioClient_Initialize ALSA period: 441 frames
>AudioClient_Initialize ALSA buffer: 1764 frames
>AudioClient_Initialize MMDevice period: 441 frames
>AudioClient_Initialize MMDevice buffer: 4410 frames
Quite normal.

>AudioClient_Start (0x147528)
>AudioClock_GetPosition frames written: 4410, held: 4410, avail: 1764, delay: 0 state 2, pos: 0
>AudioClock_GetPosition frames written: 4410, held: 3087, avail: -32, delay: 1321 state 4, pos: 1323

That's the point where experience with other bug reports tells to restart the
PA server.  Why does even the first write (of 30ms, 1323=3*441 frames) result
in a underrun (EPIPE=-32)?

The underrun makes winealsa believe that all written frames were played,
raising position to 1323.  This is different from the following well-known
transient error where PA returns EIO=-5 when too little time has elapsed after
the initial write, so winealsa keeps the position as is:
>AudioClock_GetPosition frames written: 24534, held: 0, avail: 1763, delay: 1057 state 3, pos: 23814
>alsa_write_data XRun state avail -32, recovering
>AudioClock_GetPosition snd_pcm_delay failed in state 2: -5 (Input/output error)
>AudioClock_GetPosition frames written: 24534, held: 0, avail: 1764, delay: xx state 2, pos: 23814

If you wade through the log where winmm was used 3x to play a ~1/2 second
sound, you'll see that winealsa almost constantly got avail: -32.  IOW,
winealsa played nothing.  There are rare exceptions:
>AudioClock_GetPosition frames written: 24534, held: 0, avail: 1763, delay: 1057 state 3, pos: 23814
Even that looks strange.  Why is avail 1763 and not the full buffer size 1764?
This is an off by one thing that I've observed with my ancient 0.9.x PA from
Ubuntu Intrepid already.  Perhaps resampling and rounding constraints in PA can
explain it?

So normally, I'd dismiss such a situation as yet another PulseAudio bug. 
However:
>Outside of wine, sound works perfectly under both multimedia applications and
>SDL and openal games.

I fail to see what Wine does wrong.  One last idea: In
dlls/winealsa.drv/mmdevdrv.c:alsa_enum_devices, please comment out the for loop
involving snd_card_next.  Then only "default" (if you added nothing via the
registry), no "plughw:N.N" will be acccessed.  Does    that change anything?

Also, may I suggest as work-around to use winecfg to have winealsa use the
low-level "SB Audigy 2 ZS" or "HDA Intel" for output?  This may prevent other
apps from doing output concurrently, but might give you working sound in Wine.

If you need to post another log, I recommend our render tests:
cd dlls/mmdevapi/tests; rm /tmp/render.log
WINETEST_INTERACTIVE=1 WINEDEBUG=+tid,+timestamp,+alsa,+mmdevapi wine
 mmdevapi_test.exe.so render >>/tmp/render.log 2>&1
with winecfg or the registry set your preferred device (if not "default").

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