i810 audio fixes 1/2

Paul Davis paul at linuxaudiosystems.com
Thu Apr 22 13:38:09 CDT 2004


>On Wed, 21 Apr 2004 21:06:22 -0400, Paul Davis wrote:
>> if the freedesktop people have any intent of avoiding a split between
>> the music world and the "desktop beep" world, JACK is the only viable
>> sound server. if they don't care about such a split, then neither do
>> most of us in the music/pro-audio world.
>
>Obviously if possible such a split could be avoided, but the ultimatum
>seems to be: use JACK or there will be compatibility. That's fine, but I
>thought that JACK was Linux only (as is alsa, for that matter), so we lose
>the sound-server-as-abstraction-layer properties of esd and arts.

JACK runs on OS X (and is proving very popular there). It is written
in strict ANSI C and attempts to be strictly POSIX compatible. There
is an OSS-API driver enabling it to be used on Solaris (at least).

JACK is a *much* higher level of abstraction that artsd or esd. There
is no sample format negotiation, in particular. And this is the really
hard part. Chris Morgan and I were talking about this privately last night.

>The other issue is - what about X sync? Do you agree with Alan Cox that X
>has to handle audio as well to make it work? If so that raises some
>fundamental questions about our audio architecture.

Alan doesn't know enough about this :)

Any time you have 2 reference clocks, you have sync problems. It
exists even when audio + video are done on the same system with or
without X. The clocks have a different notion of what "1 second" is,
and so the streams they control drift. Whether you have to correct
over a network, or just within a single app, you still have to correct
for this. Alternatively, you can choose 1 of the two clocks as the
master, or you can allow a 3rd party to control them both.

Audio is not like video for sync+real-time-ness. The human visual
system will not notice duplicate video frames, and most of the time it
will fail to notice skipped video frames. The auditory system,
however, will instantly hear any missed or duplicated audio as a
click. This means that the requirements for real-time/callback driven
audio are harder to meet and generally need to dominate over
video. Unfortunately, video is considered the important item, and so
audio ends up taking a back seat.

X could add new event type, "ProcessAudio" which would be driven by
the audio clock on the host side. It would a similar model to JACK,
but clouded by priority issues alluded to above. Audio has to flow
independently of GUI/video stuff; thats why all "real" audio apps do
audio in a dedicated thread, and why JACK enforces that design.

>Random observation - that location of policy  (in clients) sounds a lot
>like X. Would it be theoretically possible to merge jack with the X
>server, or am I smoking crazy weed?

Its not unimaginable, no.

--p



More information about the wine-devel mailing list