>Since I have hardly looked at Jack, and definately not tried to use it (as a >developer) I can't really comment on the design.
but you still say: >- harder to understand "what" goes "where", J�rn has made some >nice schemantics but the design is rather complex, a novice would not >understand it. that diagram isn't intended for the novice or the user. its intended for the interested application developer. either comment on the design or not. you think a novice is supposed to understand how something as complicated as the back-end of this works? its been one of trickiest pieces of unix system programming i've done, and i've been a unix system programmer for 17-18 years. no, the novice is supposed to understand how *easy* JACK is to use when developing application software and how much *power* it provides to the user. >Is there a contradiction between Jacks design and potentially >merging it INTO ALSA-lib ? I mean, without changing the design? Depends on who you talk to. Abramo believed it could be done, but proceeded to suggest an entirely new API to include in alsa-lib that would hide the existing one. Many others on the list thought it couldn't be, and that the right relationship was to have an API such as JACK *use* ALSA but not try to be a part of it per se. With the recent addition of a Solaris client/clock-driver, that design has been vindicated. >- applications need specific support applications need basic redesign, and then they need a tiny amount of code to make the new design work with JACK and/or CoreAudio and/or PortAudio and/or .... --p
