Robert Reif wrote:
Con Kolivas wrote:
On Wednesday 05 April 2006 09:45, Robert Reif wrote:
One problem that I am seeing is that there is no practical way to guarantee synchronization between the sound card hardware and the sound card thread. OSS doesn't support poll/select reliably in all drivers and the esd driver just writes to a socket. We try to synchronize to the hardware by using a one-shot timer set to the expected processing time calculated from the sound card data format. The problem I see in the esd driver is that we set a timeout to poll of for example 12 ms but what we really get is is a 20 ms sleep. We compensate for this by sending as much data as we can. Using virtualized hardware like alsa dmix just removes us even further from the hardware we would like to synchronize to by blocking.
Apart from legacy, is there a reason you haven't moved en-masse to alsa? It is the only supported driver in current kernels now. Talking to oss, the oss compatibility module or worse through a sound driver like esd, arts, gstreamer, jack... etc just adds more potential for desynchronisation.
Cheers, Con
In my case, legacy is very important because my employer specifies for example a stock RH7.x or RH9 system. Periodic sleeping works fairly reliably with real OSS and all the other drivers are spinnoffs of this design. Moving to a better designed driver using ALSA is the way to go but unfortunately it's not an option for me.
Although I have ALSA in my kernel, I also use the OSS compatability, and on top of that, use more regulary than ALSA directly. I use OSS in Wine cause the WineALSA driver is fustrating, and wants odd settings (something about DirectSound emulation -- I don't get it)
I can use ALSA if I need to, but I prefer the working legacy API