JukeBox software options
A1. One place to start is with an existing jukebox application.
The main disadvantage of the above referenced app. is that to 'control' it you need to 'log-in' using a 'twitter' account = however since it's written in python, presumably it's easy enough to 'hack' !More of an issue is that it loads the ARM CPU to almost 100% (which suggests there is not much left over for searching DVD's etc)
A2. Having a fancy UI is pointless when we are going to end up controlling the Pi via a few buttons and a 2 line 16 character display .. so the more basic Music Player Daemon (MPD) seems a much better place to start.
MPD is designed to run in the background (on the Pi) and be controlled across the network from some other device (eg PC) using the MPC (client) component. You can, of course, control the Pi MPD by running MPC on the Pi :-)
A3. Another place to look is here (also uses MPD and has a link to a 'Mk 2' ArchLinux version)
Ripping audio CD's
To facilitate the 'rip' (conversion) of tracks from a music CD to a mp3 archive, the Pi will need to be programmed to 'rip' any music CD it 'discovers' in it's local CD drive and place the result on the 'Server' (i.e. a network 'share' folder). With the appropriate ripper, it is even possible to have the Pi identify the album, go onto the Internet and automatically add track 'titles' etc.
Those who are really clever can even use the Pi to rip music from an on-line 'radio' station (see here on how to connect the Pi to internet radio)
How do I connect the Pi to my WiFi LAN ?
To link to your LAN using a WiFi 'dongle' you start by discovering what USB socket your dongle is plugged into and then edit the Pi's network config file
The 'wheezy' distro contains drivers for 'industry standard' USB WiFi 'dongles'.
To discover what USB socket the WiFi is using type :-
sudo iwconfig
If it's in the 'bottom' USB port, you should see it's wlan0
edit the /etc/network/interfaces file so the WiFi auto-connects by adding as below :-
auto wlan0iface wlan0 inet dhcp
wpa-ssid {your broadcast SSID}
wpa-psk {your wi-fi password}
Restart your network:
$ sudo /etc/init.d/networking restart
The Pi should now display the IP address it has been allocated (and you should be able to 'ssh' from the PC to the Pi)
How do I get the sound working ?
If you are using a HDMI-VGA Converter with audio split-out (see below), the Pi (which is looking for a HDMI connected display) may not auto-detect that the Converter exists (so will switch to using the ancient RCA composite video out). To force the Pi to use the HDMI add hdmi_drive=2 to the config.txt file in root
By default, sound is sent to the HDMI cable. The 'amixer' numid=3 {n=1} command switches it to the 'stereo' output socket (n = 1 for stereo, 2 for HDMI, 3 for auto).
Note, DRM restrictions imposed by the GPU 'blob' code will mean you CAN NOT get 5.1 from the 'stereo' socket (i.e. there is no way to have the GPU divert the AC-3 without it being decoded and turned into Stereo)
sudo amixer cset numid=3 1
To test it's working, download some wav files from your PC into the Pi's 'shared' folder and then use the 'aplay' command to output any .wav file, eg. :-
aplay TestSnd.wav
How do I achieve 'Hi Fi' quality sound output ?
With some difficulty :-) ... there are 3 main 'plug-in' approaches, so choose the one that gives you acceptable quality (or go route 4, the DIY approach) :-
1) Using the Pi analogue 3.5mm stereo jack
Even with the stabilised power supply of the B+, this will never be capable of true 'Hi-Fi' due to GPU hardware limitations. At best it can achieve the equivalent of '12 bit' quality, which is 4 bits (= 16 times) lower than .wav CD quality (16 bits). However, if you will 'only' be playing .mp3 tracks, 12bits should be more than enough !
The GPU firmware update of 3 March 2013 cured the loud 'clicks', 'pops' and 'crackles' that occurred at the start (and end) of each track that previously made the analogue output unusable. So it is now a 'viable' option, especially on the A+ / B+ / B2 (which also fix the hiss and hum caused by poor power regulation) !
Prior to the GPU update, the 'work-around' was to use 'mpd' with 'PulseAudio' set up so it never lets the audio Hardware 'go to sleep'. To install PulseAudio and configure MPD to use it, see here. Whilst this fixed the pops/clicks, it also caused errors if you 'pause' the audio playback. To avoid that, PulseAudio had to be launched in 'system' mode by adapting the pulseaudio initscript and adding the mpd user to the group pulse-access. Whilst now only of historical interest, it does show the extreme lengths you had to go to in order to get half decent sound out of the Pi.
Using the analogue 3.5mm stereo jack has the advantage of avoiding the Pi's notorious USB bottle-neck, so this was my 'preferred' route for direct connection to plug-in loudspeakers (via a small built-in amplifier).
Since this would 'only' be used during playback 'away from home' (when all the tracks would be stored as 128kbps .mp3 anyway), there seemed little point in going 'overboard' with the output 'quality'
For true home 'Hi-Fi' (Home Cinema, S/PDIF) use, however, I wanted full 5.1 surround sound playback, and that turned out to be rather more difficult !
2) Using the HDMI port (with S/PDIF)
Movies played back by the Pi via HDMI will include 5.1 (or better) Dolby DTS Surround Sound. However, the HDMI DRM was designed to PREVENT access to the separate audio track - so extracting the audio can be quite a pain
You can find a number of Pi apps that will play back 'pure music' (.ac3) tracks (rather than 'only movies') via the HDMI display port. If all else fails, just 'wrap' your ac-3 in a .mpg file
S/PDIF was designed for 2 ch PWM stereo. So, despite that fact that DTS (.ac3) encoded 5.1 at 1,411.2 kbit/s (see here) requires EXACTLY the same data rate as 'raw' 2 CH PCM at 1,411.2 kbit/s, the Music Industry DRM obsession makes it hard to find AC-3 'pass-through' drivers.
About the only way to get S/PDIF with AC-3 pass-through is to buy direct from China (or find a 'pirate' software driver)
Using a cheap HDMI->VGA Converter with audio split off
So long as you don't actually intend to drive (note 1) a VGA display, or want anything other than Stereo (note 2), the cheaper HDMI-VGA 'converters' at well under £10 from Amazon/eBay, will 'do the trick'.
Note 1. Just about all HDMI-VGA 'converters' rely on the HDMI 'driver' to set the 'correct' display resolution (and frame rate) for your VGA display. At power-on the Pi will drive 'half HD' (720x1280) - so if you actually try to fit a VGA (600x800) display, it will be driven HD resolutions (and you will be lucky to get anything other than 'wavy lines' :-) ).
Fortunately, most 4:3 'SVGA' displays are actually capable of 1024x1280, so will cope with 720x1280 just fine (although the text display may be squeezed into the center of the screen, or flow off the edge)
Note 2. Most cheap converters are aimed at 'gamers' and intended to drive headphones. So they all contain simple circuits that 'convert' the Surround Sound (5.1) into "Stereo". With their built-in 'bass enhancement' and other silly tricks, finding one that will deliver decent quality 'Hi-Fi' can be a matter of 'trail and error' :-).
NB. Whatever you get, make sure it has it's own power socket (or can be powered from a USB socket). Whilst the Pi's HDMI can 'source' 50mA, many audio split-off converters require a lot more than that !
Using an (expensive) HDMI adapter with S/PDIF 'split off'
WARNING - just because some highly expensive adapter has S/PDIF, this does NOT mean AC-3 5.1 ! Almost ALL such adapters 'obey' the DRM 'requirement' that 5.1 be degraded into stereo when being 'split off' from the HDMI data stream !
S/PDIF was originally designed for a pure 44.1kHz 16 bit 2 channel (stereo) PWM digital data stream. However, more often than not, the data stream would actually consist of 5.1 encoded into stereo PWM, i.e a Dolby-ProLogic II data stream.
If you feed a DPLII data stream to a stereo amplifier (or headphones), you will get 2 channel L/R sound. If you feed it to a Home Cinema system supporting DPLII decoding, you will get 5.1 surround sound. However the constraints imposed by the 'it must sound OK when played back as stereo' means that the 5.1 'range' (channel separation) is rather limited.
To get 'high quality' 5.1 via S/PDIF, you must send 5.1 encoded as an AC-3 data stream (the data rates are exactly the same). This is known as 'pass-through mode' (and a complete 'no-no' as far as the DRM obsessed movie industry is concerned)
It is reasonably easy to get adapters that will do a digital conversion from 5.1 into a 'proper' Dolby-ProLogic II data stream i.e. correctly 'encode' the 5.1 into DPLII which can be decoded back to (more or less acceptable) 5.1 later
To extract the true AC-3 5.1 data from HDMI is much harder. First you need find a HDMI to S/PDIF 'converter' which supports AC-3 'pass through' capability (most likely you will have to buy from China or some other country outside the reach of Hollywood).
This, however, is not the end of it - you will also need software that will send the AC-3 to the HDMI part without 'tripping' the Pi GPU DRM (PC users have the same problem - even those with motherboards incorporating S/PDIF will discover that the Drivers always degrade AC-3 to stereo (or, if they are very lucky, DPLII))
Read the specifications of any device you are thinking of buying EXTREMELY carefully .. many will 'advertise' S/PDIF capability but it's only when you read the small print (assuming you can find any) that you discover it will output stereo PWM only !
One 'give-away' is a highly publicised 'standards compliance' statement = which is a way of saying 'DRM stereo down-conversion is imposed' without actually telling the unsuspecting buyer
Look for HDMI to S/PDIF with 'AC-3 / DTS pass-through' - such devices do exist, however you can expect to pay upward of £35 (even from China, via eBay)
3) A USB Audio 'dongle'
A USB audio 'dongle' is, in fact, the only 'simple' way to achieve 'true Hi Fi' quality (and it's also typically easier to extract AC-3 5.1 surround sound).
Any 'USB audio class compliant' device should be 'Pi compatible' (any that REQUIRE a Windows or Mac 'driver' are likely NOT 'USB class compliant' and most likely won't work with the Pi). For decent quality, expect to pay about £25, even on eBay
They all have a 'headphone socket' (3.5mm stereo jack) and this is fine for driving a stereo speaker Hi-Fi system.
Most (especially those aimed at laptop users) will have 6 channel PWM output (which is designed to drive your 5.1 Surround Sound PC speakers or a 6 channel (5.1) amplifier)Some will have S/PDIF, however, although USB is a 'general computing' standard (whilst HDMI is a proprietary movie industry 'standard') and DRM is a lot harder to 'impose' on the user, once again, you need to be very careful when reading specifications - if it doesn't say 'AC-3 / DTS pass-through' chances are its drivers DO NOT SUPPORT 5.1 via S/PDIF (you might not even get DPLII, only the down-converted garbage they output via the headphone socket)
You also need to check the product description very carefully ! Once again a lot of the (usually cheaper) dongles are aimed at the 'gamer' and these will distort the audio with all sorts of built in (uncontrollable) "virtual HD", or "7.1/5.1 surround sound (effect)" or "3D Sound" 'simulation' and often have excessive built-in 'bass boost' and other 'clever' effects added by the driver (and that can't be disabled).
The 'gamers' USB audio dongles can usually be spotted by their pointless and annoying LED lights, and the fact that they fail to specify a frequency range or 'signal to noise' (SNR) margin on the analogue (stereo) output. You also need to be wary the many that drive the headphone jack 'direct', which results in a 'DC offset' (which can blow sensitive inputs and actually turn your headphones into ear heaters !)
4) DIY / using GPIO pins
Using the I2S bus
The I2S bus was designed to transfer digital audio between chips within a device (such as a DVD player) and at least one vendor has made use of this bus. Unfortunately, this 'off the shelf' solution comes with drivers that do not support AC3 pass-through
See the 'Wolfson' add-on board (available from CPC).Unfortunately, this costs almost as much as the Pi itself and, despite the 'hype' surrounding I2S, it seems that the driver imposes the usual DRM restriction (i.e. it limits the S/PDIF out to PWM stereo, which (may or may not) include DPLII).
So, despite the (rather misleading) claim that it supports 'rendering of HD audio', it turns out that the Wolfson (and almost all other 'S/PDIF add-on' boards) can't deliver true 5.1 Surround Sound after all
Other vendors, such as HiFiBerry, also offer S/PDIF plug-on boards. However, chances are the drivers have no support for AC3 pass-through (see the "Important note: While the hardware is able to output DTS/Dolby Digital, software has to be adapted to support this." on the HiFiBerry S/PDIF page lank)
The 'problem' with all 'add-on' hardware is likely to be with Movie Industry DRM obsession - and the manufacturers fear of being sued, rather than any fundamental limitation of the hardware (or GPU 'blob' code drivers)So, a study of the hardware specifications MIGHT allow you to write your own AC3 pass-through driver / modify the XBMC player code (as hinted at by HiFiBerry), for example, see here for one attempt...
The complete DIY approach = S/PDIF via GPIO pins
Can you just wire up some GPIO pins ? The answer is yes/no, maybe/not easily ...
Since S/PDIF is carried on co-ax or optical (TOSLINK) cable you might expect the data rates to run into the GHz region.Not so - the TOSLINK optical cable was designed to eliminate 'ground loops' and interference, NOT to support high data rates !In fact, it only needs to carry the AES3 data stream. AES3 supports both 44.1KHz (usual CD wav standard) and 48Khz (the usual Surround Sound standard) sampled digital (PCM) data. The 'maximum' data rate (48KHz samples) is 3,072 kbs (which is 384 kbytes/s). Note that the cable is driven using a 'bi-phase' clocking system (at 6.144 MHz)
Using a general purpose GPIO pin
Since it's possible to 'drive' a GPIO pin at 30MHz (or above), 'in theory' all you need to do is wire up one of the GPIO pins to a bi-phase clock circuit and an optical transmitter !
Using C code (with a 'native' driver), users have transmitted data at 22 Mbs (by 'bit banging' a GPIO pin). So 3 Mbs should be 'easy', however the slightest interruption to the flow of data will lead to the sort of audible 'drop-outs' etc. that have plagued users ever since the Pi was first used for music playback (both RCA stereo socket and USB audio dongle users have suffered drop outs).
To cope with 'interrupts' in the data flow, so the CPU can spend some time dealing with other devices (such as the CD drive or Ethernet port), you will have to place some sort of 'FIFO' between the GPIO pins and the S/PDIF circuit.
Since 'filling up' the output 'one bit a a time' will be very wasteful of CPU cycles, at the very least you should look to load 'byte at a time' into the GPIO i.e. use a GPIO pin with an internal 'shift register' (which means the CPU can load a whole byte (or word) at a time).
Using the SPI Bus
The 'SPI' bus (GPIO pins 7-11) has an internal byte wide output data shift register. Unfortunately it's data clock is limited to multiples of 2 (from 32MHz downward). This means you can't just clock the S/PDIF straight from the SPI bus
Instead you will have to fit a FIFO and load data from the SPI at 4MHz whilst you unload the FIFO to your S/PDIF at 3.072 Mbs. The Pi drivers can (apparently) support 0.428 MB/s (presumably 'byte at a time') at the 4MHz clock, so should be able to keep up OK (it only needs to support 384 kb/s).Whilst the GPU SPI hardware has DMA capability, this is not used by 'wiringPi' (and it's quite possible that the GPU 'blob' driver code offers no access to the DMA controls)
Attempting to 'bit unpack' a music file 'on the fly' during SPI output will just lead to variable data rates and 'drop-outs' in the data stream. Instead, the music track will have to be unpacked in advance to a 'buffer' in RAM.
Decoding the entire track 'in advance' will eliminate any possibility of drop-outs during play back (or, at least eliminate those caused by not decoding fast enough)At 3,072 kbs (384,000 bytes/sec or just under 22 Mb/minute), unpacking a complete 5 minute track in advance would require 110Mb of RAM space !
If you wanted to play tracks 'back to back', you would need two such RAM buffers (one being output whilst the other was being filled with bits for the next track, although, in practice, you would re-use the buffer space that is 'freed up' as the first track is output = you just have to make sure the 'next' track being decoded/unpacked doesn't 'catch up' with the current track being played !)Since 'back to back' play requires you are decode the next track at least as fast as the previous is being played, why not decode the current track into the RAM buffer as it is being played ?
So long as your decode task 'keeps ahead' of the output (and does not get so far 'in advance' of the output as to overwrite data that's not yet been sent) everything will be fine.
The 'easy' way to deal with buffer timing is to divide the available RAM space into multiple 'small' buffers (say, 1Mb each) and have both the SPI output task and music track decode task 'hand them off' to one another (decode hands buffers full of decoded bits to the SPI task, the SPI task hands empty buffers back to the decode task)
So, if you want to adopt the DIY approach, then using the SPI Bus seems quite a viable choice (especially if, at some future date, the GPIO 'blob' drivers open up the DMA controls).
Using the UART
The built in serial link UART (GPIO 14, 15 Tx/Rx with RTS GPIO 17 and CTS on GPIO 30) is another option (at least, for those not using it to drive a serial display)
The UART clock is under software control and can be run up to at least 4 megaBaud (4mbps).However (as with the SPI bus) getting the 'exact' data rate required out of the 'clock dividers' is likely impossible (so you still have to fit a FIFO)
Another problem is that whilst the 'theoretical' max. is (apparently) 15.6 mbps, it seems that the (GPIO) drivers can't actually keep up beyond 4mbps (and again, whilst documentation suggests that the UART hardware supports DMA, we have to assume that the GPIO drivers can't get access to that)
With both SPI and UART, if the CPU is going to be near 100% loaded during output, there won't be time to actually read the file off the Ethernet / SDHC / USB stick (let alone decode any .mp3).
Before investing in hardware (FIFO chips etc), it's a very good idea to see if you can get the software to 'keep up' with the data rates required ...
What audio applications exist for the Pi ?
You can find a large list of package names (but no 'links' to guides or usage notes etc) here.
Software functions for the Jukebox
One of the more basic requirements is to 'rip' a CD to a 'Server' and then playback tracks from a 'list', or, perhaps, randomly from some folder, located either on a 'Server' (SMB share), the local SDHC chip or a USB 'memory stick'.
For maximum quality, the 'rip' would be 'digital perfect' 2ch 44.1kHz .wav format. However for speed of data transfer, you might want quality (256kHz or better) .mp3. This implies that the Jukebox support both (the .wav would always be stored on the Server, however limited SDHC space suggests that only the .mp3 be stored locally - although the Pi CPU limitations may mean that it can't keep up with /.mp3 decoding)
One useful additional function would include support for a local USB connected hard drive and the ability to 'burn' selected tracks to a local CD / DVD (either for local use of use in other players eg. car system)
The 'biggie' would be to support 5.1 Surround Sound playback to a 'PC' speaker set (so 6x PCM channel output) or to Home Cinema system (so Dolby ProLogic II or .ac3 output)
Using a CD/DVD 'burner' drive
Even if all you ever do is collect together some of your favorite tracks and burn them as wav to a new CD, it's well worth ensuring your Jukebox has that capability. Unless you are using a CD/DVD drive from a very old laptop, chances are it will also be capable of burning DVD's - and almost all stand-alone BluRay/DVD players will now play back mp3's through your TV / home cinema sound system
How many tracks can you get onto a DVD ?
A single layer DVD can hold about 4.7Gb (4700Mb) whilst a CD is about 720Mb and holds about 18 tracks (more for 'pop', less for classical). So, on average, you can expect to hold 4700/720*18 = 118 tracks on a DVD. However most stand-alone players will accept .mp3s these days, so (depending on quality) you could get 10x that !
The highest quality .mp3 (384kbs) 'pop music' tracks will be from 5Mb to 10Mb ('acceptable' quality half that). Classical tracks will run from 5Mb - 25Mb. Taking 10Mb as an 'average' you will get approx 470 tracks on a 4.7Gb DVD (about 20 albums or over 20 hrs of music) at high quality, or almost a thousand at acceptable quality
The problem with mp3s (as noted above), is that the Pi ARM CPU has problems 'keeping up' with mp3 decoding especially at the higher quality (256kbps-384kbps**)
... so, to avoid 'drop outs', the Pi will need to be programmed so it 'buffers' tracks i.e. one 'task' decodes the 'next' track to RAM whilst another 'task' plays the 'current' track from RAM.
Setting aside 50mb for this should not be a problem (even on the Model A) since no RAM needs to be used for the display
**Some reports suggest that the maximum mp3 bit rate the Pi will reliably decode and play back 'on the fly' is 128kbps (note that the RCA analogue output limits the quality level to the equivalent of about 64kbps, so there is no point trying to get much above that :-) )
To increase the decode rate, you can 'over-clock' the Pi (from the standard 700MHz up to 1GHz). Of course higher clock speeds consume rather more power (expect CPU consumption to go up from 'about 500mA' to 'at least 700mA'), so if you want to prevent instability due to overheating it's a good idea to fit a heat-sink (and make sure your box has some decent ventilation holes).
What about the Pi's SDHC card ?
An 8Gb SDHC card used as the Pi 'boot' device will have enough 'spare' room for well over 600 mp3 tracks, and a 32Gb almost 2,500 tracks. On 'random play' this should be enough to ensure you don't hear the same track twice in one day (or 1 week) !
If you install 'samba' - and program the Pi to check the SDHC (at the end of each track) for a 'new' track - all you need to do is download tracks from your PC to the Pi and they will be played 'next' (the decode limitations can be avoided by downloading .wav - 44.1 kHz, 16 bit stereo .wav equates to (44 100 * 16 * 2) = 1411 kbps i.e. less than 1.5Mbs .. transferring this via a 100mbs Ethernet should present no problems what-so-ever)
Getting the Pi to play new tracks and then 'revert' back to playing the older ones is just a matter of retaining a 'date pointer' (rather than a 'play list')
At the end of a track :- List tracks in mp3 folder by date & time order Choose the track that is 'next newer' than the date pointer, update the pointer, play the track If there are no 'newer' then choose a random track
How do I play mp3's straight from a CD/DVD +/-R ?
A1. First you need to get the mp3 player app
$ sudo apt-get install mpg123
A2. Next you have to 'mount' the CD/DVD device as a 'virtual folder' (eg 'media/DVD') :-
$ sudo mkdir /media/DVD
$ sudo mount -t vfat -o uid=pi,gid=pi /dev/sda1 /media/DVD
Once the drive is mounted, every access to '/media/DVD' will be redirected to the physical DVD disc. So, for example, to play 'track01.mp3' from the 'root' of the disc :-
mpg123 "/media/DVD/track01.mp3"
Mp3's have to be decoded by the ARM CPU for playback. This 'overhead' means that it may be impossible to directly play back 'high quality' 128kbs (or better) mp3's without 'jitter' and 'skipping'.
It will be necessary to perform some experiments with your actual set-up = even running the ARM CPU in 'Turbo' mode may result in 'skips', in which case the mp3 track will have to be decoded and 'buffered' in RAM (as .wav) before being 'played' by a separate process
How do I play a normal (commercial) audio CD ?
Mount the cd drive as the default drive /dev/cdroms/cdrom0 & use the 'cdcd' app
Note - due to DRM, commercial audio CD's can't be 'mounted' as virtual folder 'media' devices
$ sudo apt-get install cdcd
How do I detect a CD 'insert' from the command line ?
To 'auto-run' a script on 'new CD insert detect', see here and here
How do I convert .wav (eg. from a audio CD) into .mp3 ?
If possible, audio tracks should be 'played' direct from the .wav file. This places much less of a 'loading' on the ARM CPU = indeed, some reports suggest that at 128mbs (& above) .mp3's become 'unplayable' as the ARM CPU is unable to decode the mp3 fast enough !
If you really need to convert from WAV to MP3 'on the Pi' (rather than samba it off to a 'watched folder' on a PC and have that do the mp3 for you), use the 'lame' app. eg: "lame input.wav output.mp3"
About the only time you would want to 'compress to mp3' on the Pi is when you are operating in a 'stand-alone' mode and you have limited storage space. Even so, I would recommend 'off loading' the wav to a USB memory stick instead (remember - a complete CD uses less than 1Gb of space, so any cheap 16Gb USB stick will hold at least 16 CD's i.e. more than 16 hours of music)
How do I 'auto-rip' tracks from a music CD ?
First you have to 'detect' the insertion of the CD. From the command line, this is harder than it sounds (but see here).
A simpler approach is to do so from within a GUI and then have the GUI 'activate' the 'ripping' script (see here for example).
You will need an application that can read the audio CD data 'standard' (known as 'CDDA') and extract the '.wav' on a track by track basis - see, for example, abcd
To control the overall rip (find the tracks, rip each, get the track 'titles' on-line etc), the 'abcde' script can be used. The actual 'rip' is done using the 'Cdparanoia' app. which 'adcde' can 'feed' to more than one 'encoder' (Ogg/Vorbis (default) or FLAC, MP3) to create the output formats you want in a single rip pass.
$ sudo apt-get install abcde
What about 'surround sound' (5.1 etc) ?
Apparently, 'pulseaudio' can only be used when 'attached' to a UI (i.e. it "won't" run in a 'headless' setup as a system daemon). You thus need to use Music Player Daemon (MPD) with 'ALSA' to drive your 'surround sound' USB device
For more on using a USB device for 5.1 'surround sound' output, see here and here
How do I add a simple display ?
Many text displays (eg 2 line x 16 character) can be found on eBay for less than £10. These are all 'driven' from a standard serial link, the Rx / Tx of which is available on the Pi's header strip,
The Pi's Rx/Tx pins are wired directly to the Broadcom SOC with no buffering or protection. It is vital to buffer these lines using a MAX3232 serial level converter to protect the SOC's 3.3v from the RS232 +/-12v levels.
How do I use the Raspberry Pi Serial Port ?
The Pi's on-board GPU dedicated UART pins default to 'command terminal' use, which is fine for debugging but means you have to 'unlink' them before they can be used for anything else. To do this edit "/boot/cmdline.txt" and "/etc/inittab".
Start by backing up both files:
cp /boot/cmdline.txt /boot/cmdline.bak
cp /etc/inittab /etc/inittab.bak
Use nano to modify "/boot/cmdline.txt" and configuration parameters:
nano /boot/cmdline.txt
(remove the "console=ttyAMA0,115200" and "kgdboc=ttyAMA0,115200", save and exit)
Comment out the last line on the "/etc/inittab" file:
nano /etc/inittab
(put a '#' before "T0:23:respawn:/sbin/getty -L ttyAMA0 115200 vt100", save and exit)
On the next boot, the above changes will make the UART RXD (GPIO15) and TXD (GPIO14) pins available for general use.
To use the UART pins using Python and the pyserial library:
Download Pyserial from http://sourceforge.net/projects/pyserial/files/pyserial/ and install it by running setup.py:
python setup.py install
Open a Python terminal (it has to run as SuperUser by using sudo or su):
sudo python
To test the function, connect Pi TXD to the RXD pin and then run the following commands on the python terminal:
import serial
ser = serial.Serial("/dev/ttyAMA0")
ser.write("UART the Font")
read = ser.read()
print read
ser.close()
The print command should have printed the string sent using the write command. To configure the UART port, read the following introduction: http://pyserial.sourceforge.net/shortintro.html
Install "minicom" for terminal emulation:
apt-get install minicom. You can use minicom using the next line command:
minicom -b 9600 -o -D /dev/ttyAMA0
SABADO CLASE LCD RASPBERRY
wget https://sites.google.com/site/semilleroadt/raspberry-pi-tutorials/gpio/lcd_raspi.pysudo crontab -e@reboot python /home/pi/LCD_raspi/lcd_raspi.py
By default the Raspberry Pi’s serial port is configured as a 'console' and receives a copy of the system status information during boot-up. Whilst this is useful if you want to control the Pi from the serial port, it means you can't use the Serial Port for other hardware. So "step 1! is to disable "system" use of the Serial Port
For more information see elinux.org/RPi_Serial_Connection
1) Disable the system 'console' by editing the /etc/inittab file.
sudo nano /etc/inittab
Locate the line :-
T0:23:respawn:/sbin/getty -L ttyAMA0 115200 vt100
'Comment out' the line by adding a # at the start :-
#T0:23:respawn:/sbin/getty -L ttyAMA0 115200 vt100
2) Disable the 'Boot-up Info' data dump
When the Raspberry Pi boots up, the boot-up status information is copied to the serial port. This will typically confuse a simple character display to the point where it might even lock-up
Disable the boot-up status by editing the file /boot/cmdline.txt file :-
sudo nano /boot/cmdline.txt
Find the line :-
dwc_otg.lpm_enable=0 console=ttyAMA0,115200 kgdboc=ttyAMA0,115200 console=tty1 root=/dev/mmcblk0p2 rootfstype=ext4 elevator=deadline rootwait
Remove both references to the serial port 'ttyAMA0' leaving :-
dwc_otg.lpm_enable=0 console=tty1 root=/dev/mmcblk0p2 rootfstype=ext4 elevator=deadline rootwait
Changes take effect after a reboot (sudo shutdown -r now)
How do I test the Pi's serial port ?
You must use a MAX3232 based level converter to buffer the Pi's serial Rx/Tx lines. Connecting a normal serial link directly to the Pi will put +/-12v RS232 levels on the SOC and this WILL blow your Pi !
From the Pi's GUI, you can use the 'minicom' utility to 'talk' to your PC's serial port 'terminal window'
sudo apt-get install minicom
Setup a 'Terminal Window' on the PC using 'putty' (or similar) to connect to the PC's serial port at 9600 baud (8 bits, 1 stop bit, no parity and no flow control). Link your PC's Serial Port to the Raspberry Pi's serial port using a standard RS232 cable.
On the Pi, launch the 'minicom' terminal window Pi using :-
minicom -b 9600 -o -D /dev/ttyAMA0
Whatever you type into the 'minicom' terminal screen should now appear on the PC's terminal window and vice versa.
Any 'known bugs' ?
As is usual with the Pi, nothing actually works 'exactly right' ...
1) When the Serial Port is 'started up' (i.e. the 'open' command is used) the Pi will transmit a 0xFF byte on the lines.
2) After start-up, data is not transmitted to the Serial Link until a 'cat /dev/ttyAMA0' command is entered. For example, if you try to send some data using :-
stty -F /dev/ttyAMA0 19200 printf "some data to be sent" > /dev/ttyAMA0
'some data to be sent' is not actually sent until you type :-
cat /dev/ttyAMA0
Click 'Next >>' in the Navigation Bar (left) for Star 'tracking' using the Raspberry Pi