WIFI notes
|
Note
|
For machines using an USB dongle for WIFI (so, not the pi3 or 4): I spent hours trying to guess why my WIFI USB dongle (an Edimax) would have such bad range, dropping packets as soon as it was more than 15m away from the access point. Measured supply voltages, tried 5 different power supplies, pulled my hair… Until I stumbled on a page where someone with the same problem solved it by using an USB male-female extension instead of plugging the dongle directly in the PI (lost the URL unfortunately, thanks, anonymous friend…). Found an extension, problem solved. |
You probably want to temporarily use mouse, keyboard, and screen, to facilitate diagnostics when using a WIFI link.
BUT it is possible, so here goes for the adventurous.
You will need to mount the SD card volumes on the machine used to prepare them, so this will only work if said machine runs Linux.
The root volume should automount after the image is copied to the card,
else mount it manually (it’s partition 2, so this would be something like
sudo mount /dev/sdx2 /mnt).
(While you are at it, also mount the boot partition and create an 'ssh' file on it, to enable sshd on first boot).
In the following, don’t forget that all editing is performed on the SD card, not on the host system, so don’t forget the mount point in the paths, meaning something like '/media/me/xxx/etc' *not" '/etc'. I make the error almost every time :)
You will need the 'wpasupplicant' package on the host system.
It’s probably safer that neither 'wicd' not 'NetworkManager' are installed or run on the future audio player. This should be the case if you chose a desktop-less image. We are using the basic 'legacy' configuration method as described here.
Then you can set up the future WIFI link in the following way:
-
Check that [mount-point]/etc/network/interfaces has lines looking like the following:
allow-hotplug wlan0 iface wlan0 inet manual wpa-conf /etc/wpa_supplicant/wpa_supplicant.conf -
Run wpa_passphrase on the host system, as
wpa_passphrase [SSID]Replace [SSID] with your WIFI network name of course. This will ask for your WIFI password, and print something like the following in return:network={ ssid="somessid" #psk="somegoodpassword" psk=0ef4feffd6d933f53a1dcb8c485915ca2c9efb5be5e7062185339b55bf471da6 } -
Append the above data to '[mount-point]/etc/wpa_supplicant/wpa_supplicant.conf' The file should look something like the following:
country=GB ctrl_interface=DIR=/var/run/wpa_supplicant GROUP=netdev update_config=1
network={ ssid="somessid" #psk="somegoodpassword" psk=0ef4feffd6d933f53a1dcb8c485915ca2c9efb5be5e7062185339b55bf471da6 } -
Then unmount the SD card and go on with the rest of the installation just like with a wired connection (a little prayer won’t hurt though…)
Audio hardware notes
Of course, MPD will work over the Raspberry native audio, it is just a matter of (not) changing a value during configuration (see further in the main text). But the Pi audio is, shall we say, not so great. I have quite bad hearing and I can easily tell the difference with "normal" audio.
There are two main approaches to get sound out of the Pi: USB or I2S (HDMI too but I never tried this).
The details follow. My current choice is to use an I2S daughter board. There are plenty of options there, you will easily find tests on the Internet. If you are audiophile-minded, it may be worth it to select a board which works as the I2S clock master (see below).
USB
A long time ago, I initially used an external USB audio card, a Terratec Aureon Dual USB (price around 15-20 Euros), which is recognized by the system without any need for configuration or tweaking, and also has an optical output. I sort of suppose that the same would be true for most other USB audio cards. A good indication seems to be to use cards which don’t need a specific driver under Windows.
Historically (before the Raspberry Pi 4), there have been quite a few issues (crackling or stuttering) with USB sound on the PI. Things seem to have improved with newer hardware and software versions, and everything should now be fine at least for "normal" audio (16 bits 44.1/48 Khz). However, Pi 1/2/3 Ethernet hangs from the internal USB hub, and it seems that there are still possible issues with "high definition" audio files. It’s very unclear what triggers them, and details of the device USB implementation may be involved. Just be aware that transferring high bit rate through Ethernet to USB on a Raspberry Pi may still be an issue, and test before you invest in an expensive DAC for this usage.
I use a Meridian Explorer 2 DAC, on a Raspberry Pi 3 and playing 24/192 WAVs from a Samba share work just fine (not that I do this regularly, this was for stress-testing the setup).
It is very likely that all these problems are solved on the Raspberry Pi 4.
I2S
Even with Pi USB improvements, it may still be actually easier and safer to use a DAC connected to the internal I2S bus (a specialized chip-to-chip audio bus available on the board).
There are many I2S DAC daugtherboards for the Pi.
I had begun with HifiBerry boards, always with good success. There are many more choices now, you will find plenty of references on the net.
The I2S jitter `issue'
For people with really good ears (not my case): the Pi I2S bus has quite a bit of jitter. This is certainly inaudible to me, and supposedly rejected by the DAC PLL, but still `in theory', this may trouble some people. See a discussion here.
There are two possible fixes for this:
-
Use an I2S DAC board with an onboard clock, acting as clock master, such as the Hifiberry Pro board. Measurements here.
-
Use an I2S reclocker, there are reasonably cheap ones, see for example on the Volumio Web site. Frankly, I don’t see the point at all, just use a clock master with a good clock.
For what it may be worth, this is my final config for the kitchen, which has no Ethernet cabling: Raspberry Pi 1 B, Edimax EW-7811Un Wireless adapter, HifiBerry, plus a pair of powered shelf speakers. Works flawlessly and sounds great !
In the lounge, and with the headphone amp, I use DAC+ Pro boards `just in case'. It’s a difference of ~15 Euros anyway.
SD card insertion and device names
The system you are using to prepare the SD card will assign a device name to it when you insert it.
Depending on your environment and how it manages removable volumes, the system may also perform a logical mount of the volume(s) on the SD card .
You need to determine the device name and unmount any volume before installing the Raspberry Pi system image.
Device name. You can use dmesg to look at the kernel messages and see
what device name was assigned. Under Linux, after the insertion, you should
see, near the end of the dmesg output, a line like the following:
[133380.655696] sd 7:0:0:1: [sdc] 15564800 512-byte logical blocks: (7.96 GB/7.42 GiB)
Here, for example, the device name is sdc (complete path: '/dev/sdc').
Logical mounting: Use df, both to determine if the system automatically
mounted the volume from the sd card, and to make very sure that there was
no mistake and the device name you found out above was not really your hard
disk. Example df output:
hautmedoc$ df Filesystem 1K-blocks Used Available Use% Mounted on /dev/sda1 305611000 42178076 247908780 15% / udev 1018216 4 1018212 1% /dev tmpfs 410204 876 409328 1% /run none 5120 0 5120 0% /run/lock none 1025508 1324 1024184 1% /run/shm /dev/sdc1 57288 18536 38752 33% /media/A1B1-918F
Here we see that the system disk is sda (of which the first partition, sda1 is used for the root filesystem), and that sdc is plausably the removable disk, the first partition of which was automatically mounted somewhere under '/media'.
So sdc it is, and you need to unmount the volume before copying the
system image: sudo umount /dev/sdc1
Be aware that there may be several partitions (e.g. sdc1, sdc2) mounted
from the card. Unmount them all.
Changing the main user Id on the Raspberry Pi
Very optional: I also changed the main user name from pi to dockes (because my name is such and the default pi user had uid 1000 which is mine by right…):
-
On the Pi, create temporary user temproot:
sudo adduser temproot -
Add to group sudo:
sudo usermod -G sudo temproot -
Set a password for temproot:
sudo passwd temproot -
Log out, then log in as temproot and rename pi and its home directory, set the password for the new user:
sudo usermod -l dockes -d /home/dockes pi
cd /home
sudo mv pi dockes
sudo passwd dockes
-
Log out, log in as dockes, delete temproot:
sudo userdel -r temproot
Setting up a host name and fixed IP address
Things are really easier with NFS when machines have fixed IP addresses. This is a bit less so with SMB, but even then, using a dynamic address means playing hide and seek if it ever changes and your dynamic DNS updates don’t work that well. So… fixed address it will be.
We also want to change the Raspberry Pi default host name, in case we want
to install another one (by the way this can now be done from
raspi-config in the Advanced Options section).
I am setting up the Raspberry to be called rasp1 on the network and retrieve its address by DHCP, but:
-
We don’t strictly need a host name, we could use the IP for the ulterior steps.
-
We could get rid of DHCP at this point, just choose a static address, and set it up on the Raspberry (see the page about headless setup referenced above). If your DHCP device doesn’t have the option for setting up fixed addresses, this is your only possibility.
Anyway, here goes for the sophisticated approach, where isc-dhcpd is
running on the server, along with named. Really, you don’t need the named
part all that much, you could just as well use the IP address.
DNS/named optional part
I prefer to have a static 'named' entry to associate the raspberry host name with the chosen IP. 'dhcpd' is supposed to update the DNS when it allocates an address, but let’s say that on a poorly administrated network such as mine, it doesn’t always work. So there will be something like the following in the two 'named' files for the home network:
In file db.dockes:
rasp1 A 192.168.4.10
In file db.192.168.4
10 PTR rasp1.dockes.com.
The IP must be taken outside of the DHCP server dynamic range.
DHCP
Then edit '/etc/dhcp/dhcpd.conf' to associate the Raspberry Ethernet address with its host name (or IP). Something like:
host rasp1 {
hardware ethernet b8:27:eb:0d:1f:2a;
fixed-address rasp1.dockes.com;
}
Host/IP final steps
On the Raspberry
-
Edit /etc/hosts: change alias for 127.0.0.1 from raspberrypi to rasp1 (do not touch the localhost entry).
-
Edit /etc/hostname change raspberrypi to rasp1
Setting up NFS for mounting the music volume
I’m a great NFS fan since 'round 1988, but it may be actually simpler to use SMB (Windows sharing) if this is already configured and in use on your network. See the next section in this case.
The default Debian NFS client setup appears to have trouble, the accepted workaround seems to install rpcbind:
sudo apt-get install rpcbind sudo update-rc.d rpcbind enable sudo service rpcbind start sudo service nfs-common restart
Install autofs (for automatic NFS mounts, I like this):
sudo apt-get install autofs5
Edit '/etc/auto.master', uncomment the /net line, and restart automount:
sudo /etc/init.d/autofs restart
Then perform the steps in the Host name and fixed IP address section.
Then halt the Raspberry PI.
On the NFS server, add rasp1 (or its IP) to '/etc/exports', restart 'mountd' (or whatever you do to authorize a host on your appliance).
Restart the Raspberry. It should come up as rasp1 with its fixed address.
When the Raspberry is back you should be able to connect to it through ssh and check that you can access the server music volume either inside '/net': '/net/servername/path/to/music', or inside '/smb' if you followed the SMB note: '/smb/server/share'.
Else something is wrong, try to mount the volume by hand and see what kind of error you get, e.g. for NFS:
sudo mount servername:/path/to/music /mnt
Using Windows sharing / SMB / SAMBA for accessing the music files
We’ll be using autofs as this is quite convenient, and it lowers the number of things to adjust if you ever change the server or share names (you’ll only have to change the mpd configuration).
I am assuming here that the shared volume which contains the music files is public (can be read without credentials). This is a reasonable approach, and it works with the default autofs map which comes with raspbian.
If you need credentials to access the share, it’s probably simpler to set a static mount in '/etc/fstab'. I’m sure that you can easily find a tutorial about this…
Anyway to set up things with autofs and an anonymous mount:
Install the autofs package:
sudo apt-get install autofs5
Insert the following line in the '/etc/auto.master' file, preferably after the /net line (not at the end):
/smb /etc/auto.smb
Restart autofs:
sudo /etc/init.d/autofs restart
You should see the shared volume under /smb/servername/sharename.
You can then use the above path as the music_directory parameter inside the 'mpd.conf' file.
Installing upmpdcli on the Pi to provide an UPnP interface
I used to duplicate the "official" instructions here, but this lead to obsolescence and errors, so I’ll just reference the right place:
MPD backports
If you are using Raspbian Wheezy, you should install the MPD package from the following alternate place: the standard one is ancient. The newer version is less buggy and supports the direct SMB access method.
Raspbian Jessie has a package for MPD 0.19.1, which is reasonably recent but does have some issues. There is also an official Debian jessie-backports repository which has MPD 0.19.12 (as of 2016-10). Or use the one from the following alternate site.
I maintain an
alternate
repository for a reasonably up to date MPD version with additional tweaks
(mostly: suppressing a buggy library). You’ll have to trust that I did not
introduce a Trojan in the MPD source. If you don’t, you could also rebuild
from the debian source package, also available there, which would be
reasonably safe as you would check the MPD source tarfile against the
official depot.
Also these packages were built on Raspbian: beware if you are running Debian, I have heard of incompatibilities: some library versions differ, which can cause dependancies issues. If you hit this, you can still use the source package.
If the leap of faith is not too much for you, here how the simple approach goes:
cd /etc/apt/sources.list.d sudo nano mpd.list
Insert the following lines:
deb http://www.lesbonscomptes.com/upmpdcli/downloads/mpd-debian/ jessie main deb-src http://www.lesbonscomptes.com/upmpdcli/downloads/mpd-debian/ jessie main
(Use wheezy instead of jessie if appropriate).
Then save and exit.