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
