arts active but no sound

[Martin Koller]

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

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.

OK. 
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)
    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?
- -- 
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/PgP+HmdPoI37D4YRAl9mAJ9/Ttl+bg5U5GQHBHdzWuSlEVHDqgCgp7QP
Qam6+TyhbWc4rjJ4ATnESbc=
=pMOW
-----END PGP SIGNATURE-----