Right now (SVN r479), darkice uses sched_get_priority_max()-1 as the
scheduler priority for its realtime threads.
Though this might be ok for ALSA/OSS sources, it doesn't make sense when
using jackd.
The attached patch adds a new config item "rtprio" to the general section
and provides a sensible default for jackd use.
Rationale is part of the code.
Resulting RT levels look like this:
adi@hex:~$ for i in $(ls /proc/`pgrep -x darkice`/task/) ; do chrt -p $i ;
done
pid 11407's current scheduling policy: SCHED_FIFO
pid 11407's current scheduling priority: 4
pid 11408's current scheduling policy: SCHED_FIFO
pid 11408's current scheduling priority: 4
pid 11409's current scheduling policy: SCHED_FIFO
pid 11409's current scheduling priority: 4
pid 11410's current scheduling policy: SCHED_FIFO
pid 11410's current scheduling priority: 5
pid 11411's current scheduling policy: SCHED_FIFO
pid 11411's current scheduling priority: 1
This is fine: the jackd callback thread is at 5 while the encoder threads
are at 4. This way, darkice's input buffer can always be filled, because
all jackd threads have higher priority. This should fix the buffer underrun
in issue 11. (don't know how to link to the ticket)
Cheerio
Original issue reported on code.google.com by a...@drcomp.erfurt.thur.de on 16 May 2010 at 7:44
Original issue reported on code.google.com by
a...@drcomp.erfurt.thur.de
on 16 May 2010 at 7:44Attachments: