>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