Re: [Discuss-gnuradio] High packet loss problem (samples dropped?) and fusb parameters

[Frank Brickle]

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.