We see the kernel msg: rtc: [number] > kern.hz: Timing will be inaccurate, please increase hz. on the console as well as in /var/log/messages (maybe dmesg) even when [number] and kern.hz are the same value or close to each other. Fix: I don't know much about this, but it sure seems rtc.c is comparing apples with soccerballs ;) . I have been using the following patch for many many weeks so far: ===cut-here=== FWIW I will usually use 500 for kern.hz et al. as it is more evenly-divisable for other related system parms. Also FWIW this "puny p2" machine really slows down if kern.hz gets close to or over 1000 for kern.hz; this slowdown really shows while running KDE or Gnome. <sigh> At any rate, I'm not so interested in atomic-level accuracy here, but rather have a cleaner log, since this particular msg is issued every single time mplayer is invoked. ;) Besides, wouldn't the accuracy be 'best' if both were set to exactly the same value? -- thx, Paul Seniura System Specialist State of Okla. D.O.T.--B76hPAsPuvfkoVoxgkXTxMq1khh5EBbFdImPT7hSr14P3l0b Content-Type: text/plain; name="file.diff" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="file.diff" diff -ur files_orig/rtc.c files/rtc.c --- files_orig/rtc.c Thu Jun 24 08:54:46 2004 +++ files/rtc.c Wed Sep 8 17:11:56 2004 @@ -268,7 +268,7 @@ break; } sc->var.freq = freq; - if (sc->var.freq * 9 > hz * 8) { + if (sc->var.freq > hz) { sc->var.freq = hz; printf("rtc: %d > kern.hz: Timing will be inaccurate, please increase hz.\n", sc->var.freq); } ===cut-here=== How-To-Repeat: (1) Choose a suitable kern.hz value that your machine can handle. For the "puny p2" I'm using here at work, I set this to 512 for testing. (2) Add a line in your /boot/loader.conf to set kern.hz to the same value e.g. for me: kern.hz="512" . (3) Compile the port multimedia/mplayer with WITH_RTC=yes and WITH_KERN_HZ=[number] set in your /etc/make.conf e.g. for me: WITH_KERN_HZ=512 . (4) Compile & install emulators/rtc normally. Load rtc.ko and ensure /dev/rtc is ready to be used etc. (5) Test the freshly-built mplayer with any supported sound file i.e. something simple. I test this on a local ttyv session with no X running at all. (6) Look at your console and/or /var/log/messages (maybe dmesg) to see the 'Timing will be inaccurate' msg is logged.
Responsible Changed From-To: freebsd-ports-bugs->emulation Over to maintainer(s).
Responsible Changed From-To: emulation->silby I'll take care of this
I had the same problem as you do. As you noticed, Mplayer defaults HZ to 1024 and I found my kernel was set to 1000 hz by default. My kernel would output : rtc: 1000 > kern.hz: Timing will be inaccurate, please increase hz. when mplayer ran. I tried adding to my kernel conf to match mplayer's default: options HZ=1024 and yet I still got the message. After searching on the net, I found that you had to set a higher value in the kernel as there is apparently no true synchronisation with RTC and mplayer. So setting: options HZ=1160 fixed it for me. In your case, try setting around 600 in the kernel to see if that does it. Nicolas.
State Changed From-To: open->feedback Is the workaround proposed in this PR sufficient to solve the problem?
State Changed From-To: feedback->closed Annoying message has been removed, with addition that it will never bug if you have hz set to 1000 or greater.