On Tuesday 13 February 2007 01:55, terminator356@... wrote:
> Hi, I just spent 4 weeks in distro upgrade hell.
> I'm using Mandriva2005, and having went through hell with
> Mandiva2006 only to conclude it was too broken - not usable for me,
> I tried Mandriva2007. First the emu patch loader ld10k1
> was broken. A week talking to ALSA got that patched. Then
> the supplied QJackctl package was broken. Installed my own latest version.
> Then after all that, it turns out the ALSA pcm 'multi' cards feature is
> broken. No end in sight with that bug. So here I am back in Mandriva2005.
> Remember I said that it's going to be some time before people upgrade
> to QT4 and muse-1.x? Well, there's a prime example why. I mean, just a
> couple of very specific packages that I use, and they were broken.
> Terrible... The good news is that Mandriva2007 has QT4 packages, which I
> have not tried yet. That should allow me to get started on muse-1.x, but
> only if I can solve these problems!
I hear you :-/ been there too. I was driven away from Mandriva partly due to
bugginess.. Using Kubuntu now, quite happy, but if I sit down and try to
recall the things I've changed to get it to work I'll probably regret the
> On February 12, 2007 02:32 am, Robert Jonsson wrote:
> > I noticed that you fixed one of the recent bugs, great!
> > There's another bug "[ lmuse-Bugs-1650953 ] select and move segfault"
> > Could it possibly be the same bug ?
> No. You see, I had intended a weekend 'bug blitz', just to wet my feet
> again. But this Kdevelop/gdb thing shut me out. I'll try again. I really
> don't want to keep using printf statements.
> With this bug, the only thing I found was that if you move the notes
> OUTSIDE (or past) the part length, then muse crashes with an assert at
> line 154 of part.cpp. This may be harder to fix, as it might require
> some kind of 'auto part lengthening' if the user tries to move past the
> part length. Other than that, moving around inside of the part length seems
> fine. Perhaps if the poster of that bug is listening he could verify that
> is the problem.
Ok. Glad you are looking into these things. I see you assigned yourself to it
I think the submitter (Geoff) only reads the user list, but you can get in
touch with him by using the reply field in the bug. That would be the
preferred way, all info will end up in one place.
> PS: How can I make sure that this message is posted as a continuation of
> this thread, rather than dumped on top as a new thread? I don't see
> anything on SF that says 'reply to this message'. Maybe it will be
> automatic? I'll know once I post this.
If you have a decent mail client that will happen automatically. I think
there's somekind of id in the header, but I've really got no idea ;-)
Your mail did get threaded correctly so you probably needn't worry.
> Also, Robert, this may sound stupid after all this time, but what do the RT
> 'priority' numbers mean? Is a higher number a higher priority? Or does a
> lower number have higher priority, as in
> "priority is number 1, top priority".
Not stupid at all. This is a constant subject for discussion. Atleast the
parts relating to system configuration, achieving high RT throughput on a
specific system is still something of an art...
Slightly longer answer than you probably anticipated follows...
When we are talking RT we are generally talking about processes/threads that
have the SCHED_FIFO attribute set. This alters the scheduling algorithm so
one such thread is allowed to execute as long as it likes. This means that if
the scheduling rotation is fast enough we should always get all the work we
need done, in time.
A bonus is that you can lock your machine if, for whatever reason, the
process/thread never yeilds.
The SCHED_FIFO processes do however have priorities too and I believe 99 is
the highest. So a SCHED_FIFO thread with higher priority than the running one
CAN preempt the running thread. In muse there are three RT threads, disk
access, audio and midi, of which midi has the highest priority since it has
higher timing needs. All RT threads need however to execute before the
next "round" happens.
The above locking scenario is commonly solved (in muse too) with a watchdog
thread with the highest priority. So, if the application decides to go for
the loop record the watchdog will terminate the lot.
There's some more random information (mainly about configuration) at Florians
Oh, there's lots of other places too, but nothing structured, and most of it
> Using Tomcat but need to do more? Need to support web services, security?
> Get stuff done quickly with pre-integrated technology to make your job
> easier. Download IBM WebSphere Application Server v.1.0.1 based on Apache
> Lmuse-developer mailing list