Arts for X thin clients
Chris de Vidal
chris at devidal.tv
Wed Mar 31 15:37:11 BST 2004
Stefan Westerfeld said:
> > I have an X thin client. The .mcoprc has had both
> > GlobalComm=Arts::X11GlobalComm (which prevents artsd from starting)
> > and GlobalComm=Arts::TmpGlobalComm. I run artsd -n -F 5 -S 8192 &
> > then X -query <X terminal server>.
> You need to start artsd on the thin client after having logged in, if you
> want to use Arts::X11GlobalComm (and you will probably want to do
> so, if you want to use artsd remotely, see below).
I believe I had even tried that. Let's see... I logged into KDE remotely
then SSHed into the X thin client (the actual X server... am I the only
one that finds X server/client terms confusing??) from the X terminal
server (where KDE actually executes). In the SSH session on the X thin
client (X server) using the same username that the X server was running
under (root), I ran
export DISPLAY=:0 # since the X server on the X thin client is
# running essentially as localhost
echo GlobalComm=Arts::X11GlobalComm > ~/.mcoprc
artsd -n -F 5 -S 8192
I believe I got the same error message as when I tried to start it with no
X server running and when I . So it doesn't seem to flow as advertised.
I then ran xcalc which showed up on the X terminal server and back on my
remote X thin client (the X server), so I know I was authenticated
properly and my display variable was set correctly.
I could try it again and report the error message.
> > I haven't gotten _any_ answer. When I read similar threads on this
> > list I see no answers. It's almost as if the KDE people know it's
> > broken but aren't saying so :-/
> Well, so lets fix this here: its broken.
Ahh, thanks for your honesty :-)
> There are three reasons:
> (a) its hard to get client and server find each other
> If both run locally, this happens by reading files in
> which say which tcp host/port or unix domain socket to connect
> (GlobalComm=Arts::TmpGlobalComm in .mcoprc). Of course, if you are running
> on different hosts, this doesn't work, since they have different /tmp
> Thats why Arts::X11GlobalComm was invented, which exchanges the
> over the X11 server. However, this implies that you have the X11 server up
> and running _before_ starting artsd, and that client and server share the
> same display. You can't start artsd and then log in.
I tried this too; see above.
> An alternative but unsupported/undocumented way is to use the
> ARTS_SERVER=host:port variable ; however, this does not work well with
> authentication, so you can practically only use it with -u, which is
I also tried something like this:
ssh user at host "artsd -n" & # The X thin client with the sound card
artsrec | ARTS_SERVER=host:port artsrec
xmms --play # no sound
I could repeat this experiement, but I recall seeing auth errors. Perhaps
I need to test the -u flag as you suggest.
> (b) its hard to get client and server authenticate to each other
> Basically, either you run with -u, or you use Arts::X11GlobalComm, or you
> use artsd only locally.
> (c) what you get might not be what you want
> Usually, people expect that applications like noatun read and decode an
> mp3, and artsd outputs the decoded data to the soundcard. What really
> happens is however that applications like noatun tell artsd to read and
> decode an mp3, and output it to the soundcard. This means two things:
OK this explains alot. arts isn't a sound conduit so much as it is a
front-end for an mp3/wav player.
> - both hosts need to have a reasonably similar file system (i.e. NFS
> mounted homes) otherwise, you will click on a file in noatun, which
> then can't be played
> - the cpu load will occur on the host running artsd, not on the host
> running noatun
Well I suppose this is OK considering I'm on a 10MBit shared-media network
and mp3s stream much better when compressed. But it isn't what I was
> This also indicates it is a very bad idea to run artsd as root for all
> users, as you can then exploit the situation (as user) and tell artsd to
> read security critical files, load .so files and execute arbitary code
> as root, and so on.
> > I did find a page for LTSP on recompiling arts with nas support. It's
> > an ugly hack but it should do what we want it to do (although I haven't
> > had time to try it). Here's the page:
> > http://www.ncpl.lib.in.us/~rjune/lbe/LTSP-arts-howto.html
> Yes, in fact my recommendation for most users who want to use KDE in a
> setup where they log in remotely, is to select a pure sound server (MAS,
> NAS or ESD), and configure KDE to use it. Most of the time, that will be
> less work, and you will probably get what you expected to get in the first
Do you know of more websites/resources like the above which document using
NAS/ESD/MAS with arts?
Thanks for the enlightenment,
More information about the kde-multimedia