>I'm not sure if I understand why this would help to position jack as the
>standard linux sound server.  It seems like we need to get some kind of
>discussion going between arts and jack developers as arts is in the position
>that jack would like to share.  No doubt that jack has something to offer in
>terms of lower latency.  Since you are the primary developer of jack, what do
>you think?

like i said, linux is not an environment where we can force anything
on anyone. artsd does quite a lot more than just provide
approximations of JACK's features.  those additional features
apparently made it attractive to the people that have adopted it. it
would be really very difficult to get artsd to support the JACK API
because artsd is another app that uses read/write to schedule
itself. i've discussed the issues involved with the author of arts
several times, and i really can't see it happening.

i am also not clear that the GNOME or KDE people would be willing to
support an audio API that requires multithreading.

also, JACK is not finished yet, which is a major problem. i think that
a finished JACK API, with latency and CPU load performance at least as
good as CoreAudio, plus a half dozen significant and extremely useful
applications will persuade people much more than any of these
technical arguments.

however, don't let any of this stop your advocacy. its always been my
role in life to explain why things won't work, and then end up
somewhat suprised when they do.

>I wouldn't mind working on some documentation or an example command line jack
>wave player(if such a thing doesn't already exist).

it exists. andy added JACK support to his excellent alsaplayer several
weeks ago (it has both command line and GU interfaces), and plays all
kinds of things (mp3, many sound file formats, etc.)

--p

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

Reply via email to