Some random ideas (was Re: fw: jackd/ audio apps mini policy)
I think that even raises some new ideas.
As the number of debian packages has grown to 5 digit numbers and
most people don't mind burning the entire CD set (at least most
people I know burn/buy the first CD and install the rest from the
network), maybe we should start thinking of different ways to organize
the distribution.
I'd like to see the "debian multimedia task" created (or at least
mentioned in the Debian web pages) to deal with this kind of discussion.
Ideally, I'd love to have all "multimedia" (at least audio, video and
graphics) related packages on a single CD.
I've been away from debian-devel for a while, I don't know if such a
thread was brought forth in the recent past, but maybe we should even
start thinking about the way we group our packages, for me it seems that
we've grown too large for just ordering packages by popularity.
This Debian Multimedia package set could be comprised of custom kernels
for real time, some useful datasets like soundfonts/samples synthesizer
instruments, whatever...
Just some thoughts that have been chasing me on the last few weeks at
least...
Em Ter, 2003-11-04 às 08:36, Zenaan Harkness escreveu:
> On Tue, 2003-11-04 at 20:08, guenter geiger wrote:
> > Hi, thanks for your explanations,
>
> Courtesy the old(er) hats on debian-mentors. I essentially just collated
> the responses to my questions. You're welcome.
>
> > The way I see it the only solution to have realtime functionality
> > with JACK is to build a capability and lowlatency patched kernel and set
> > jackstart suid root via the debconf system.
>
> That certainly seems to be the consensus and it sounds right to me.
>
> > Setting jackd root does not work, because in that state JACK does not
> > accept clients started from users.
>
> :)
>
> Yes, I have discovered this - had me scratching my head for quite some
> time initially.
>
> > Anyhow, as JACK is not of too much use without the lowlatency patched
> > kernel, this is the only option we currently have.
>
> ... for "professional audio". Agreed. And then jackd is still runnable
> by anyone as per standard expectations of debian policy.
>
> jackstart = bonus
>
> > I don't know what is involved in uploading kernel images to debian,
> > we would have to check that. I am going to try to figure that out,
> > if we can agree on this policy.
>
> I think we've just about hashed all possibilities for the policy.
>
> For kernel, either debian-devel, or herbert@d.o (the current debian
> kernel-image-... etc, maintainer - he's very cluey). From the bits I've
> read so far on d-devel, it seems that all that is required is creation
> of a package and probably an ITP for the custom kernel. That will
> naturally invite discussion on d-devel, which would be good.
>
> I think a multi-media specific kernel will be generally appreciated.
> Also, the steps involved in creating it would be good do list here
> somewhere, so that those with lower- or higher-spec hardware can
> customize it.
>
> debian-multimedia custom kernel desired features:
> - 686 processor optimized, MMX, SSE, etc ??
> - follow existing kernel-image-... package naming conventions (roughly)
> - lowlatency
> - preempt
> - ALSA (no OSS, ie remove legacy ??)
> - full kernel package set, a la herbert's existing package conventions
> (eg. kernel-source-2.X.YY, kernel-headers-2.X.YY, etc)
> - do we build on top of herbert's existing kernels (with his selected
> patches - my recommendation) or roll our own from vanilla sources? I
> tend to think that there must be a certain amount of work going into
> establishing what are "good" default options (there are 100s and 100s of
> these) that work well for most people, as well as little stability
> patches, etc, etc, that it would be good to build on, rather than
> rediscovering these ourselves...
> - also, the standard packages have everything modularised - eg. NICs,
> video drivers, pcmcia, etc, etc - again, it is presumably a big win to
> build on top of this.
>
> Perhaps (a la gentoo), our -multimedia kernel package is in fact just a
> script that takes the existing kernel, adds in the kernel-patch-2.X...
> patch packages we need, optionally downloads and installs additional
> patches we recommend, and even auto-detects (and confirms) CPU type to
> get maximally optimal kernel for each user. This is my top preferred
> route - running status (ie verbose make-kpkg output) to keep user happy
> that something is happening while it all happens (after pre-config).
>
> By building on existing programs, ie. make-kpkg (from kernel-package
> package) it should be "relatively" straightforward for someone with
> enough know-how and time...
>
> > Of course the JACK package should then at least recommend the
> > multimedia kernel.
>
> Good.
>
> > For audio apps I think it should be the decision of the application
> > packagers.
>
> To what - recommend multimedia-kernel? - I'd agree.
>
> > All this will introduce security risks, maybe there is a
> > way to write a general audio apps starter that gives the required
> > capabilities (RT sched and memlocking) to the soundapps ?
>
> Yes, this would be ideal. jackstart is apparently already that -
> as per earlier d-mm email:
>
> On Sun, 2003-11-02 at 05:40, Jack O'Quin wrote:
> > Zenaan Harkness <zen@iptaustralia.net> writes:
> > > I thought jackstart was essentially equivalent to a generic wrapper
> > > - both require RTcap-patched kernel. Which would mean the only
> > > difference between 2 and 3 here is the use of jackstart vs. generic
> > > wrapper, where jackstart is more intelligent about jack command
> > > line args. ??
> >
> > Actually, jackstart knows nothing about jackd command args. It is a
> > minimal trusted program written by Fernando Lopez-Lezcano (of Planet
> > CCRMA fame) for invoking jackd with realtime capabilities as carefully
> > as possible. From the comments...
> >
> > Jackstart is based on code and concepts found in sucap.c, written by
> > Finn Arne Gangstad <finnag@guardian.no> and givertcap.c, written by
> > Tommi Ilmonen, Tommi.Ilmonen@hut.fi
>
> (see email archives for more)
>
> jackstart might not need much changes, except perhaps a more
> generic name and some other names (via symlinks or whatever
> config) to run appropriate prog...
>
> regards
> zenaan
--
"If you have an apple and I have an apple and we exchange apples then
you and I will still each have one apple. But if you have an idea and I
have an idea and we exchange these ideas, then each of us will have two
ideas." -- George Bernard Shaw macan at debian dot org
Reply to: