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§ion=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