On 5/24/06, Wolfgang Woehl <tito(a)rumford.de> wrote: Hi, I'm just echoing Lee's inputs as someone who's been down the low latency path for a while now. I am currently using 2.6.16-gentoo-r2 with no low latency patches. It works fine on my AMD64 hardware, at least for low work load low latency needs. I run at 64/2 on my HDSP 9652 and get no xruns doing mostly mixing and a very little recording. However I do require realtime-lsm be enabled and loaded. Without realtime-lsm all kernels on my machine, with or without Ingo's patches, cause xruns. I have not tried the pam enabled realtime methods as there doesn't seem to be any value spending the time to do it just yet. Cheers, Mark

On 5/23/06, Lee Revell <rlrevell(a)joe-job.com> wrote: We went through this before. I'm just being a grouse. PAM-0.99.3.0 is masked in portage right now meaning it hasn't been completely tested, etc. It's easy enough to unmask, but why should I bother? I feel no need to be an early adopter in this area. When the Gentoo devs unmask pam then I'll consider it, but why now? Will it give me any fewer xruns than I'm getting with realtime-lsm? It cannot. I'm at zero right now. * sys-libs/pam Available versions: 0.78-r3 ~0.78-r5 ~0.78-r6[2] [M]0.99.3.0 Installed: 0.78-r3 Homepage: http://www.kernel.org/pub/linux/libs/pam/ Description: Pluggable Authentication Modules I expect that when someone produces a kernel that won't work with realtime-lsm then I'll have to jump. Cheers, Mark

On Tue, May 23, 2006 at 05:01:28PM -0700, Mark Knecht wrote: Does realtime-lsm offer any performance benefits over simply running relevant sound apps as root? I'm aware of the security benefits. -- Joel Roth

On 5/23/06, Joel Roth <joelz(a)pobox.com> wrote: No. Cheers, Mark

On Wednesday 24 May 2006 01:01, Mark Knecht was like: I am, and I have to say I think there is value in it. I'm using the debianised patched PAM modules from RFA (thanks Eric!) so it took me all of 10 minutes to set up. I guess it's a bit more fiddly on Gentoo. -- cheers, tim hall http://glastonburymusic.org.uk/tim We are the people We've been waiting for.

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Mark Knecht escribió: For instance Fedora Core 5 has the version of PAM required... Say, if I grab my kernel's .srpm, modify the spec to it includes this patch, make sure that this patch will play nice with the rest of the Fedora patches and am successful to build and install the generated kernel, how would I make use of the PAM controls to set user-space real-time priorities? PS: I read the thread, but the e-mail containing the pam controls was accidentally erased, were those the ones needed with this patch?

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Lee Revell escribió: I was thinking on adding some low-latency and improved libata drivers amongst other stuff (like staircase sched from CK sources), and if I was going to do that anyway, I thought including the low-latency patches or PAM controls would have been a plus. Thanks a LOT, Lee!

On Wed, 2006-05-24 at 09:17 +1000, Loki Davison wrote: You'd have to copy off all the data, mkfs again, and copy it back. Do you have CONFIG_PREEMPT_BKL=y in the mainline kernel config? ReiserFS 3.x uses it heavily. Also, I never claimed that mainline was OK on all hardware - it does work for me and several others I have talked to. It will heavily depend on the driver set. Did you do: echo 64 > /sys/block/hd*/queue/max_sectors_kb like I described on the ML and my LAC2006 paper? You could also use Ingo's latency tracer patch for the mainline kernel o debug it. Lee

Wednesday 24 May 2006 07:32, Loki Davison: CONFIG_PREEMPT_BKL (Big kernel lock) should be "yes" (on)

On Thu, 2006-05-25 at 01:55 +0200, Wolfgang Woehl wrote: You are confusing preemption (which improves the performance of realtime processes) with the permission to run realtime processes at all (addressed by the realtime LSM, pam, or set_rtlimits). It is also confusing that if JACK is told to start in realtime mode and it does not have permission, it falls back to non-realtime rather than failing to start. This is fixed in the latest development versions. Lee

On 5/25/06, Wolfgang Woehl <tito(a)rumford.de> wrote: One is a mechanism, useful in many domains. The other controls who has access to that mechanism. Some systems don't care (yours pehaps?), others care very much. There is nothing wrong with this as a system design concept. What you and many of us are suffering from is the balkanized implementation of Linux kernels and distributions. The kernel group made some implementation choices a year ago. While those choices were OK, they did not worry about all the peripheral pieces needed to gather them into a useable end-user package. That is not their job. The required components are now available, and are being provided by a few leading-edge distributions. Had you installed Ubuntu Dapper Drake (which is not yet officially released), you would not have seen any problem. They chose to include the PAM patches and authorize all users to start realtime threads be default. That is a reasonable choice for them (given their goals), but would not be appropriate for most other distributions. -- joq

