Implement THREAD_PRIORITY_TIME_CRITICAL
Segin
segin2005 at gmail.com
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