Re: [Lmuse-developer] MusE on FreeBSD or other non-linuxes?

[Robert J. <spa...@gm...>]

2012/9/19 Tim E. Real <ter...@ro...>

> On September 19, 2012 12:55:26 AM Tim E. Real wrote:
> > 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.
>
> Rats!
> 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
>             inspect with:
>             cat /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?

Regards,
Robert