Gentoo Forums
Gentoo Forums
Gentoo Forums
Quick Search: in
HOWTO: Remote X terminal with sound using arts
View unanswered posts
View posts from last 24 hours

 
Reply to topic    Gentoo Forums Forum Index Documentation, Tips & Tricks
View previous topic :: View next topic  
Author Message
radg
n00b
n00b


Joined: 14 Aug 2004
Posts: 33
Location: Edinburgh, UK

PostPosted: Tue Sep 14, 2004 12:20 pm    Post subject: HOWTO: Remote X terminal with sound using arts Reply with quote

Picture the scene: I have my big, fast and noisy machine hidden away in a cupboard and a small and nearly silent box under my desk to work on. This machine can be so low noise that it doesn't even have a harddrive and is booting over the network. I can run all my apps on the faster box and have them displayed and controlled from my desk. I can now actually hear myself think again and can get on with some work. Or more likely I can just listen to my music collection in peace...

I've got this working really quite well using XDMCP and KDE and I've been using this happily for about a month.

This setup uses arts for the sound networking so only KDE apps (in general) will work with sound over the network. All other apps will work fine, but no sound.

Firstly on the server (the fast box) enable XDMCP. I'll assume you already have kdm working. In /usr/kde/3.3/share/config/kdm/kdmrc:
Code:
[Xdmcp]
Enable=true
and in /usr/kde/3.3/share/config/kdm/Xaccess:
Code:
*                                       #any host can get a login window

Don't forget to restart kdm.

Next on the client we will run the X server. Hmm, the X terminology really seems back to front sometimes... Anyway, after you have a basic booting Gentoo installation on the client:
Code:
emerge xorg-x11

Here is a script I wrote to start X on the client:
Code:
#!/sbin/runscript
 
depend() {
   need net
}

start() {
   ebegin "Starting X terminal"
   start-stop-daemon --quiet --start --background --pidfile /var/run/xterminal.pid --make-pidfile --exec /usr/X11R6/bin/X -- -broadcast
   eend $? "Failed to start X terminal"
}

stop() {
   ebegin "Stopping X terminal"
   start-stop-daemon --quiet --stop --pidfile /var/run/xterminal.pid --exec /usr/X11R6/bin/X
   eend $? "Failed to stop X terminal"
}

Copy this to /etc/init.d/xterminal and add it to the default runlevel.

Now you should have a working remote X session using kdm to log you in. Nothing new so far really. However after a while of enjoying the silence you realise it is a bit too quiet and in fact there is no sound coming from the client box. Now the fun starts.

First thing to do is
Code:
emerge arts
on the client. Then run KDE Control Center and disable sound in the "Sound System" applet. Then you need to edit the file ~/.mcoprc to read
Code:
GlobalComm=Arts::X11GlobalComm

NB: keep an eye on this file, if things aren't working it is likely that arts has changed this file behind your back. It's very annoying and I haven't spotted a pattern to when it happens, but it does. If you have to fix this file, then you also have log out and in again to get things to work.

OK, nearly there. The last trick is to put this code in your ~/.xprofile:
Code:
# run arts on the machine with the display
localhost=${HOSTNAME%%.*}
displayhost=${DISPLAY%%:*}
if [ -z "$displayhost" -o "$displayhost" != "localhost" -o "$displayhost" != "$localhost" ]; then
        artscmd=`which artswrapper`
        if [ -x "$artscmd" ]; then
                ssh -X $displayhost $artscmd -n -d &
        fi
fi
What this does is to run the arts daemon on the client box whenever you log from a remote X terminal. Note for this to work you need to have
Code:
X11Forwarding yes
in the /etc/ssh/sshd_config on the client box and of course the ssh server must be running.

OK, if everything went well you should be able to sit back and enjoy using your really fast PC without the attendant din. It really does make a difference I think.

Problems
Unfortunately there is a problem with noatun and this setup so it doesn't work.
To get System Notifications to work you need to either:
    configure the external player to 'artsdsp aplay'
    configure the external player to artsplay and copy all the system notification sounds to the client machine

Yes the latency is quite high...

Troubleshooting
The best way to figure out problems is to kill the artsd on the client (it needs a kill -9 for some reason) and run:
Code:
ssh -X <clientmachine> `which artswrapper` -n -d
to see the arts messages and hopefully some clue as to what is going wrong.
Back to top
View user's profile Send private message
RexM
n00b
n00b


Joined: 12 Aug 2004
Posts: 47
Location: South Jordan, Utah

PostPosted: Wed Sep 15, 2004 2:58 pm    Post subject: Reply with quote

This sounds pretty usefull, the problem is I don't even have a powerful machine that makes a lot of noise :(
Back to top
View user's profile Send private message
kendowns
n00b
n00b


Joined: 02 Dec 2002
Posts: 17

PostPosted: Sun Jan 16, 2005 11:56 pm    Post subject: Reply with quote

radg, thanks for the nice post. Here is some additional information as well as an *INSECURE* way to rig this up w/o ssh.

Consider two boxen, which we'll call the workstation and the remote. The workstation is the machine you've got sound, speakers, keyboard, mouse and display, the one you are sitting in front of. The server is some remote headless machine in East Flamboolia. You use XDMCP to sit in front of the workstation and run a session on the server, and you want sound.

