>Our app does not use poll or anything like it. It does not get woken up by >the audio device.
actually it does. but not woken up from poll, just from snd_pcm_write. >Look at our source code. i did. i downloaded xine a few weeks ago. xine won't work the way a user expects if anyone tried to get it to inter-operate *in sync* with another application. computing an application-determined-sized chunk of data and delivering it to the audio interface is a sure fire way to destroy sync as well as responsiveness to user controls. not that your code is alone in doing so, of course - its been the way Unix audio apps have been written for years. the audio interface is the only thing that knows how much data you should be generating at any one time. the only case in which you can get ahead of the interface (i.e. rely on the driver to buffer) without any effects is when there are no real-time controls that might affect the data (aplay would be an example of such a program). xine has a volume control, at the very least. i haven't studied the source code enough to see if there are other examples of things that make this kind of "pre-generation" questionable. --p _______________________________________________ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
