Am 28.04.2012 20:56, schrieb Tim E. Real:
> On April 25, 2012 12:26:02 AM Tim E. Real wrote:
>
>> Ooh, here's a near miss and a clue!
>> Almost crashed like the others but it ran. (See my previous printouts)
>> ---------------------------------------------------------------------------
>> Trying ALSA timer...
>> AlsaTimer::initTimer: Calling snd_timer_open
>> timername:hw:CLASS=1,SCLASS=-1,CARD=0,DEV=0,SUBDEV=0
>> snd_timer_open OK
>> AlsaTimer::initTimer: Calling snd_timer_open
>> timername:hw:CLASS=1,SCLASS=-1,CARD=0,DEV=1,SUBDEV=0
>> JACK ERROR: Cannot read socket fd = 11 err = Success
>> JACK ERROR: Cannot read socket fd = 11 err = Success
>> JACK ERROR: Cannot read socket fd = 11 err = Success
>> JACK ERROR: Cannot read socket fd = 11 err = No such file or directory
>> JACK ERROR: Cannot read socket fd = 11 err = No such file or directory
>> Continuing. Error No such device<<<- Apparently took a while to get
>> here, unlike other successes.
>> AlsaTimer::initTimer: Calling snd_timer_open
>> timername:hw:CLASS=1,SCLASS=-1,CARD=0,DEV=2,SUBDEV=0
>> Continuing. Error No such device
>> AlsaTimer::initTimer(): best available ALSA timer: system timer
>> got timer = 70
>>
>> ----------------------
>>
>> But MusE hasn't even initialized the audio drivers nor Jack yet !
>>
>> Look: This crash happens starting from main.cpp line 555:
>> MusEGlobal::muse = new MusEGui::MusE(argc,&argv[optind]);
>> which calls
>> MusECore::initMidiSequencer();
>> ands so on, which eventually calls these timer init routines.
>>
>> It is not until a few lines later in main.cpp at line 565 that:
>> MusEGlobal::muse->seqStart();
>> is called, which calls
>> audio->start()
>> which calls
>> initJackAudio()
>> and so on.
>>
>>
> Oops. I got that wrong. Wrong sequence.
>
> OK after three days intense debugging I found that
> the act of registering an ALSA client in initMidiAlsa(),
> which is called by initMidiDevices() in main(), causes Jack
> to take down MusE a few lines of code later.
> Very puzzling. Jack indeed has been initialized and registered
> by that time, but it has not been activated, so no processing
> is taking place.
>
> So...
> I have completely and radically altered the startup sequence in
> main(), and portions of MusE::MusE have been moved into main().
>
> The results:
> --------------------
> Fixed: No more "Jack calling while audio is disconnected" errors
> at startup (visible with the -D switch). Jack was being activated
> (begin processing) before our Audio object had been initialized.
> Now Jack is not activated until the very last step.
>
> Fixed: LASH leak: Added lash_args_destroy after LASH registered.
>
> Fixed: Icons leak: Oops. Delete all icons !
>
> Fixed: Leak: Function dialogs had NULL parent when created
> with init_function_dialogs() because the MusE object had not
> been created yet.
>
> Fixed: Very many "QPixmap::handle(): Pixmap is not an X11 class pixmap".
> Cause: Somebody added the line "QApplication::setColorSpec()".
> So I added a new command line option '-c' which you *must* now
> specify for the ManyColor Qt option feature (for low-color displays).
>
> -------
> So... Unfortunately, the original problem is still there.
> MusE still crashes randomly at startup.
> Yep, it's definitely that initMidiAlsa() function.
> No matter where I place the caller function initMidiDevices(),
> whether at the beginning of main() or later, Jack crashes MusE
> a few lines AFTER that line. Very strange. Possibly something
> with other Jack registration callbacks, or our ALSA registration
> 'watcher' monitoring callback.
>
> I am unable to solve this ATM, so I have added a new command-line switch
> '-A' which you *MUST* SPECIFY if you really want ALSA devices listed
> WHILE Jack is running.
> It means by default ALSA devices will *no* *longer* be listed if running
> MusE with Jack.
>
> I am wrestling at the moment whether to do the opposite:
> The '-A' switch would then simply *prevent* ALSA from being listed.
> But I'm not fond of turning ALSA on by default for fear of these crashes.
> But I know that turning it off might alarm users with existing projects.
>
> Consider that MusE is now a *fully* Jack-ified application, and as such
> perhaps really ought to list only Jack midi devices when Jack is running.
> Just something to consider...
>
we might want to drop alsa-and-jack-together support. the only thing
alsa is useful for (when jack is running) is for MIDI connections.
a2jmidid offers jack-midi ports for all alsa-midi ports, thus muse can
run with jack and without alsa support perfecly well.
> So what do you guys think? Should option '-A' mean
> "Force ALSA support if running Jack" or should it mean
> "Disable ALSA support if running Jack".
>
> No commits yet, hopefully tonight.
> Please do let me know what you think of that -A switch...
>
honestly, i would propose fixing the actual bug ;) (though i know that
it might be very hard ;) )
maybe we want to add a static bool muse_is_fully_initalized, and all
audio-accessing stuff check this variable. if false, zeroes (and not
undefined stuff) is sent to the device/port, if true the actual stuff.
maybe this might help?
even more honestly, i proposed some time ago, and still propose, to
focus on jack, so that MusE is "a jack-only application which might
support different backends". but the point is that MusE works fine with
jack-only, does not need any backend (and actually, they're useless, as
jack can do anything such a backend can do as well).
the next consideration would be to drop support for all these backends
(because they are useless, jack can do it all. or can't it?)
this would simplify the code, let muse run everywhere where jack runs
(which is: everywhere), and hopefully fix some issues.
(but not before the release)
btw, does this only occur on muse startup? if so, i'd not call it
critical. there is no chance for data loss, and if there are other ways
to start muse with your song, then this is very annoying but not
critical. (and can probably be worked around by my patch (which has been
removed/done properly(?) by tim IIRC): that song-load-timer, which loads
the song 10ms after muse startup)
greetings
flo
> Thanks. Tim.
>
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Lmuse-developer mailing list
> Lmuse-developer@...
> https://lists.sourceforge.net/lists/listinfo/lmuse-developer
>
>
|