Streaming audio between Linux machines

My laptop, being my mobile machine, contains all of the music I listen to on a daily basis. At home, it's nice to hook it up to my stereo so I can hear it throughout the house. However, while there is music playing, the laptop is no longer mobile and stuck within a three-foot leash of the stereo.

Having recently resurrected an old desktop to function as a MythTV, DVD-watching and backup machine and wired it into the stereo, it was extremely simplistic to stream the audio wirelessly from my laptop and have it be received on the desktop, to be piped into the stereo.

For this guide, I am utilizing Fedora 9 on the laptop (client) and freshly-installed Fedora 12 (server) with glibc on the desktop, although this should work on any Linux distro. You will need the following packages on both machines:

pulseaudio
pulseaudio-module-zeroconf
paprefs
padevchooser

Setting up the sound server

First, on the server, launch paprefs from the terminal. It can also be accessed through the PulseAudio Device Chooser (located in Applications -> Sound & Video), under "Configure Local Sound Server." In the Network Server tab, check all applicable boxes:



You may also enable Multicast/RTP, although this is not required for a simple sound server.


Now, start up padevchooser. An alert should appear notifying you of a new sound server.










Select the new server as the default.














Setting up the sound streamer

Now launch padevchooser on the client, and select the same server.







Configure your sound properties to use PulseAudio as the audio output. This will vary by distribution and by version, as the pictured F9 gnome-sound-properties dialog does not exist in F12.






















In some cases, such as XMMS, you may have to configure its output manually, in addition to the system-wide output.

In fact, if possible, it is far safer to configure individual programs to use Pulse if it is not already your sound device -- those of us using OSS or ALSA for system-wide sound, for example.















You do not have to have padevchooser open all the time. You can close it once the default server has been selected. Although the client's volume does not communicate to the PulseAudio server, the individual applications should, (such as XMMS's native volume control) as well as the volume on the server.

You may have to open ports 4713 and 59352 on both machines before the audio will connect.
Read Full Post

Copy-pasting on the Linux command line

On Mac OS X, since the Apple key is used for copying instead of Ctrl, copy-pasting works within the Terminal. On Linux, Ctrl-c sends an interrupt signal.

Instead, use Ctrl-Shift-c to copy within a terminal, and Ctrl-Shift-v to paste. Other similar commands are:

• Ctrl-Shift-t : Create a new tab
• Ctrl-Shift-w : Close the tab
• Ctrl-Shift-q : Close the entire window, tabs and all
• Ctrl-Shift-n : Create a new window

Read Full Post

Showing hidden files in the Finder

By default, OS X does not show its hidden directories, such as /etc, /var, and /usr, in the Finder, although they are still accessible using Go from the menu.

To enable them, use the command defaults write com.apple.finder AppleShowAllFiles -bool true as root.


Read Full Post

Fixing a slow SSH prompt

For owners of multiple Linux machines, it's happened to all of us -- the machine in the living room responds immediately to SSH; but it takes forever to log in to the one in the closet, although it does succeed eventually.

This happens because of the SSH client attempting various authentication methods. Using ssh -vvv user@host, the output of a slow connection will look something like this:

debug3: check_host_in_hostfile: filename /home/drsavoye/.ssh/known_hosts
debug3: check_host_in_hostfile: match line 11
debug1: Host '192.168.2.107' is known and matches the RSA host key.
debug1: Found key in /home/drsavoye/.ssh/known_hosts:11
debug2: bits set: 499/1024
debug1: ssh_rsa_verify: signature correct
debug2: kex_derive_keys
debug2: set_newkeys: mode 1
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug2: set_newkeys: mode 0
debug1: SSH2_MSG_NEWKEYS received
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug2: service_accept: ssh-userauth
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug2: key: /home/drsavoye/.ssh/id_rsa (0xb7f541a8)
debug2: key: /home/drsavoye/.ssh/identity ((nil))
debug2: key: /home/drsavoye/.ssh/id_dsa ((nil))
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password
debug3: start over, passed a different list publickey,gssapi-keyex,gssapi-with-mic,password
debug3: preferred gssapi-with-mic,publickey,keyboard-interactive,password
debug3: authmethod_lookup gssapi-with-mic
debug3: remaining preferred: publickey,keyboard-interactive,password
debug3: authmethod_is_enabled gssapi-with-mic
debug1: Next authentication method: gssapi-with-mic
debug3: Trying to reverse map address 192.168.2.107.
debug1: Unspecified GSS failure.  Minor code may provide more information
No credentials cache found

debug1: Unspecified GSS failure.  Minor code may provide more information
No credentials cache found

debug1: Unspecified GSS failure.  Minor code may provide more information


debug2: we did not send a packet, disable method
debug3: authmethod_lookup publickey
debug3: remaining preferred: keyboard-interactive,password
debug3: authmethod_is_enabled publickey
debug1: Next authentication method: publickey
debug1: Offering public key: /home/drsavoye/.ssh/id_rsa
debug3: send_pubkey_test
debug2: we sent a publickey packet, wait for reply
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password
debug1: Trying private key: /home/drsavoye/.ssh/identity
debug3: no such identity: /home/drsavoye/.ssh/identity
debug1: Trying private key: /home/drsavoye/.ssh/id_dsa
debug3: no such identity: /home/drsavoye/.ssh/id_dsa
debug2: we did not send a packet, disable method
debug3: authmethod_lookup password
debug3: remaining preferred: ,password
debug3: authmethod_is_enabled password
debug1: Next authentication method: password
root@192.168.2.107's password: 

In this case, GSSAPI is failing alongside publickey-authentication, but unlike publickey, takes much longer to give up. To disable it, edit /etc/ssh/sshd_config and remove or comment out the lines #GSSAPIAuthentication yes and #GSSAPICleanupCredentials yes.
Read Full Post