Re: Jackd hell and other oddities
Hi all, sorry for the delay. |--== Daniel James writes: DJ Hi Free, Well, a possible definition of the group could be the list of the Alioth's project members http://alioth.debian.org/projects/demudi DJ Do you think it would be possible to ask Nicola Bernardini to redirect DJ demudi.org to this alioth page? The Plone site created by the Agnula DJ project which is currently visible via that domain name hasn't had any DJ news posted for nearly two years now. Yes it would be possible, but I'd rather keep the current DNS for www.demudi.org, as historically it was the AGNULA project that fostered the development of DeMuDi (hence the name AGNULA/DeMuDi), and even if the chances are relatively low, I wouldn't exclude that it could do that again in the future. For the moment I've simply modified the home page of www.agnula.info (to which www.demudi.org is pointing), and added a notice about the Debian Multimedia project on the top and a like to its wiki at: http://wiki.debian.org/DebianMultimedia Notice that I've split the page above in sub-pages, to make it easier to read and extend. Wiki maintainers are welcome! DJ By the way, http://demudi.alioth.debian.org/ links back automatically DJ to the hijacked demudi.agnula.org site, which sometimes has dodgy DJ links on it. DJ demudi.alioth.debian.org is listed as the project homepage on DJ alioth.debian.org/projects/demudi - so there's a bad loop there. It DJ gives the false impression that nothing's going on with Debian DJ multimedia these days. Thanks for the report, I've changed the redirection of demudi.alioth.debian.org, and it now points to the wiki page of Debian Multimedia. DJ Perhaps the alioth page could list all the active, Debian-derived DJ multimedia projects. There are some projects under DJ http://alioth.debian.org/softwaremap/trove_list.php?form_cat=99 which DJ could probably be cross-linked. Yes, anyone willing to make a selection and add it to http://wiki.debian.org/DebianMultimedia/Links DJ Also, DJ http://alioth.debian.org/mail/?group_id=30525 doesn't show the DJ debian-multimedia@lists.debian.org list. That's because it shows only the alioth mailings list, it's not possible to change that. DJ And finally, on http://alioth.debian.org/projects/demudi it says DJ 'Development Status: 3 - Alpha' which I don't think is a fair DJ reflection of the stability of the software in 2007. I couldn't understand how to modify that, perhaps is something that we have to ask to the Alioth admins. Ciao! Free -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Jackd hell and other oddities
Daniel, you are right, sorry. Let's see asking for it to Bernardini... Marco -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Jackd hell and other oddities
Daniel James escribe: The point I like to make to them is that the true innovators in electronic music didn't follow what everyone else did, they created their own tools. Still, it does explain why there's so much derivative dance music around. I remember when Rebirth first came out, it was like 'instant acid house, in a can'. Right, like John Cage's piece for a detuned piano or Ligeti's one for a hundred metronomes. Then people ask Linux to ship with a hundred metronomes an apt-get away... Cordially, Ismael -- Ismael Valladolid Torres m. +34679156321 La media hostia j. [EMAIL PROTECTED] http://lamediahostia.blogspot.com/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Jackd hell and other oddities
Eric Dantan Rzewnicki escribe: /etc/security/limits.conf needs to be set up as well. It's a simple step, but I guess it would be good if users didn't have to ask about it. A multimedia dedicated distro should ship /etc/security/limits.conf configured for realtime but not a generic distro. Letting all process from a user in the group audio getting realtime could pose a security problem in a server setup. Cordially, Ismael -- Ismael Valladolid Torres m. +34679156321 La media hostia j. [EMAIL PROTECTED] http://lamediahostia.blogspot.com/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Jackd hell and other oddities
On Thu, Apr 12, 2007 at 10:33:32PM +0200, Ismael Valladolid Torres wrote: Eric Dantan Rzewnicki escribe: /etc/security/limits.conf needs to be set up as well. It's a simple step, but I guess it would be good if users didn't have to ask about it. A multimedia dedicated distro should ship /etc/security/limits.conf configured for realtime but not a generic distro. Letting all process from a user in the group audio getting realtime could pose a security problem in a server setup. Sure, but some sort of audio-workstation meta-package could perhaps include a debconf question that sets this up based on user input or something. It would of course not be something installed by default on all systems whether asked for or not. -Eric Rz. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Jackd hell and other oddities
On Thu, 2007-04-12 at 18:03 -0400, Eric Dantan Rzewnicki wrote: On Thu, Apr 12, 2007 at 10:33:32PM +0200, Ismael Valladolid Torres wrote: Eric Dantan Rzewnicki escribe: /etc/security/limits.conf needs to be set up as well. It's a simple step, but I guess it would be good if users didn't have to ask about it. A multimedia dedicated distro should ship /etc/security/limits.conf configured for realtime but not a generic distro. Letting all process from a user in the group audio getting realtime could pose a security problem in a server setup. Sure, but some sort of audio-workstation meta-package could perhaps include a debconf question that sets this up based on user input or something. Debconf is powerful, but it works best when it is non-interactive; strong and silent. Most users will only know one way to encounter debconf: at install time. There is no compelling and discoverable UI to debconf on a freshly installed GNOME or KDE desktop! This configuration must be possible to find by digging a little in the System menu on GNOME or in KDEs control center. And it needs to be triggered by the installation of packages that suggest low latency features. Why should the user have to know _in advance_ what settings to tweak to make an app work? The app's packagers should have that knowledge, and present that information in a convenient way. And not by dumping a README.txt into a pager. If you have the power to compile source code and build packages, you also have the power to add new components in the Desktop Environment that will provide a nice and shiny UI with all the choices the user must make. Not necessarily at install time; at runtime is often more convenient. What is missing is a policy on how such UI-plumbing is supposed to be done. It would of course not be something installed by default on all systems whether asked for or not. It probably should be the default for an audiovisual workstation. But then again, the user ought to be warned that services that require high availability should not be hosted on that computer! -- Herman Robak -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Jackd hell and other oddities
On Wed, Apr 11, 2007 at 02:37:53AM +0200, Free Ekanayaka wrote: If my interpretation is correct, my question is, Marco according to your experience is the installation of a multimedia/desktop kernel on a plain Debian (or Linux) distribution enough to fill the responsiveness gap? /etc/security/limits.conf needs to be set up as well. It's a simple step, but I guess it would be good if users didn't have to ask about it. If the multimedia kernel includes ingo's rt patches, then some script to set IRQ priorities and such, like Rui's rtirq thing, is also needed. I feel like there must be something else, but maybe it's just remnants of historical cruft lingering in my brain from earlier years when this stuff took more effort ... 1) Include in Debian a Multimedia/Desktop Kernel IVT I agree it should also be available an apt-get away nevertheless. This is actually not that straight. I've tried to that myself about one year ago, and the feedback from the debian-kernel folks was really positive, but also clear in the guarantees that the possible multimedia kernel maintainer should offer. I was basically said that if I wanted a multimedia flavour to be added, I also had to be available to provide support for the security updates, both in stable and in testing. This request is pretty reasonable to me, but also quite demanding, and I'm not sure if we, as Debian Multimedia Team, have the forces to keep with such a task. Of how many active developers does the Multimedia Team currently consist? and can we recruit more? Are those handling the alsa packages here? what about xiph-maintainers? are there other groups? maybe the gst maintainers? I don't know for sure, but I feel like there must be many more debian-devs who care about audio and video than those who currently participate in this list. (I intend to begin the new maintainer process this year, but I don't count, yet.) 2) Make Jackd usable out of the box or after the installation of a normal package I've lost the quoting ... so not sure who asked this, but did you mean make it easy to build and use jack from not-yet-debian-packaged release or svn? Removing the .so name mangling as Free has done will help with this. In my somewhat naive understanding, it seems there are 2 complementary approaches to this issue: 1) keeping jack debian packages up to date with jack releases (so fewer users have a need to build their own). 2) providing a clear and easy set of instructions for users who want or need (say for a bug fix affecting them) debs of svn ... perhaps using svn-buildpackage. So users can easily role their own debs that work with all of their installed jack apps. (or maybe somehow debs could be autobuilt somewhere for each jack svn release ... just thinking out loud, not sure if that is practical or not.) IVT I find it usable out of the box... I agree with what Daniel said, the focus of general purpose distribution is different, but I also agree that we can do much better. I think lenny has the potential to provide a perfectly useable multimedia workstation with very little end-user pain. -Eric Rz. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Jackd hell and other oddities
|--== Eric Dantan Rzewnicki writes: EDR On Wed, Apr 11, 2007 at 02:37:53AM +0200, Free Ekanayaka wrote: If my interpretation is correct, my question is, Marco according to your experience is the installation of a multimedia/desktop kernel on a plain Debian (or Linux) distribution enough to fill the responsiveness gap? EDR /etc/security/limits.conf needs to be set up as well. It's a simple EDR step, but I guess it would be good if users didn't have to ask about it. EDR If the multimedia kernel includes ingo's rt patches, then some script EDR to set IRQ priorities and such, like Rui's rtirq thing, is also needed. This are both things which are performed automatically in 64 Studio, but not in Debian yet. I've once tried to upload Rui's init script, but it was rejected because considered to tiny. Maybe we could include it as extra in some other package. EDR I feel like there must be something else, but maybe it's just remnants EDR of historical cruft lingering in my brain from earlier years when this EDR stuff took more effort ... Please if you find something more, let me know. 1) Include in Debian a Multimedia/Desktop Kernel IVT I agree it should also be available an apt-get away nevertheless. This is actually not that straight. I've tried to that myself about one year ago, and the feedback from the debian-kernel folks was really positive, but also clear in the guarantees that the possible multimedia kernel maintainer should offer. I was basically said that if I wanted a multimedia flavour to be added, I also had to be available to provide support for the security updates, both in stable and in testing. This request is pretty reasonable to me, but also quite demanding, and I'm not sure if we, as Debian Multimedia Team, have the forces to keep with such a task. EDR Of how many active developers does the Multimedia Team currently EDR consist? and can we recruit more? Well, a possible definition of the group could be the list of the Alioth's project members http://alioth.debian.org/projects/demudi who are the one with commits rights in the SVN repository, but of course there are much more DDs maintaining audio/multimedia related packages. EDR Are those handling the alsa packages here? what about xiph-maintainers? EDR are there other groups? maybe the gst maintainers? I don't know for EDR sure, but I feel like there must be many more debian-devs who care about EDR audio and video than those who currently participate in this list. Actually I think that for this kernel matter it's not (only) a matter of how many people you have, but also how much committed they can be. To maintain a kernel flavour requires a very close interaction with the kernel team, which is one of the most active in Debian, and at least the reading of the relevant mailing list (which is rather busy). Probably it's something that could be done by one or two people, but they need to have the proper skills and the necessary commitment. EDR (I intend to begin the new maintainer process this year, but I don't EDR count, yet.) That would be great! If you want to start working on existing packages or making new ones, you don't strictly need a debian account. For example I could include you in the Alioth project and you could work directly with project's SVN repository. When you think you're done with some task, just commit it and drop me a line, I can review it sponsor the package for you. 2) Make Jackd usable out of the box or after the installation of a normal package EDR I've lost the quoting ... so not sure who asked this, but did you mean EDR make it easy to build and use jack from not-yet-debian-packaged release EDR or svn? EDR Removing the .so name mangling as Free has done will help with this. EDR In my somewhat naive understanding, it seems there are 2 complementary EDR approaches to this issue: EDR 1) keeping jack debian packages up to date with jack releases (so fewer EDRusers have a need to build their own). That's something that has always been more or less done, of course we can always be faster. EDR 2) providing a clear and easy set of instructions for users who want or EDRneed (say for a bug fix affecting them) debs of svn ... perhaps using EDRsvn-buildpackage. So users can easily role their own debs that work EDRwith all of their installed jack apps. Probably for a user it would be simpler to ./configure; make install EDR (or maybe somehow debs could be autobuilt somewhere for each jack svn EDR release ... just thinking out loud, not sure if that is practical or EDR not.) Yes, that could be also done. IVT I find it usable out of the box... I agree with what Daniel said, the focus of general purpose distribution is different, but I also agree that we can do much better. EDR I think lenny has the potential to provide a perfectly useable EDR multimedia workstation with very little
Re: Jackd hell and other oddities
Hi Ismael, Musix kernels are packaged by Tapani Raikkonen This may have changed recently, but last month they used our 2.6.17 package in their 0.99 release, see under 'New Software Packages' here: http://lists.linuxaudio.org/pipermail/linux-audio-announce/2007-March/000932.html The more package sharing we can do, the better - apart from avoiding duplicated effort, it makes QA much easier because the kernel config is no longer such a big variable between distros. Cheers! Daniel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Jackd hell and other oddities
Hi Marco, 1) A multimedia/desktop oriented kernel like the one in 64Studio or here: ftp://musix.ourproject.org/pub/musix/deb/kernel/n I believe Musix now uses the 64 Studio kernel packages, so that's one less variable ;-) Ubuntu Studio is not going for a Molnar-style RT kernel, according to an interview with Cory Kontros I read. The reason why this has not been made already it's a secret to me, and a even weirder one. I believe it's because in the mainstream, audio on GNU/Linux has mostly been addressed from the point of view of a so-called 'consumer'. So distros have tried to solve questions like How do I make my iPod work out of the box, so I can re-arrange my collection of Britney Spears downloads? rather than How do I tune my kernel and OS for maximum performance when tracking 24 channels over my ADAT interface? I believe free software has a role to play in providing serious, reliable tools to the people that need them, in order to enable and enhance their creativity. Among other free software advocates, there is an argument that says we need to chase the tail-lights of OS X and Windows Vista in providing a slick 'consumer' experience, which has very little to do with RT kernels or tools like jackd. Cheers! Daniel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Jackd hell and other oddities
Daniel James escribe: I believe Musix now uses the 64 Studio kernel packages, so that's one less variable ;-) Ubuntu Studio is not going for a Molnar-style RT kernel, according to an interview with Cory Kontros I read. That's not the case. Musix kernels are packaged by Tapani Raikkonen which by the way is doing a great job, Musix is delivered with the most recent kernels suitable to be patched for realtime work. I believe it's because in the mainstream, audio on GNU/Linux has mostly been addressed from the point of view of a so-called 'consumer'. So distros have tried to solve questions like How do I make my iPod work out of the box, so I can re-arrange my collection of Britney Spears downloads? rather than How do I tune my kernel and OS for maximum performance when tracking 24 channels over my ADAT interface? I agree with that. A system suitable for those who enjoy multimedia just for fun is very different than a system for those who use a system for multimedia creation. Indeed almost nobody really needs jackd to be installed unless she pretends to use ardour, zynaddsubfx or similar soft. So I think it's ok that Debian doesn't focus on multimedia creation given there are more suitable distros adapted from the Debian main one. Cordially, Ismael -- Ismael Valladolid Torres m. +34679156321 La media hostia j. [EMAIL PROTECTED] http://lamediahostia.blogspot.com/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Jackd hell and other oddities
Hi Daniel, Hi Marco, 1) A multimedia/desktop oriented kernel like the one in 64Studio or here: ftp://musix.ourproject.org/pub/musix/deb/kernel/n I believe Musix now uses the 64 Studio kernel packages, so that's one less variable ;-) Ubuntu Studio is not going for a Molnar-style RT kernel, according to an interview with Cory Kontros I read. Nice, but I was meaning having it into the official Debian archive, not in an external repository. I know many people who use Ubuntu kernel on Debian for its responsiveness and this is a bit strange. IMHO Debian should install a desktop friendly kernel if the user chose during the installation the Desktop task. Does it make sense? The reason why this has not been made already it's a secret to me, and a even weirder one. I believe it's because in the mainstream, audio on GNU/Linux has mostly been addressed from the point of view of a so-called 'consumer'. So distros have tried to solve questions like How do I make my iPod work out of the box, so I can re-arrange my collection of Britney Spears downloads? rather than How do I tune my kernel and OS for maximum performance when tracking 24 channels over my ADAT interface? I love Britney, especially after she shaved everywhere... ;-) Poor girl... I believe free software has a role to play in providing serious, reliable tools to the people that need them, in order to enable and enhance their creativity. Among other free software advocates, there is an argument that says we need to chase the tail-lights of OS X and Windows Vista in providing a slick 'consumer' experience, which has very little to do with RT kernels or tools like jackd. Responsiveness, always IMHO, is exactly the point. I get lots of question from people saying two things: 1) a default Linux installation is less snappy (responsive) than a fresh Windows install (in example using the same software like Audacity) BUT 2) they all see easily that Linux doesn't get slower also if you add thousands of packages (no defrag needed, as we all know) and the two things in a way are inexplicable to them. Short version: 1) Include in Debian a Multimedia/Desktop Kernel 2) Make Jackd usable out of the box or after the installation of a normal package In any way I want to make clear that my questions/suggestions are based only on a personal point of view/experience and in no way I have the rights/merit to contrast your opinions. Free as in speech... Regards, Marco -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Jackd hell and other oddities
Marco Ghirlanda escribe: 1) a default Linux installation is less snappy (responsive) than a fresh Windows install (in example using the same software like Audacity) As far as both default installations have no software and in Debian all software is just an apt-get away, I admit I don't understand your point. 1) Include in Debian a Multimedia/Desktop Kernel I agree it should also be available an apt-get away nevertheless. 2) Make Jackd usable out of the box or after the installation of a normal package I find it usable out of the box... Cordially, Ismael -- Ismael Valladolid Torres m. +34679156321 La media hostia j. [EMAIL PROTECTED] http://lamediahostia.blogspot.com/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
