>> Then maybe I should report a bug: if I don't start mpd with "nice -10",
>> I get skips on a regular basis, and it becomes unbearable as soon as
>> I run other things in the background (typically rsync-over-ssh since
>> I use the same box for my backups). I didn't report it since "nice -10"
>> fixed it, and such things just seem fairly normal to me (tho, maybe mpd
>> should/could do the "nice 10" itself when run as root).
> Only a real-time kernel can guarantee that MPD doesn't skip (provided
> that the hardware is fast enough). Linux is not a real-time OS.
> What we do on Linux is use large buffers, and hope that there will
> never be a delay longer than our buffer size. If other processes take
> so much CPU or induce much latency (by blocking disk I/O, e.g.), MPD
> can not compensate, and you hear skips. In that case, increase MPD's
> scheduler priority (negative nice level) to reduce the probability.
That was my reasoning indeed. The machine is seriously underpowered
(266MHz, MPD takes about 20-30% CPU when playing an Ogg song) and its
64MB makes it swap fairly heavily when large rsync processes are running.
> Of course, that rule of thumb is too easy for the real world. There
> may be bugs in MPD which increase the probability of skips, and there
> may be a lot of room for optimization. We will attempt to optimize
> when we can measure such problems on a test system. During the 0.15
> development, MPD's internal latency has been reduced by orders of
> magnitude, most of that with the implementation of reference counted
> pages.
> Which MPD version were you using, Stefan?
I've seen such skips with both 0.13 and 0.14. Haven't tried 0.15, but
really I don't think it's unreasonable to require "nice -10" in
such circumstances.
Stefan
------------------------------------------------------------------------------
_______________________________________________
Musicpd-dev-team mailing list
Musicpd-dev-team@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/musicpd-dev-team
