Zenaan Harkness <[EMAIL PROTECTED]> writes: > > 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
Some people have reported good results running jackd without realtime privileges using larger buffers (hence larger latencies). For me, running Debian without SMP, this does not work well at all. The largest buffer my soundcard supports is 2048 frames, and I still get frequent overruns whenever the X server is active. Someone told me that Debian runs the X server with nice -10 (or something). This might explain why non-realtime audio works OK for others but not for me. It also seems to work better for people using SMP machines, perhaps for the same reason.If I could find where this happens I would experiment with turning it off. > 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: - capabilities enabled > - 686 processor optimized, MMX, SSE, etc ?? > - follow existing kernel-image-... package naming conventions (roughly) > - lowlatency > - preempt > - ALSA (no OSS, ie remove legacy ??) > > 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 ? > 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... This could be done. Jackstart tries to be very careful to ensure that it only starts the *real* jackd, checking ownership, permissions and md5 checksum. That could be generalized, I suppose, along the lines of /etc/sudoers. If only the required realtime capabilities could do without CAP_SYS_RESOURCE, I would advocate opening them up to any process in group `audio'. The advantage of this is that if all audio applications automatically got realtime privileges, there would be no need to delegate CAP_SETPCAP, which is the danger the kernel gurus fear, AFAICT. There would be no need for a special starter program, one could just do... # chgrp audio foo # chmod g+s foo I'm not sure what the problem is with CAP_SYS_RESOURCE. Both Nando and I tried to run jackstart and jackd without it. Neither of us could get it to work that way. It fails on the call to mlockall(). Looking at the kernel sources, it only checks `capable(CAP_IPC_LOCK)' explicitly. I suppose there must be some hidden resource allocation going on somewhere else that requires this. Maybe this is just a bug in the kernel and someone could fix it. -- Jack O'Quin Austin, Texas
