>> + if [ -x /bin/nice ]; then
> maybe this is a better abstraction:
> which nice >/dev/null && {
Fine by me (I don't use it myself because it's less standard, and
because I know the kind of input it returns on stdout, but not the kind
of status it returns).
>> + # This has real-time constraints, so let's at least tell the OS
>> + # that this should have higher priority to avoid skipping
>> + # when doing other things in the background.
>> + nice="nice -n -20"
>> + fi
>> + $nice /usr/bin/mpd
> really '-20' ? maybe this is _to_ high?
These are not real-time priorities, so other processes can still take
precedence on occasion (i.e. there's no risk of completely starving
other processes). Still, I wonder: what other process should have
higher priority? Audio glitches are the ones to which the human is most
sensitive after all. I.e. I think a real-time priority would be a good
choice as well, tho it is more risky (in case the MPD daemon goes
haywire or is asked to decode/encode more than the CPU can take).
In any case, if it's necessary to reduce this in order for the patch to
be acceptable, that's fine by me: I haven't actually tried any lower
setting anyway.
Still, I regularly make my OpenWRT box work (rsync/NFSd/apt-get) at the
same time as playing music and this patch had no noticeable negative
influence on the other processes (and significantly reduced skipping).
Stefan
_______________________________________________
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
http://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