As a general comment, I would point out the biggest weak spot is the apps. Getting the infrastructure going is easy, but we are not yet in the land beyond the rainbow where you click anything and it JustWorks(tm).

To get a feel for how this works, on the workstation type this command as root:

Code:

# artswrapper -u -n -p 7899


This runs the arts server on the workstation. The -n option makes it network aware, the -p 7899 has it listen on port 7899 (you can pick any port). The -u is what makes it so insecure. This option allows anybody to connect from anywhere. If you are behind a firewall and you personally know everyone on the net, you are probably ok, such as at home. At best your teenagers will send sound to each other's machines. But at worst a remote exploit for artsd will allow somebody to root your box. You have been warned.

Now go to your X-terminal session (which is actually running on the remote box) and try this:

Code:

$ export ARTS_SERVER=workstation.ip:7899
$ artscat somefile.wav


If you don't have a .wav file handy pull one off a cd, or use lame to make one out of an mp3:

Code:

$ lame --decode somefile.mp3


...which will produce somefile.mp3.wav.

The magic here is that arts-aware apps look for that ARTS_SERVER environment variable, and if it exists they send the output there, instead of firing up a local artsd instance. The artscat is like a "cat" for sound files, and allows you to discover how arts is going to behave, because whatever artscat does is what the other arts apps will do.

If you can't get this working then there is no bother continuing. This is your basic reality check. When this works, you know that the copy of artsd on the workstation is capable of receiving connections and that the remote machine can send them.

Now we are ready to set it up so it works for free automatically. First is the workstation. You need the arts server always running on the workstation, network aware, regardless of what the user does. There are two disclaimers to what we are about to do. The first disclaimer is that we are going to run what is probably a weak app as root, receiving network traffic. This makes it suitable only for small tightly-controlled nets behind firewalls, and really nowhere else. Second, I saw artsd segfaulting on one box (SuSE 8.0 on an old P166), so when that happens the user will be stuck (you can relaunch it if you know how, but family members will either reboot or give up). That being said, try adding this to the workstation's /etc/inittab, near the bottom:

Code:

arts:<default runlevel>:wait:/path/to/artswrapper -n -u -p 7899 &


OK, so much for the workstation. From here on out everything we do is done on the remote system, though of course it is done sitting in our X-terminal session at the workstation. Now we want apps running on the remote system (but displayed locally) to send their sound to the local workstation. For this we need two things. We need to assign the ARTS_SERVER environment variable, and we need everything to send output to arts.

To set the environment variable, we will take radg's code from above and modify it slightly:

Code:

# set ARTS_SERVER variable
 localhost=${HOSTNAME%%.*}
 displayhost=${DISPLAY%%:*}
 if [ -z "$displayhost" -o "$displayhost" != "localhost" -o "$displayhost" != "$localhost" ]; then
   export ARTS_SERVER=$displayhost:7899
 fi


...where again the use of 7899 as the port number is arbitrary, so long as it matches the port on the workstation. This must be saved into your ~/.xprofile. Log out and back in.

From here everything depends on the application and how "well behaved" it is. In principle any app can be fooled into using arts by invoking it with the command "artsdsp <app>" but that is not universally true, some trial and error is still necessary. Here are some things I've found:

1) Macromedia flash apps *will* work, hooray hooray. If you have not installed flash yet, then emerge "netscape-flash" and go to Konqueror and scan for plugins so it will be recognized. Then start konqueror with "artsdsp konqueror" and check out your favorite flash animation. Modifying your konqueror shortcut is probably a good idea for this.

2) gxine works out of the box (at least the version I tried, 0.3.3), but you do have to go into preferences and tell it to use arts.

3) XMMS simply refused to do what I told it to, so I gave up. Maybe somebody knows something I don't.

4) Noatun version 2.4.1 in KDE 3.2.2 would not work no matter what, but Noatun 2.6.1 in KDE 3.3.2 worked first time with no tweaking.

One final note. I actually forgot all about ~/.mcoprc and never changed it, it does not seem necessary to do so.

Hope this helps everyone, enjoy!
_________________
Every application wants to be a database application when it grows up
Back to top
View user's profile Send private message
slick
Bodhisattva
Bodhisattva


Joined: 20 Apr 2003
Posts: 3495

PostPosted: Sat Feb 18, 2006 6:18 pm    Post subject: Reply with quote

works fine, thanks kendowns
Back to top
View user's profile Send private message
slick
Bodhisattva
Bodhisattva


Joined: 20 Apr 2003
Posts: 3495

PostPosted: Tue Feb 21, 2006 7:33 am    Post subject: Reply with quote

On my client the artswrapper crashs every time I logout from the remote maschine. I not found the problem, so I write a bad workaround to keep artswrapper alive every time while /etc/init.d/local is started (/tmp must not mounted with noexec or take another path)

/etc/conf.d/local.start
Code:
source /etc/conf.d/rc
echo "while [ -e ${svcdir}/started/local ] ; do /path/to/artswrapper -u -n -p 7899 &> /dev/null ; done" > /tmp/artswrapper.sh
chmod +x /tmp/artswrapper.sh
/tmp/artswrapper.sh &> /dev/null  &
Back to top
View user's profile Send private message
Display posts from previous:   
Reply to topic    Gentoo Forums Forum Index Documentation, Tips & Tricks All times are GMT
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum