On 4 Nov 2003, Jack O'Quin wrote: > 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.
My experience in general is that it doesn't work that good ... Seems to depend largely on type of soundcard too. > > 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. Its in /etc/X11/Xwrapper.config Seems that it is changeable with debconf -- snip --- ### BEGIN DEBCONF SECTION # Do not edit within this region if you want your changes to be preserved by # debconf. Instead, make changes after the "### END DEBCONF SECTION" line. allowed_users=console nice_value=-10 ### END DEBCONF SECTION -- snip --- > > > 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 > Zenaan: > > - 686 processor optimized, MMX, SSE, etc ?? > > - follow existing kernel-image-... package naming conventions (roughly) > > - lowlatency > > - preempt > > - ALSA (no OSS, ie remove legacy ??) This is probably not a good idea (remove the legacy mode). Also it might not harm to leave the OSS modules in the kernel. ALSA is a separate package in 2.4, so we have to build our own alsa modules anyway. > > > 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. Thats interesting, I am just guessing here, but probably the mlockall needs the whole program loaded into RAM, and this process needs CAP_SYS_RESOURCE ... ? (This is a really wild guess, to tell the truth I don't have any idea). Guenter
