arts active but no sound

Matthias Kretz kretz at
Sat Aug 16 13:46:10 BST 2003

On Saturday August 16 2003 12:14, Martin Koller wrote:
> On Saturday 16 August 2003 11:04, Matthias Kretz wrote:
> > On Friday August 15 2003 19:15, Martin Koller wrote:
> > > I'll try to test it - maybe there were really two instances of arts
> > > running. Hmm .. this shouldn't be possible, right?
> >
> > 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.

> 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.

> 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...

> 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.

Matthias Kretz (Germany)                          <><
MatthiasKretz at, kretz at,
Matthias.Kretz at
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: signature
URL: <>
-------------- next part --------------
kde-multimedia mailing list
kde-multimedia at

More information about the kde-multimedia mailing list