2012/9/19 Tim E. Real <firstname.lastname@example.org>
On September 19, 2012 12:55:26 AM Tim E. Real wrote:Rats!
> Ya know, there *is* another old timer which MusE supports:
> Ye olde RTC Clock.
> When you start MusE (possibly with debug messages), do you
> see any messages about the RTC clock? Permission denied?
> I haven't gotten the RTC clock to work for a long time but I think
> Robert wrote some info about poking the /proc tree to make it work.
> Try the README.
First of all there's outdated info in the README.
Where it says:
- make sure MusE can set the rtc clock:
echo 8192 > /proc/sys/dev/rtc/max-user-freq
That should read /sys/class/rtc/rtc0/max_user_freq.
At least here on *buntu.
Can someone change it if I don't get to it?
I'll give it a shot tonight if time permits... Thing is I had done improved instructions for this on the webpage but it seems it got lost with the unfortunate rollback of the server. I forgot to put it in the README, in which case all would have been well.
Second, the frequency here is stuck at a paltry 64 !
When I try to poke it I get permission denied.
This is one of the things that can be reconfigured which I listed before. I believe it's another proc/sys register.
And that's with desktop OR low-latency kernels. Crud !
So MusE still fails RTC when it tries to set it to 1024,
and so falls back to ALSA timer as usual.
+1 For a new HP timer driver.
And optional ALSA - of course, Flo!
Yeah, about that. I haven't gotten around to debate this, I thought I would just voice a slight reluctance for this.
Making ALSA optional, to remove a dependency is well and all, but I worry it means changing the internals in a way that we loose timing, both latency and jitter.
This is mostly just a fear and it's not necessarily true, I just wish us to be aware of this risk.
I'm not sure how this is implemented in jack but running with big buffers won't that directly incur a latency penalty that we are completely immune to with the alsa sequencer support?