From: Paul D. <pa...@li...> - 2005-04-15 19:47:31
|
>The only broken client I know about for sure is JAMin. But, I expect >it is used by more than 1% of JACK users. Breaking it will probably >affect at least as many people as were inconvenienced by freewheeling >problems under Linux 2.4. the design before this change is simply wrong. thats one of the many reasons why JACK is still at 0.99 and has not yet reached 1.0. we are not going to freeze the API in a broken state. if the current design was correct, the issues with freewheeling would not have been lingering around like a fly buzzing in the back corner of a dark closet. >Existing versions of JAMin will work correctly (after recompilation) >if jack_create_client() is undefined. But, you made the mistake of >changing the function prototype without changing its name. That it wasn't a mistake, it was a conscious choice. i want to break existing clients that were using this function because it does not and cannot work in the way that i think it should work. clients that use jack_create_thread() are creating threads that cannot relinquish and reacquire RT scheduling. this may seem minor given that they will likely not be participating in any freewheel activity (though they may well do so). i don't consider it minor. i think that any RT thread within JACK must be able to do this with no issues. >This whole change is poorly timed and something of an overreaction. at some point recently, i was getting 1-2 bug reports every week from people who exported with ardour and then had terrible behaviour from JACK afterwards. providing a feature (freewheeling) that inevitably leads to poor performance for no apparent reason is not a good idea. >Introducing binary and source compatibility surely does more harm than >good. It's going to take us at least another month or two to smoke >out all the other problems inadvertantly introduced by this fix. what you seem to have failed to notice is that for months, JACK has been reliant on a function that already embodies 90% of what this fix does. jack_acquire_realtime_scheduling() has to work, or a number of things will fail. all the cruft that was in jack_create_thread() was there because we adopted the wrong priviledge model (parents granting children scheduling classes etc). >Meanwhile, there are significant JACK enhancements that will not be >widely available because of it. We have not done a new release of JACK for months when we could have. Even if this takes another month, which I seriously doubt, its really no different than the status quo that we've lived with for a while. If you really want to burden the API with "jack_create_thread()" and jack_create_thread_legacy()", i am not opposed to that, but i think its a mistake. the broken one would need to be removed for 1.0 anyway, which is not far off according to most perspectives, i think. --p |