Re: [Lmuse-developer] More AlsaTimer issues

[Robert J. <ro...@mu...>]

Hi Jonathan,

On Tuesday 09 Aug 2005 04:48, Jonathan Woithe wrote:
> Hi Robert
>
> Find attached the diff between Muse 0.7.2pre1 and my current working code.
> These changes are all detailed in my previous posts to the list on the
> subject.  A few more tweaks might be needed but on the whole the new
> framework should provide the necessary foundation for robust timer handling
> into the future.  The biggest change has been the communication (via
> function return values) between the timer functions and the callers.  It
> makes it easy for the caller to work out whether the requested operation
> has succeeded, and if not the option is always there to try something
> else.

Ok, sounds great!

>
> In particular, the hi-res sequencer timer could possibly benefit from this
> (although I must admit that I can't work out exactly what this timer does).

Someone (Werner 8-) can correct me if I'm wrong, my understanding of this is 
somewhat vague, anyway I think the purpose of this timer is 'timing', i.e. 
increasing the granularity of midi scheduling. 
The tempo is (as you deduct below) dictated by the audio timer.

> For example, if it was a generic Timer one won't know ahead of time whether
> frequencies have to be a multiple of HZ (alsatimer) or a power of 2 (rtc).
> In fact, one can't even assume a value of HZ from 2.6.13 on.  Therefore
> one could try a multiple of jiffies first (as we do now) and if that
> fails we could switch to a power of two and try that.  I haven't done
> any of this yet since the exact approach will depend on how the hi-res
> timer is presented to the user in the GUI - something I understand is
> being considered.
>
> I'll post to the list regarding the use of the hi-res timer.  From my tests
> the actual speed of MIDI events (ie: the tempo) is actually dictated by the
> audio timer rather than the hi-res timer.  If I claim the timer is a
> certain frequency but silently set it to something else the tempo of
> delivered MIDI events is changed.  The hi-res timer clearly does something,
> but I haven't yet been able to work out what.
>
> With this patch and a new alsalib (fixing the timer/vfs ioctl clash), I
> *think* most timer-related problems within muse are fixed.
>
> The patch turns on TIMER_DEBUG in alsatimer.cpp; you'll probably want
> to omit this - it's mainly for my debugging efforts and it activates
> stderr messages which help one work out what's going on.  For example,
> it means stdout tells you why the call to set the hi-res timer frequency
> to 2048 fails (the alsatimer can't do more than 1000).

I've added it in and it seems to work just fine. Infact I already suspect it's 
working much better than before! The lockups related to small jack periods 
and opening songs apparently have vanished (!).

> One final word about the patch: at the end you'll notice a change to
> fdialogbuttons.ui.  This makes "song+data" the default action rather than
> just "song".  You can omit this bit if you want - it has nothing to do with
> the timers.  For me, however, having to continually remember to select
> "song+data" every time I load a song is a real pain (if I don't, all patch
> information is dropped).  I would humby suggest that the default should be
> changed since in general, people will want to load "song+data".  This is
> why I've left this in the patch for your consideration.

Mmm, I'm not sure I follow, what patch info is lost?
Mathias, this is your invention, right? Do you have any comments?

>
> I should point out that when "Open Recent" is used, "song+data" is the
> default (as I contend it should be).  Loading from the command line,
> however, defaults to "song only".  This inconsistency should also be
> cleaned up.

Indeed.

Regards,
Robert
>
> Regards
>   jonathan

-- 
http://spamatica.se/musicsite/