I'm not getting segfaults like Wade is, using pd 0.37-4 + jack + realtime-lsm. I just can't convince PD to start in realtime as a user. It works on my other computer, but not the one I'm at now. Somebody please refresh my memory and tell me what magic I did to make it work before :-)
Im using 0.38-0test13 because Millers source didnt compile on my x86_64 when last I tried. Also I have been told that using the -jack and -rt flags is a oxymoron. The -rt flag is for alsa and the -jack is (obviously) for jack. What we should be able to do is run jackd as user and pd as user, jackd gets priority in the scheduler by virtue of realtime-lsm and pd connects to jack. I guess that jackd is the only part of the system that needs priority in the scheduler...
For some reason I can run jackd as user no problem, and I can run pd as user if its run fom within gdb, albeit with TONS of DIO errors, but I cannot run pd as user normally as I get the afor mentioned segfault.
If it helps with figuring out where the segfault occurs, the pd window gui flashes onto the screen quickly right before the segfault. If I dont miss my mark, pd initializes the gui then starts parsing the flags in .pdrc, which means that when it hits the -jack flag (first in the list) it trys to connect to jackd and the segfault occurs. Right?
-thewade
Hi Wade,
thewade wrote:
Im using 0.38-0test13 because Millers source didnt compile on my x86_64 when last I tried. Also I have been told that using the -jack and -rt flags is a oxymoron. The -rt flag is for alsa and the -jack is (obviously) for jack.
mmmm... as per my earlier response to that comment of Fernando's... sorry, but I just don't buy it.
I can run jackd realtime, connect to it with PD w/o realtime, and I still get dropouts when I move PD windows around which Jack doesn't even notice. I think the -rt flag has more function than simply an ALSA interface, but also has to do with kernel processes. Still waiting for a clear explaination from the developers about this, but the closest thing I have found is from Frank Barknecht [I beleive in answer to a question of yours]:
Frank Barknecht wrote:
This is a bit complicated to explain, but I'll try my best as far as I understand it:
Linux, being a true multitasking/multiuser sytem, has many processes running concurrently. But there is only a limited amount of ressources available (one or two or more CPUs, ...) so there must be an instance, that keeps track of when a processes turn is coming. This instance is the so called Scheduler in the Linux kernel. Normally this Scheduler just more or less evenly divides the ressources and processor times between processes. But it is possible, that a process might require more or more immediate action. This is quite typical in our audio world: If you want to record something, you cannot afford a single lost sample, whereas an email transport doesn't care for several seconds more wait.
To get the scheduler to play nicer with (audio) processes these processes need to be "scheduled higher". For security reasons only the root user is allowed to do that per default. (There are several other solutions for this: Capabilities, Linux Security Modules and maybe more).
So if Pd is run by root or has been setuid root, it tries to convince the Scheduler, that it is more equal than other processes. If you look into src/s_inter.c, you will see several things happen that have names with "sched" like "sched_get_priority_max" in set_priority. This is the realtime scheduling in Pd on Linux (and maybe OS-X).
thewade wrote:
What we should be able to do is run jackd as user and pd as user, jackd gets priority in the scheduler by virtue of realtime-lsm and pd connects to jack. I guess that jackd is the only part of the system that needs priority in the scheduler...
In theory yes, but in practice no way. Running *both* PD and Jack realtime is the only setup which has ever been useful for me to do live performance, or even to reap the benefits of having a Hammerfall soundcard.
d.
-
derek holzer -
thewade