On September 20, 2012 7:38:46 PM Tim E. Real wrote:
> > On September 20, 2012 9:15:47 AM Robert Jonsson wrote:
> >
> > Hi Tim,
> > I'll get back more on the rest of the subjects. I just wanted to adress
> > this, quickly.
> >
> >> Darn. I tried all the instructions including
> >>
> >> sudo echo 2048 > /proc/sys/dev/hpet/max-user-freq
> >
> > Did you try doing the echo as pure root?
> > I have found that sometimes (always in kubuntu perhaps?) performing the
>
> above line will do the echo with elevated permissions but the pipe will be
> done as the original user.
>
> > So if you do
> >
> > > sudo bash
> >
> > before, and efter that perform the procedure
> > echo 2048 > /proc/sys/dev/hpet/max-user-freq
> >
> > ...If I'm right we should document this better too.
> >
> > Regards,
> > Robert
>
> Phht... There we go. Thanks a lot!
> I've become so used to sudo on 'buntu. Used to run Mandriva, using su
> always.
>
> OK so RTC is working now.
>
> And I see this in kernel config:
> CONFIG_HPET_EMULATE_RTC=y
>
> So I tested my previous question about Jack ALSA midi driver 'taking' the
> RTC (possibly ALSA itself taking it), if that rule was still valid.
> Nope. Running Jack with the ALSA midi seq driver, MusE is using the RTC.
> Whee...
> I recall that MusE would not use the RTC if something else took it,
> and I recall that in the old days I read that's how the RTC worked.
> That's why I wrote this startup timer error message:
> "fatal error: open /dev/rtc failed: Permission denied"
> hint: check if 'rtc' kernel module is loaded, or used by something else
> I should modify that now.
> Either there's another factor here, or it shows you how long ago I wrote it.
>
> Yet we must be careful, HPET is relatively new, I have PCs here that are
> older
One more thing:
If you look in utils.cpp in the very important function curTime(), you see
commented previous attempts by me to use the higher res clock_*
functions instead of gettimeofday, such as
clock_gettime(CLOCK_MONOTONIC, &t);
clock_gettime(CLOCK_MONOTONIC_RAW, &t);
clock_gettime(CLOCK_REALTIME, &t);
// Only this one works for me. Could be my older kernel...
clock_gettime(CLOCK_PROCESS_CPUTIME_ID, &t);
(I bet they would work now on this newer PC!)
However I recently switched that function to ask the driver for the
time instead, and if the driver isn't running yet to fall back on the
gettimeofday so that section isn't as important now once the Jack
driver is running even if we do use the clock_* functions.
But the dummy driver still uses the old gettimeofday as well, so I
should look at changing these sections to use clock_*.
So mind your Jack clock source setting, MusE asks Jack for the time.
>
> ---
> There doesn't seem to be a printout of the RTC frequency used even with -D,
> so I couldn't tell what was being used (wasn't there a printout before?).
Duh. It's 1024 in the code. Interesting we could set it higher now...
>
> So let me get this correct. I have two paths here:
> /sys/class/rtc/rtc0/max_user_freq
> /proc/sys/dev/hpet/max-user-freq
>
> I poked both of them with 2048. But do I only need the first one?
> When I reboot (can't do it now), /proc.. will be refilled from /sys..?
> I will try the suggestions in the your links about putting the commands
> into an .rc or /etc. Just wondering exactly what to write now...
>
> Thanks.
> Tim.
>
------------------------------------------------------------------------------
Got visibility?
Most devs has no idea what their production app looks like.
Find out how fast your code is with AppDynamics Lite.
http://ad.doubleclick.net/clk;262219671;13503038;y?
http://info.appdynamics.com/FreeJavaPerformanceDownload.html
_______________________________________________
Lmuse-developer mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/lmuse-developer
