On Mon, 14 Jan 2002, Paul Davis wrote:
> >[snip]
> >> what you're missing is that high end applications need *two* things:
> >>
> >> 1) low latency
> >> 2) synchronous execution
> >>
> >> the latter is extremely important so that different elements in a
> >> system do not drift in and out of sync with each other at any time.
> >>
> >If it is possible to have an audio server that would satisfy the requirements
> >of high end applications it should also suit applications that just want
> >sound to add to the ui.
>
> thats fine. the problem is this: if you require that the "add sound to
> the UI" apps use the same API as the "high end ones", people writing
> the former category of apps have to adapt to a callback-like
> model. they will likely find this quite hard. If instead, you allow
> them to use ALSA's HAL-like model (which can be done reasonably easily
> by using something like the ALSA "share" server to mediate between
> ALSA and JACK), then you continue to have two different APIs with all
> the problems that implies.
>
I'm not at all sure why the callback mechanism is such an issue. Windows uses
callbacks for their standard sound layer as well as with DirectSound. I'm not
sure why the callback model is so difficult to incorporate into an application.
> >> i don't mean to sound harsh, but this is naive. there is no agreement
> >> among any of these groups on what they want. ALSA *is* a standardized
> >> API that is equivalent, roughly speaking, to the HAL layer in Apple's
> >> CoreAudio. if people are willing to write to a HAL layer, ALSA is the
> >> "basic standardized API" you're describing. but IMHO, thats not enough.
> >>
> >I'm curious as to what you would propose be done about the current state of
> >sound under linux. I'm certainly not the only one willing to help work(code
> >etc) to reach the goal of making a more unified and more suitable sound
> >architecture under linux. Something should be done sooner than later as from
> >a deverloper standpoint things are quite confusing.
>
> as i've said several times: i don't think there is much that can be
> done except producing working systems with such impressive performance
> and capabilities that people recognize them for what they are, and
> decide to start using them. we cannot make things more unified under
> linux - just take a look at GNOME and KDE: there is absolutely nothing
> to stop the same kind of fracture in the audio realm (and in fact,
> developers of these environments are contributing to that very thing).
>
> the particular system that i am working on (with help from kai, andy
> wingo, jeremy hall, richard guenther and others) is JACK, and if you
> want to help out, please do. but as i said before, the API JACK
> presents is unfamiliar to most people working with audio under Linux,
> and there is likely to be much resistance to it, despite the many
> benefits and enhanced portability it offers.
>
After looking at the jack.h header file and at the api I'm surprised that the
number of api functions is quite low and seems pretty easy to understand. I
don't think is is unrealistic to think that linux could move to a standardized
sound server, or at least a standardized api which would allow for jack and
other sound servers to compete on a technical basis. This is just something
that would benefit all linux users. People like yourself know a lot better
than I about what would need to be done to further the goal of having a
standardized api for sound servers and moving towards a sound server that would
suit high end apps while not making it too difficult for low end apps. It
really is time that something was done. What can I do to help?
> >Interesting. I'm unfamiliar with CoreAudio although if it is technically
> >superior and fullfills requirements then we should look to mirror its
> >capabilities.
>
> that's what JACK is all about (except that the ideas behind JACK
> predate CoreAudio's appearance). CoreAudio has been measured as
> technically superior in terms of latency to any other audio API. JACK
> (with ALSA as the HAL layer) came second.
>
Where can these comparisons be found btw?
> --p
>
Chris
_______________________________________________
Alsa-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/alsa-devel
