Re: [LAD] LADI
On 11/21/2009 03:21 PM, Paul Davis wrote: > > I am personally appalled by the debacle that LASH turned into. > Stemming from a proposal made years ago (by Bob Ham, I believe), LASH > has gone more or less nowhere. It has never arrived at a stable, > congruent and consistent specification, even via a header file. The > people working on the project have appeared to a casual observer like > myself to be in constant turnover and/or constantly redesigning the > entire system with a claim that this time it will be done right. The > project is, quite frankly, a joke when compared to what has been > managed with ALSA, LADSPA, JACK and even something like DSSI. > Certainly session management is an important issue when using a weakly > connected set of cooperating applications, and it remains almost > entirely unsolved. I personally have no faith that any of the work on > LASH has moved us notably closer to an actual solution to this issue, > although I will grant that it has helped some developers to get a > better grasp on what some of the issues actually are, and for that I > suppose we must be grateful. > We have seen many good things come from the session management development process. LADI is the most advanced implementation for session management that has been achieved so far. There have been a consistent set of procedures applied in all the above projects and in many cases the issues that the session management people have encountered have been consistent the main exception being the lack of consensus by the community on which approach makes the most sense. As has been stated before many times, the standard model established over the years in LAD has required one or two highly motivated people to push forward with their vision and also take on the wider community with a forceful and intense defense of their direction. Nedko has chosen to work with dbus and has provided a very flexible system built on that decision. However his approach is not acceptable for all use cases. Afaict there is very little interest from parties that disagree with the dbus approach to enhance the LADI toolset in a way that makes it more flexible for their use and vision. One major item of note is that qjackctl now has preliminary dbus support even though Rui has stated that it would not happen. This step in itself should be clear a major roadblock to LADI integration and deployment. Patrick Shirkey Boost Hardware Ltd ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] LADI
On Fri, Nov 20, 2009 at 10:06 PM, Patrick Shirkey wrote: > It's not easy to find motivation for continuing development when a large > subset of your ideas are received as fundamentally flawed because of the > core design choice that enables their existence. I think that I should be clear on why nedko's work on using dbus with jack has not been integrated into the jack1 codebase. Its really very simple, and has absolutely to do with the "dbus" issue in the way that it has played out on this mailing list. there are basically a few core reasons: 1) the coding guidelines specify that the core jack1 codebase should contain only ANSI C and POSIX. we allow utility clients to exist that have other dependencies, but they are always conditionally compiled and are not considered core elements of JACK. dbus does not meet this test. 2) the only API to talk to the JACK server has been provided by one or more libraries provided by JACK. this means, for example, that we have not "published" the protocol used between the server and libjack. It is therefore incongruous with the existing design of JACK to add any IPC mechanism (OSC, dbus, CORBA, DCOP, Sun-RPC or whatever else you might care to suggest) directly into the JACK server or libraries that make up the core of JACK. 3) reliance on 3rd party technology is only acceptable if it is clearly platform independent. dbus does not meet this test (although it is not terribly far from meeting it, it still does not meet it). there are actually very few IPC technologies that do. 4) reliance on technologies that appear to be tied into desktop-centric computing architectures should probably be avoided in the core of JACK. Having other JACK tools that integrate well with various desktop platforms seems VERY desirable, but it seems reasonably clear that there is no inherent reason to build such functionality into anything that is distributed as "part of JACK". if a particular distribution wanted to "fix JACK" by integrating into their desktop, that also seems entirely reasonable, and might be something that other distributions would pick up. the success of such work would have little to no impact on the core of JACK. Hopefully, this can remain focused on providing, as well as it can, a cross-platform pro-audio/music audio server for use on a variety of platforms and a variety of use cases, including but not limited to systems where "integration" is not an issue. Nedko's jackdbus actually shows a way to do this: he provides (almost simultaneous) releases of jackbus that feature a level of integration between JACK and dbus-based IPC for control that seems inappropriate for a general release of JACK. I am glad that those who which to control JACK in this way have the chance to do so with current versions - its a good thing. What would always have been acceptable, and without any argument or even much discussion was (a) implementation of the "control API" as a JACK library combined with (b) a client that understand dbus (or OSC, or Sun-RPC or DCOP or whatever) and translated between the JACK control API and whatever protocol it used to communicate with the outside world. Nedko did not want to do things in this way, and has even stated to me on IRC that he believes that we/I should have been willing to simply adopt the work that he did do until something better came along. This is not how Linus has successfully managed the kernel, and although I believe that Linus has done a better job of that then we have managed with JACK, his example is still something that I believe is correct to follow here. Precisely the same points would have had to be made had Nedko or someone else taken a similar approach using OSC, Sun-RPC, DCOP or any other IPC protocol/technology. None of this is intended to negate the entirely valid points that Nedko makes about some aspects of JACK's implemenation(s). However, his sensitivity to people's commentary on dbus, along with some of the really undeserved and ignorant criticism of dbus that has appeared on this mailing list, makes it necessary to try to be as clear as possible on the actual issues that block adoption of some or all of the work he has done. The problems that he has mentioned separately DO need working on (and preferably fixing), and any ideas, designs and contributions of code that meet the coding guidelines long established, along with some of the points I have raised above will be very welcome. Moving on a bit I am personally appalled by the debacle that LASH turned into. Stemming from a proposal made years ago (by Bob Ham, I believe), LASH has gone more or less nowhere. It has never arrived at a stable, congruent and consistent specification, even via a header file. The people working on the project have appeared to a casual observer like myself to be in constant turnover and/or constantly redesigning the entire system with a claim that this time it will be done right. The project is, quite frankly, a joke when compared to what
Re: [LAD] LADI
Hi Nedko - I agree wholeheartedly with you are trying to achieve and think your work could be quite important to the linux audio community I have gone as far as running and testing (g)ladish - So far I haven't been able to anything really useful to with it. I noticed that the next milestone is supposed to provide methods for launching apps within ladish (am I right in thinking that applications started in this manner gain some support for basic session management even if they are not specifically written to do so?) and I was waiting on that do some more extensive testing. ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] LADI
On Fri, Nov 20, 2009 at 3:15 PM, Nedko Arnaudov wrote: (hopefully you've all read what Nedko wrote...) Nedko, I can't comment on the technical merits or drawbacks of your project, but I can say that as a user who wants Linux audio to be easier to manage, the LADI(sh) project is one that I've been keeping a close eye on. When I first began using Linux for audio several years ago, LASH was one of the exciting things that I thought set it apart from other platforms... and I was saddened to discover that very few programs supported it, and at that time there was no "dashboard" program to control it aside from the command line. Even now, as you've mentioned, LADISH doesn't offer features beyond existing tools (yet) and is still in the "preview" stage. That's the only thing that has held me back from testing... which I suppose is a catch-22 situation. When you release preview 2 of LADISH, I'll be sure to try it out. I'd like to see hacking continue on it, and when you've got some more tangible results to show off its functionality (maybe post some screencasts somewhere?) perhaps more of the community will jump onboard. Sean ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] LADI
On 11/21/2009 01:00 PM, Rui Nuno Capela wrote: > On 11/20/2009 08:15 PM, Nedko Arnaudov wrote A LOT :) > > Nedko, are you on some kind of a meltdown or something? > > now that i was making my day (erm, night?:) with your lv2fil plugin, are > you throwing in the towel (*) ? > > certainly you aren't _that_ desperate, i hope. > > am i too naive to assume you're just stirring the heavy waters of the > reactor? ;) > > I know exactly where Nedko is coming from. He has invested a lot of effort into making huge strides in developing his vision for session management. I didn't realise that Ladi was being left in the cold by the wider community. It's not easy to find motivation for continuing development when a large subset of your ideas are received as fundamentally flawed because of the core design choice that enables their existence. In addition being continually dragged into a heated debate or having flames directed your way by the people who you are trying to get constructive feedback from can be extremely tiring, stressful and depressing. Not to mention the trolls or people feeling trollish at a given moment like to direct their attacks at the people who are taking the most heat which can be an additional source of annoyance. The same issues that Nedko sees with the anti reaction for his work is the same thing that the PA developers receive and verges on the same thing the OSS developers have received in the past. Hence there is usually a conflict and heated argument when these parties contribute to discussions in the wider community. The one thing that cannot be denied is that each of the above has technical merits that the core developers have decided are worth "compromising" on or developing around to achieve their goals. I personally see Nedkos work as extremely valuable so I will be making some time for testing and feedback. Patrick Shirkey Boost Hardware Ltd ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] LADI
On 11/20/2009 08:15 PM, Nedko Arnaudov wrote A LOT :) Nedko, are you on some kind of a meltdown or something? now that i was making my day (erm, night?:) with your lv2fil plugin, are you throwing in the towel (*) ? certainly you aren't _that_ desperate, i hope. am i too naive to assume you're just stirring the heavy waters of the reactor? ;) uber-procrastinator dixit -- rncbc aka Rui Nuno Capela rn...@rncbc.org (*) spam warning: lv2 plugin support shaping up in qtractor ;) ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] LADI
> > > If I'd respond to all technical issues you raise the > result would be a 30-page paper. Maybe I should present > it a the next LAC, to be hung on the nearest high tree > shortly afterwards. I think you should (present at at the LAC, not be hung on the nearest tree). That's a very good forum for these discussions. Perhaps a Panel discussion on 'desktop' versus 'pro-audio' could be set up. Victor ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] LADI
On Fri, Nov 20, 2009 at 10:15:20PM +0200, Nedko Arnaudov wrote: Nedko, Since you refer to me twice in your post I feel free to respond. And even if you may regard me as one of your 'adversaries', please don't take anything I write as a comment on you personally. Let me say first that I'm sorry to see you in such a state of despair. On one hand I'm sure you're not the one to blame for it. On the other, you can't blame the world. Some things are just what they are. I do share many of your technical concerns about Jack, about session management, and the state of LA in general. My views on how they can be solved are probably quite different to yours. This won't make me many friends, but I don't believe there are easy solutions, in the sense that there could be a gradual evolution, consisting of a series of simple steps, each of them 'backwards compatible', that would resolve the problems that do exist. Unless maybe for someone who is prepared to wait much longer than I am. This may be a personal attitude, but I believe that in a situation like this one, at some point you have to bite the bullet and clean up the mess that stands in the way, no matter how much pain it causes. In IT language, some of the solution (IMHO) will be incompatible with current practices, APIs, and standards. If I'd respond to all technical issues you raise the result would be a 30-page paper. Maybe I should present it a the next LAC, to be hung on the nearest high tree shortly afterwards. So I'll limit my response to the dbus related issues, also since you accuse me of having waged a flame war against it. Let me make it clear: I do not like dbus, for a variety of reasons. The first is its ugly API. That's opinion, but it's my opinion and not likely to change any time soon. The second, and more important, is that it mixes up a lot of different things. Maybe, to arrive a Linux Audio apps that are as user friendly as some of the ones that exist on competing systems there are two solutions. One is the 'integrated application' where everything can be done within just one program, and the whole issue of session management and connections is internal to that application. The other is a degree of session management that would provide almost the same user experience, and for such a thing maybe a system like dbus is part of the solution (but see comments below). But in that case the only concern of such an inter-application communication framework should be communication. Not security, access control, or any form of policy. And certainly not any dependency on irrelevant context, such as a desktop or a local login. ** If you had proposed a separate 'audio dbus', completely independent of the desktop session one, my reaction would probably have been much more relaxed. ** The third, already hinted at above, is the close relation of dbus to some other systems designed to provide a 'rich' Windows-like desktop experience. The Kit family is not really a set of independent and maybe on their own useful components. It's rapidly becoming a 'all or nothing', take it or leave it' sort of thing just like Windows, with all the consequences that brings. And and least for me, those consequences are not acceptable, the whole thing is much too invasive and desktop-centered. And AFAICS, dbus is very much married into that family. Finally, some comments on session management. If session management is supposed to work then apps have to agree to being managed rather than doing everything on their own. This includes for example external Jack connections: to whom does a connection A->B belong, to A or B ? At least Linux Audio's most famous app, Ardour, is not moving that way - it's going the 'integrated app' way, and even more so since its developers are looking more and more towards OSX. Wait a bit more and it will integrate everything you need to make (some types of) music. And at that point the whole session management issue will become irrelevant. Except for people like me who are very much into minority interests that never will be covered by integrated applications. Secondly, being managed means that apps are talking to their session manager. Not to each other. In other words, this is a 'star' type of topology, not a bus. There are many existing standard solutions for that, and they don't need dbus. Nor do they need autolaunching of servers etc. Ciao, -- FA Io lo dico sempre: l'Italia รจ troppo stretta e lunga. ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] [LAA] Ubuntu Studio 9.10 Karmic Koala
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Robin Gareus wrote: > Ralf Mardorf wrote: >> Ivica Ico Bukvic wrote: >>> How come the linuxaudio.org mirror (http://download.linuxaudio.org) is not >>> any more updated with newer releases? Last version available on there is >>> 7.04 which is truly enchant. >>> >>> What do we need to do to jumpstart this thing again? I presume this would be >>> something you guys would want to explore, particularly considering that the >>> hosting/bandwidth are effectively free... >>> >>> Ico Ubuntustudio is updating as we speak. >> Oops, Suse also is outdated there. jacklab - which is was the motivation for the openSuse mirror on download.linuxaudio.org - has been discontinued. OpenSuse is not very linux-audio specific and they have quite some high-bandwidth mirrors themselves. Do we really need to mirror that? The 64studio ISO-image mirror is up to date; however the apt mirror of 64studio is outdated due to rsync://64studio.com::apt/ returning "No such file or directory". I've notified Daniel James about that. so long, robin -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAksG/sUACgkQeVUk8U+VK0IhfgCfezH+NQHgrgWlJPjp2dMsjpAy fuUAn2ElBxs9B1Ej475wJwqFNhbMLbIe =QoHB -END PGP SIGNATURE- ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
[LAD] LADI
After recent discussion on IRC I'm loosing faith in whether it is worth to contribute to linux audio session handling/management. Two reasons were given why it does not get testing from users. One is that what I did so far is not mature, has annoying bugs and I'm not wanting to fix them. The other one is that ladish is not giving more than users already have with qjackctl. Also it was mentioned that D-Bus is not what users find acceptable for controlling jack server. Given the almost missing feedback about LADI development from community members that could benefit from it, I'm not sure whether I should continue to contribute. Maybe I should give up on trying to make linux audio usable for my needs. I could also stop using computers and make music only by using my guitar. Because alternatives to Linux Audio (windows/mac) don't suit my needs. Moreover they don't have the potential to suit. This is why I'm contributing to Linux Audio and not making VST plugins or something. This anti-dbus movement is getting too far. If there is no user that accepts my point of view, there is no point of me contributing. Because it may be possible that someone has missed the whole point of my jackdbus and session handling effort, I'll try to explain what I find wrong/unacceptable in JACK (dbus-less) system as we have it now. * JACK server tries to kill clients that are suspected to misbehave and cause xruns or expose other kind of bad behaviour. This can result in qjackctl (or patchage for example) being killed. IMO, killing control apps is wrong. Apps that that don't process audio/midi should be treated differently. * When jackd is autolaunched, log messages are going to stdout/stderr of the app that launched them. This is wrong, unix daemons are supposed to have a log file, even if they are per-user. One of the reasons why log file is a good thing to have is that it allows to analyze problem post factum. This helps a lot if some misbehaviour is rarely reproducable. * Control apps that start the jack server through jackd know only about the parameters that were known at compile time. Somewhat recent example, IIRC, jack2 specific parameters (-S) and firewire options missing after upgrade of jack because qjackctl does not know about them. IMO, control apps should be able to query parameters for jack and display the available options to user. * Control apps that manage jack connections, are subject to realtime constraints. IMO, this complicates control apps development for no good reason. This is valid only for jack1. jack2 already uses non-realtime threads for port notifications. * Implementing control app requires C level program or use of specially crafted bindings. It will be good if control apps could be implemented with few lines of code in a scripting language as Python, Ruby, Perl, etc. * JACK graph (clients, ports and connections) API is badly designed and is prone to race conditions. Fons talked about this problem recently too. * Session handling capabilities are suboptimal. Various programs lurk here. I'll mention the two most popular ones: qjackctl cant save/restore internal state of the programs. It also cant save and then relaunch them automatically. lash cannot manage jack settings and cannot restore connections for applications that are not linked against liblash. There are other problems but those are the most frustrating ones. * Hardware port virtualization is suboptimal. it is provided through the JACK "system" client. The only reliable ports are first ones, they are expected to be the main input/output. If applications wants to connect to phones for example it does not know on what ports they are. projects/session should be movable to other system, one with different hardware setup and [extensive] reconnecting should not be required. * Hardware port names are not human readble. Aliases exist but are not widely used for various reasons. Users should be able to name and group their ports to match their hardware cable setup. * JACK "system" client is used for non-hardware ports (-X seq). * There is no global list of JACK enabled applications. * JACK MIDI is not widely accepted. JACK AUDIO + ALSA seq appears to be acceptable solution. IMO, sample accurate audio+midi is very important. * There is no session handling for netjack LAN setups. * Session handling apps cannot restore apps to more than one X11 screen (do not mix with X11 display). * Patchage-like (flowcanvas based) patchbay interface is best what I've seen. Unfortunately Patchage does not integrate well with other parts of JACK infrastructure. As you can see, I have collected enough problems to fight. Almost all of these fixes need new software modules to be written or existing ones to be rewritten. In past years I've tried to collaborate with people behind JACK, LASH, Patchage and Qjackctl. At the end, I think t
