Segin segin2005 at
Tue Apr 4 20:42:13 CDT 2006

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

More information about the wine-devel mailing list