I have looked at the Jack web page (http://jackit.sourceforge.net/)

It would help more if jack.h had more documentation for all api function,
and not just a few of them.

I have a particular application in mind, and was wondering how Jack would
handle it.
1) Audio and Video Sync

Here there is no requirement for low latency or synchronous execution.
The requirement is just that the app is told exactly how long it will be
between the next samples written to the driver, and
the sound actually coming out of the speakers.

How does JACK provide that sort of information, which ALSA currently
provides to the APP ?
I call this real-time, as it tells the app what is actually happening at the
speakers in real-time.

Cheers
James



> -----Original Message-----
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]On Behalf Of Paul Davis
> Sent: 14 January 2002 14:37
> To: Chris Morgan
> Cc: Christopher Morgan; [EMAIL PROTECTED]
> Subject: Re: [Alsa-devel] Alsa and the future of sound on Linux
>
>
> >[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 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.
>
> >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.
>
> --p
>
> _______________________________________________
> Alsa-devel mailing list
> [EMAIL PROTECTED]
> https://lists.sourceforge.net/lists/listinfo/alsa-devel


_______________________________________________
Alsa-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/alsa-devel

Reply via email to