Jack O'Quin wrote: OpenSUSE 10.1, which has been officially released a couple of weeks ago, also is PAM ready. However, it's not OOTB. You'll have to add the relevant entries to /etc/security/limits.conf, like for example these ones where realtime capabilities are given only to users who belong to the "audio" group: @audio - rtprio 90 @audio - nice -10 @audio - memlock 4000000 Cheers. -- rncbc aka Rui Nuno Capela rncbc(a)rncbc.org

On 5/24/06, Lee Revell <rlrevell(a)joe-job.com> wrote: Dapper came up "insecure by default" for me. Knowing about this stuff, I added something similar, restricting access to group "audio". I figured they had done it intentionally (so things would "just work"). Maybe they consider it a bug and have "fixed" it? -- joq

On 5/24/06, Lee Revell <rlrevell(a)joe-job.com> wrote: In the "desktop" environment, which seems to be their focus, it probably isn't a problem. -- joq

On 5/26/06, Wolfgang Woehl <tito(a)rumford.de> wrote: Some do. What we all use in the Linux world is basically POSIX threads with fixed SCHED_FIFO priorities. These cannot be preempted by normal SCHED_OTHER user processes. Going into a loop with realtime priority, effectively locks out all other user processes. The kernel can still run, but not much else. Watchdog threads are typically provided by jackd or other mechanism, but are not built into the kernel. -- joq

paul santa clara wrote: You could be looking at the OSS name for the chipset. on my emu10k1 the oss mixer is called something funky like tritech so and so. does lspci still look right? If not, then you may have data corruption on your pci bus. That happened to me once to where a sb16 card showed up as a whatever manufacturer has the hex code Ox0000. brian

Lee Revell wrote: what about XFS? I am running XFS on my audio partions without any problems...

On Sat, 2006-05-27 at 06:25 -0400, Ivica Ico Bukvic wrote: Wow, ext3 has this?!?!? How do I use it? Lee

gmureddu(a)prodigy.net.mx: No, does not seems so: $ man e2undel 2>/dev/null | grep -A5 'To recove' tion. To recover the data of a deleted file, you must completely rely on the information in the inode like file size, owner, deletion time, etc. ext3 behaves different from ext2 in one regard: When a file is deleted, the information in the inode is also removed. Tools like e2undel (or Ted T'so's debugfs(8)) that rely on this information when undeleting files don't work anymore. $ Both e2undel and recover say the same thing, with ext3 you are on your own. And in this regared ext3 is no different than xfs. The way to recover files left is to something similar to grep. This is what I did (no, grep ... /dev/hda11 did not work wery well) to succesfully recover some text files from a xfs partition (and yes, you must know what to look for, in this case it started with the version string): #include <fcntl.h> #include <stdio.h> #include <stdlib.h> #include <string.h> #include <sys/stat.h> #include <sys/types.h> #include <unistd.h> #define BUFSZ 1024*1024*16 #define EXTRA 40000 char goal[] = "\\version \"2.9.0\""; char buf[BUFSZ+EXTRA]; char nl[] = "\n"; int main(int argc, char * argv[]) { size_t sz; char *ptr; char *sta; int fd = open(argv[1], O_RDONLY); int len = strlen(goal); long long cnt = 0; if (fd < 0) exit(1); while (1) { int avail; sz = read(fd, buf, BUFSZ); if (sz < 1) exit(3); fprintf(stderr, "%16lld\r", cnt); cnt+=sz; sta = buf; avail = sz; while ( (ptr = (char *) memchr(sta, '\\', avail)) ) { int tstlen = len; sta = ptr+1; avail = sz - (ptr-buf); if (avail < tstlen) tstlen = avail; if (!strncmp(goal, ptr, tstlen)) { int plen = EXTRA; if (plen > avail) plen = avail; write(STDOUT_FILENO, ptr, plen); write(STDOUT_FILENO, nl, 1); } } } return 0; } $ ./a.out /dev/hda11 | less Happy hunting /Karl

On 5/23/06, Lee Revell &lt;rlrevell(a)joe-job.com&gt; wrote: Didn't know that. Will I be alright if I have my audio files on ext3 but the OS on reiserfs? alex -- Alex Polite http://flosspick.org - finding the right open source

I think it's more important to place the fifo buffer in shared memory than the choice of your harddisk-fs. Did you check that shm option for the compilation of jack? Is shm enabled (read write excess to /dev/shm)? best regards Martin Am Dienstag 13 Juni 2006 22:43 schrieb Alex Polite: