arts active but no sound
m.koller at surfeu.at
Sat Aug 16 11:14:20 BST 2003
-----BEGIN PGP SIGNED MESSAGE-----
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 ?
I started always as root.
> > > > ps -ef|grep arts
> > > > root 24406 23395 1 15:23 pts/7 00:03:34 artsd -l 0
> > > > root 24408 24406 0 15:23 pts/7 00:00:00 artsd -l 0
> > >
> > > So you started it manually with debug output. Is there anything the
> > > debug output could tell?
> > Yes.
> > e.g. that artsd started, but doesn't use oss or whatever, but instead
> > using null
> Very interesting, since artsshell said, that artsd is properly using the
> oss device. It really looks like there are two artsds running. Oh, did you
> do all your testing as root?
Yes, all as root.
> > BTW: what is the sense behind running artsd with the null-output device ?
> > If I can't hear anything, what is it worth having artsd running?
> artsd is more than a mixer daemon. You can also grab the output stream and
> record it to disk or beam it to another computer over the network. So the
> null output device has it's uses. I KDE it's mainly used so that programs
> expecting artsd to be there don't fail.
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.
> > > > BTW: Is there any possibility to cancel a job which is displayed in
> > > > the audio- manager of artscontrol?
> > >
> > > If you know what process is holding a reference to the
> > > AudioMangerClient you can kill that process, but there's nothing artsd
> > > can do.
> > I don't know how artsd is working with multiple processes, but
> > can artsd not simply close the connection to a process, or clean the
> > queue?
> The problem is, that artsd might be able to delete the AudioManagerClient
> but it cannot stop the process that created the Client. This would most
> probably result in a crash of the process that was using the Client.
> Just in case this isn't clear: aRts uses MCOP for IPC - something
> CORBA-like, optimized for multimedia - meaning, that another program can
> create objects in the artsd process while the control of those objects
> remains in the other process. Now you see, if you just delete those objects
> the controling process is bound to have a problem.
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 ?
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)
#7 0x0805b54e in VControl::showAudioManager (this=0x8137e78) at main.cpp:384
#8 0x08057fd5 in VControl::qt_invoke (this=0x8137e78, _id=53, _o=0xbfffed70)
Is this a bug in artscontrol or is it the behaviour "by design" as you
Best regards/Schöne Grüße
Public key at:
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org
-----END PGP SIGNATURE-----
More information about the kde-multimedia