>Nothing I said was new of course (as I tried to note several times), I >was simply trying to add my own enthusiasm to this topic. Perhaps you >didn't get that though, at least I gather from your response.
sorry about the tone of my response. days of grappling with the total fsck-up that is autoconf/automake, trying to finish the implementation of libgnomecanvasmm for gtkmm 2.0, worrying about how i was going to deal with cross-fading in ardour, bratty kids treating me a taxi driver and a lack of sleep has contributed to an-even-more-than-usual unpleasant tone in my voice. i apologize. its not necessary, and not helpful. >When I think of where Jack comes into the picture. I realize that it is >trying to accomplish a similar thing as LADSPA or aserver. That is, >streaming audio data to other applications. Now I know you have stressed >time and time again that you are going for sample sync, low latency, >standard floating point streams, but the overall object is the same. Not really. aserver, like esd and artsd before it, have been focused on simply bringing data streams together before delivering to an audio interface. at this time, there is nothing in ALSA to facilitate inter-process audio exchange, though the framework to write such a thing (in user-space) is certainly there and it would not suprise me if Abramo, Jaroslav or someone else adds this soon. However, as i hope my recent exchange with kai shows, when you start adding to the requirements of what you consider an acceptable solution, sometimes what you're actually doing is solving a different problem. as Kai has noted, JACK is really about building a synchronous execution engine. inter-app data exchange and sample sync operation possible are really just consequences of this design. if you start out saying that the goal is to share data, you will find (as evidenced by the available solutions) several different ways to get there. if you start out saying that the goal is to have a synchronous execution engine, the pathways change in important ways, and are a bit more constrained. >If we create multiple standards for the same desired effect, we are >going to be fragmenting application development. You have specified what the desired effect is. If its sharing data, there are at least 3 available solutions, and perhaps more if you include JACK as well as the audio stuff in GRAME's MidiShare. If you require synchronous execution, then JACK is the only functional or semi-functional solution. ALSA doesn't do this, and neither does anything else. This is why I like to focus on ALSA as the equivalent of CoreAudio's HAL. I love ALSA. I just don't think its the API that most programs should be written around unless it changes in some important ways (or rather, provides some simplifications), provides some new functionality, and encourages a certain kind of program design more actively. this doesn't seem like the role of ALSA to me, though i could change my mind about that. >hardware? An API that satisfies all our needs (or at least as close as >possible). but josh - what are those needs? 90% of the people who write "audio code" for linux couldn't give a damn about synchronous execution or low latency, if they even knew what those terms meant. Abramo has been correct to take me to task for rather narrowly defining what the acceptable solutions look like, and he's write in the sense that there are many users and applications which really don't care about this stuff, but still want audio interface sharing (for example), or believe that they want inter-app data routing without sync execution. i prefer to start from the most demanding set of requirements and work backwards from there. until ALSA provides inter-app data sharing, and until most/all ALSA native apps use a poll-based design, ALSA can't meet those requirements. so, to meet those specific requirements, a different API is needed, one that forces the correct design methodology on programs and provides inter-app data sharing so that this set of requirements can be met. then, i'm happy to work backwards to how we can fit less demanding requirements into the picture, and as far as i can see, aserver will do that perfectly well if and when it can talk to JACK. >How about integrating the ideals of JACK with LADSPA? They are both >constructed around the idea of networks of audio processing nodes. Could >LADSPA 2.0 be JACKed :) JACK is, in some ways, my own take on a certain version of LADSPA 2.0. a lot of what's in LADSPA has been stripped out because a JACK host doesn't want to know much about it clients and because ports are dynamically allocated rather than being something to lookup in a shared object. the work on in-process clients (the closest equivalent to LADSPA) is not finished, but it works for the driver-as-client case already. more fundamentally however, i think this is missing the point of what LADSPA was for. it was getting really silly seeing yet another delay implementation being written. LADSPA provides a lowest-common-denominator way to pack up common DSP algorithms and reuse them in many different programs. it doesn't deal with inter-process data sharing, and doesn't try to. things that implement LADSPA are not programs as much as algorithms with a discovery protocol wrapped around them. as such, i don't see JACK and LADSPA as being any more similar than, say, JACK and ALSA. >of moderation here. I don't want to see the audio world in Linux be >fragmented like the Desktop world is already becoming. The underlying >protocols should be standard, flexible and independent. heh. the classic response to this is "pick any two". i share your concerns, but i am not sure what can be done about them. there is no dictator to impose CoreAudio on everyone. we can do our best to provide solutions, advertise them, improve them, use them, but beyond that, this is linux, and people are, sometimes unfortunately, free to do whatever they want. --p -------------------------------------------------------------------- Linux is not the penguin. Linux is the smile on the penguin's face. _______________________________________________ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
