[pulseaudio-discuss] PulseAudio/alsa_plugins bugs without Wine

[Joerg-Cyril.Hoehle at t-systems.com]

Hi,

For the last six month, I've spent an incredible amount of my time fighting bugs
related to audio with Wine.  These days, it turns out that there are known bugs
remaining in Wine components, however a constant number of bugs involves
PulseAudio -- or the Pulse alsa_plugin, which I do not distinguish.

Instead of crawling through user logs, I've written some trivial tests apps myself -- running
outside Wine -- and can observe bugs that explain what people observe. So far, as I've
been using somewhat old versions of Ubuntu (Intrepid and Lucid) and not the latest PA, I've refrained from
posting bugs to PulseAudio's bugzilla.  However, time passes by, users of newer releases
of PA on Ubuntu and Fedora keep seeing the same bugs again and again and I'm left
wondering what can be done to improve the audio experience on Linux.

These are the Ubuntu package versions of pulseaudio:
http://packages.ubuntu.com/search?keywords=pulseaudio&searchon=names&suite=all&section=all

Here are a few things that I've observed, playing with tiny programs (I can provide
source if you can read Common Lisp). I'd be *very* interested if you know these
symptoms or can suggest work-arounds.

a) Ubuntu Lucid never enters XRUN state like hw:0 or dmix do, given the same
parameters. I've been using stop_threshold = alsa_buffer_size.
The older Ubuntu Intrepid worked better.
(one PA bug report says sw_params are unsupported except for start_threshold?)

b) After snd_pcm_pause, avail_update suddenly returns results doubled, i.e.
as if the buffer size had doubled.

c) After an underrun and a sequence of snd_pcm_recover/drop/reset/prepare,
avail_update initially returns alsa_buffer_size.
So far so good, but as soon as I start writing, avail_update grows beyond buffer_size
and produces values that continue the growth from before the underrun, as if
no reset/recover ever took place. avail then grows way beyond buffer size.

d) Sometimes, I don't know what triggers it, no sequence of
snd_pcm_recover/drop/drain/prepare/reset manages to have PA/ALSA produce avail&delay
values that look sane, like in the first run after snd_pcm_open. I need to do snd_pcm_close
and a new snd_pcm_open.

e) Sometimes, I don't know what triggers it, snd_pcm_open is not enough.
Only restarting the pulseaudio daemon helps.

f) At one time I was led to believe that the post-underrun sequence
snd_pcm_prepare + drop + prepare helped PA recover reasonable values
of avail&delay, then that trick did not work anymore at all.

g) Past ac underrun + recover/prepare situation, writing data despite bogus values of
avail_update succeeds to some extent, but produces weird effects: Some writes produce
no sound, then after some more, suddenly a cascade of sounds is played.

Now this is a snippet of misbehaviours observed when writing simple Common
Lisp programs that use the safe subset of ALSA AFAICT.
snd_pcm_open NONBLOCK
snd_pcm_set_hw_params_rate/channels/... typically 8000x8x1
snd_pcm_set_hw_params period_near, buffer_near
snd_pcm_set_sw_params start/stop_threshold
snd_pcm_avail_update, snd_pcm_delay, snd_pcm_write.
snd_pcm_prepare/drop/reset
No snd_pcm_rewind or forward
A Linux laptop with on-board Intel sound.

What am I doing wrong? I read PA's Wiki about Troubleshooting,
known incompatibilities etc., but no kernel SCHED or RT bits or similar
misconfiguration in Ubuntu can IMHO explain the above.

Wine is not involved at all in my tests, but from what I read in Wine bug reports, the above
selection of bugs looks a lot of like what Wine users experience:
- need to reinitialize audio from within the application
- need to restart PA, 
- sound dying after an underrun or at random times

You may wonder why I talk so much about underrun recovery.  This is an essential requirement,
as system load or simply the end of a song may trigger underrun situations.

Now the question is, how can the situation improve?
I would like to see sound work equally well with the plug:dmix or PA front-ends.

Thank you for your help,
 Jörg Höhle