Re: [LAU] A year of Linux Audio revisited - would like to know your oppinion

On Thu, 2007-12-13 at 21:57 -0800, Robert Persson wrote: No, the problem here is that you comments are midway between a technical user and a completely new user. You have opinions about the nature of the user interface, specific features you think the system should have, and ideas about what matters with respect to its adoption for specific kinds of work, but at the same time, you want to plead "i am not a programmer" etc. Rather than simply observe behaviour and say "this doesn't work for me" or "this breaks the following workflow", you chose to get into the details of "this is how to fix jack". your assumption is that since you know what appears to be broken, you also know what needs to be fixed. this might seem like an obvious corollary, but i can assure you that afters years of writing software, it simply isn't true. I don't think, as you claimed, that you are being thoughtless in posting what you did. But I am also not being disrespectful in my response. So, lets go over it again: 1) the problem with JACK configuration is, to the best of my knowledge, ALWAYS caused by either incorrect system configuration (i.e. no authorization for the user to user realtime scheduling or memory locking, in turn caused by incorrect setup or the wrong version of PAM or its equivalent) OR by the use of specific hardware that requires different defaults than the ones JACK picks on its own. Problems in the first category are NOT solvable by JACK - they can only be solved by distributions (or users if they want to try it). Problems in the second category: well, here is where JACK could maybe do a better job and automatically pick a better set of defaults. However, at this point this is hard to do - there is no simple way for us to identify which hardware requires different values. So, once again, this is a problem that doesn't lie entirely within JACK's domain. It is also not clear to us that 2) latency configuration - when JACK was designed, we understood that for a number of applications, responding to changes in the buffer size would be difficult. we also understood (perhaps incorrectly) that most users did not need to do this. as time has gone by, and people have grown comfortable with JACK and/or a new set of users with different workflow requirements, a different perspective has crept in. JACK has the technical ability to alter the buffer size on the fly, and most clients will handle it. However, most *control* applications do not provide a way to do so. Is this an error in JACK? If you see JACK as a finished ecosystem that should just work for the user, then sure. If you see JACK as a technology that can be used in a number of different ways, and allows different control apps to be created for it, then not really. me too. but this can't happen in the way that a lot of people expect. there is no dictator of linux audio. this is no like apple, where they could say "CoreAudio is the API you will all use, now get busy". linux audio, perhaps for better and perhaps for worse, is a ragtag collection of individuals, APIs, technologies etc. its not some uniform, unified, cohesive system, which is simultaneously its biggest strength and its biggest weakness. That's correct. But blaming JACK for not working properly is an obstacle for us. JACK developers do not control the full context in which a user uses JACK. If we did, JACK would Just Work (TM) for everyone. But we don't, and its a problem for us when every single day on IRC i hear from users like you who expect JACK to work, find it does not, and blame JACK. If only there really was a manual to FR.