>What Paul is voting for is to have just one "protocol" (at least for now), >so we can drop the need for B and magically A turns (with some additional >static cruft from the missing B) out to be LAAGA (or whatever). > >Richard is voting to have both APIs to allow maximum flexibility.
As insightful as always, Richard. But one additional note: I am not blind to the flexibility in Richard's LADMEA suggestion. I merely claim that for the design goals of JACK, the flexibility is at best unnecessary and at worst a hindrance. JACK doesn't claim to offer the same kind of API as say, alsa-lib. We constrain the clients to make life easy for the clients. For clients that want to stream raw MP3 data to another port that handles floats, I think its preferable for them to call "mp3_to_float()" from a handy library than it is to require that there be *implicit* data conversion in the interconnect. The other alternative - allowing a user to connect things up with "adapters" - seems too much work for most users to bother with. Requiring a single data type makes everyone's life easier, at very little cost to the vast majority of relevant applications. Don't tell me that GLAME is using integers while mixing internally ? :)) However, as I pointed out yesterday, and as Richard himself notes, there is no particular problem imagining an API with more flexibility like LADMEA "containing" "exchanges" like JACK. >I'm just fearing that while there are those two basic fundamental >APIs they're going to be hidden and crippled by any of the suggested >implementations. > >So please - go the easy way, drop the need for B, but _dont_ intermix >A with the resulting API (so you can add B later without lots of hassle). Do see any ways in the existing JACK API that does this? What are the grounds for your fears? --p
