arts active but no sound

[Martin Koller]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

> > > It is possible, AFAIK, if one is started with X11GlobalComm and the
> > > other one with TmpGlobalComm - or if they're started from different
> > > users.
> >
> > Sorry, I don't understand. What is the *Comm stuff ?
>
> It's defined in ~/.mcoprc
> It tells artsd how to communicate with other processes. Something you
> normally leave set to TmpGlobalComm.

OK, it is.

>
> > Hmm ... I'm thinking about usability: If a user defines in kcontrol to
> > use some sound I/O method != null, then why should artsd still be running
> > when it cannot use some methode != null ?
> > It might be the case that some KDE apps don't fail in this case, but
> > isn't it also a failure if they expect to be able to output sound, but
> > the user doesn't hear it?
> > I think, this situation could be worse than if artsd doesn't run at all
> > but instead tells the user that there is a serious problem.
>
> Well, on startup artsd does complain that it couldn't open the sound device
> and that it's using the null output now. You can tell it to never display
> that message again, though.
>
> And what about users without soundcard? They perhaps want to watch a video
> but know already that they won't get any sound.

Yes, good point. But: If artsd _could_ use a soundcard, it _should_ do it or 
stop (or retry later, etc.).
If there is no soundcard, then it should not issue this warning, because then 
it is not a failure.

>
> > Maybe my situation is a special uncommon problem - still one question:
> > The object which is created inside artsd, does it have e.g. the PID of
> > the creating process ?
> > If not - what about adding this feature ?
>
> It does not know the PID. And does not make sense to have it, since the
> process could as well be running on another computer in your network. And
> this whole thing is about working around problems - it's nothing that I see
> helping aRts directly...

OK, accepted.

> > Also what I easily can reproduce is the crash you mentioned: I start
> > artscontrol, then kill artsd via "artsshell terminate", then start in
> > artscontrol the audio-manager -> crash of artscontrol.
> >
> > #5  <signal handler called>
> > #6  0x0805c4d2 in Gui_AUDIO_MANAGER::Gui_AUDIO_MANAGER (this=0x816ef60)
> >     at /opt/kde3/include/arts/artsflow.h:2110
> > #7  0x0805b54e in VControl::showAudioManager (this=0x8137e78) at
> > main.cpp:384 #8  0x08057fd5 in VControl::qt_invoke (this=0x8137e78,
> > _id=53, _o=0xbfffed70) at main.moc:506
> >
> > Is this a bug in artscontrol or is it the behaviour "by design" as you
> > explained above?
>
> This is a bug resulting from this "problem" of distributed objects.
> Artscontrol shouldn't crash, though, there's a missing check before the
> AudioManger object is used.

Shall I submit a bug report, a patch or both ?
- -- 
Best regards/Schöne Grüße

Martin

Public key at:
http://blackhole.pca.dfn.de:11371/pks/lookup?op=get&search=0x8DFB0F86
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE/PknuHmdPoI37D4YRAi+kAKCGvI9UhFJ9heRjQjvUL+aFmfaGogCgvUMl
JcwTE75tvs9hCh5BP9kXW2w=
=4yaJ
-----END PGP SIGNATURE-----