Hsin-mu Tsai wrote: > I didn't change the nice value (with top or nice, etc.). I thought > enabling the real time setting (gr.enable_realtime_scheduling) in the > script will automatically change priority to (max + min) /2.
I don't actually know what the gr.enable_realtime_scheduling function does; you're probably right. On the other hand I'm not sure that effect is sufficient to get what you want. As I understand it, what the low-latency/realtime scheduling provide are more frequent opportunities for high-priority processes to run. It's sheer speculation but I wonder whether your gnuradio process isn't competing with something else at the same priority, so that giving your process a slight edge in priority might take care of the problem. I spent a great deal of time a couple of years ago trying to balance the JACK daemon against the X server, without much success and a with lot of frozen mice. It's only the most recent patches that really give solid low-latency performance with the current audio subsystems. The performance is very good now, though. > are 'priority' and 'nice' the same thing? Niceness is an increment to the priority value. Nice-ing in the negative direction improves the priority. -- Managing developers is like herding cats. Managing volunteer developers is like herding bats, in the dark. _______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
