csup breaks sound device output?

[yks]

I've run into a really very interesting issue.

When I do a csup (ports or sources) -- and I do that every day -- something happens to programs which play sound. For instance, play, XMMS and musicpd would occasionally abort playing current file and skip to next, and mpg123 would at all break and use 100% CPU time. I couldn't test this issue on an extensive set of applications because there is a limit on csup connections and I don't have an own server, and because this issue is not just so repeatable, it could occur as well after 1 or 10 minutes of csup'ping but not on every csup nor every 10 minutes... But I am sure that the issue is related to csup because I use my PC at least 8 hours a day and all this time music is being played, and it breaks only when csup'ping. I wonder only HOW csup could be linked to sound/or kernel?

My system is:
FreeBSD 8.1-RELEASE amd64, custom kernel, snd_hda driver.

By the way, something like this occurred on 8.0-RELEASE but I didn't use csup that often to pay attention.

 

[DutchDaemon]

Try with a [cmd=]nice -n 20 csup .. etc.[/cmd]

Sounds like csup is simply starving resources and competing with your (hungry) multimedia apps.

 

[Galactic_Dominator]

Your problem is IO contention, not csup. Hard drives are slow, and when you run concurrent IO intensive tasks something has to give. Lowering the priority as mentioned above is the cleanest 1 off solution for something like this, but it may not solve a larger problem if you're using a lot of IO intensive apps. Things that help permanently are AHCI enabled systems w/ NCQ, gsched(), gjournal(), or vfs.read_max=128 if on a UFS system which seems likely in your case.