Hi, David Henningsson wrote: >I'd think that wine is a big enough project to justify a pulseaudio driver Wine may have a very large user base, but if you look at who regularly contributed code in the audio area in recent years, you'll find 2 names: Andrew and mine, with Maarten and Eric in past years. What I want to see happen is for the PA + alsa_plugin combination to deliver its promise of seamless integration with ALSA, i.e. be able to use standard ALSA calls. IMHO it is not acceptable should PA ask every app to write a backend using its own API. The avail>buffer_size appears to be a bug in the alsa_plugins, given that it persists after disconnecting from PA. The "need to restart PA to recover any sound" bug that people report can only be a bug in the PA server. I'm sorry I've not written a C equivalent of my trivial CLISP FFI code, nor do I have any machine with the latest PA -- the most recent one is running Ubuntu Lucid. Do you believe posting the Common Lisp code to the PA bugtracker would help? It really is nothing more than: 1. open and setup hw_params + sw_params, e.g. 8000x8x1 2. snd_pcm_prepare 3. snd_pcm_write a little, e.g. 600 frames 4. print snd_pcm_state, avail_update & delay 5. sleep 5ms 6. go to 3 a dozen times 7. print snd_pcm_state, avail_update & delay 8. sleep 5ms 9. go to 7 at most 50 times or until avail < 0. 10. sleep some seconds 11. snd_pcm_recover 12. add any mix of snd_pcm_reset / drop / prepare 13. go to 3 half a dozen times. The rest is manual analysis of log output. It is *very* revealing*. For instance, sometimes snd_pcm_delay freezes for 30ms, then works again as one would expect, continuously decreasing. You may run that playing silence and observe the broken values of avail_update. You may also play a tune and check whether audio output matches your expectations. Regards, J?rg H?hle
