On Thu, 22 Nov 2001, Paul Davis wrote:
> >Using callbacks is a bit unuseable in the unix systems, because it doesn't
> >allow multiprocess communication. Using RPC has same cost like poll,
> >so I don't see any benefit here.
>
> also, just to be clear: sure, there's still poll(2) involved. the
> point is not that its cheap (this is what Abramo and I disagreed about
> originally, and he turned out to be right - its cheap *enough* for
> many things), but that it encourages/enforces program design
> that allows desirable things to be done.
>
> i spent some time last week porting a nice little app called RythmnLab
> to use JACK. it used the same kind of design that so many linux audio
> apps do - blocking reads and/or writes on the audio device. this
> approach just can't be used for low latency sample sync'ed
> performance. its precisely this goal that is so important to the
> Windows/MacOS proprietary s/w developers these days, and it should be
> for us as well, IMHO.
I still don't understand the difference. Seeing jack code, there is
nothing new. You are using threads, shm for multiprocess communication
and callbacks for the final communication between the application audio
code and arbiter client. Can I see the global JACKs scheme which beats
this scheme?
Here is our scheme for share and future mix plugins / aserver:
<audio stream producer> -> <shm sender & poll> -> <arbiter & poll> ->
<final point - audio device or other consumer & poll>
Note that alsa-lib covers the <shm sender & poll>.
I have a strong suspect, that the JACK engine is only some pre-cache
tool which can be solved using bigger ring-buffer. I think that the
global serializing and parallelizing scheme can't be avoided or changed
in the audio dataflow.
Yes, I know that many audio software developers (I must admit that
I can count myself there, because aplay/arecord and the pcm test utility
uses standard blocking scheme) waits directly to stream and don't use the
meantime to prepare new samples (I'm refering here managing file I/O or
generating new samples) for the ready event.
Jaroslav
-----
Jaroslav Kysela <[EMAIL PROTECTED]>
SuSE Linux http://www.suse.com
ALSA Project http://www.alsa-project.org
_______________________________________________
Alsa-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/alsa-devel
