Archive for May, 2013

Raspberry Pi project — Car Audio improvement #3

Tuesday, May 28th, 2013

Update 2013-05-31:
I’ve received the hardware, time to play around! ;-)
In the meantime, I’ve created a repository on GitHub for this project. I’ll upload all the setup instructions, code, etc in there: https://github.com/dsebastien/audioPi.

AudioPi Hardware

AudioPi Hardware

Update 2013-05-28:
I’ve ordered the hardware I needed for the project:

Now I just hope that I’ll be able to plug them both in, given that both USB ports are pretty close and I guess that the sound card is a big large ;-)


After pulling my hair over the following schema for a few minutes:

Scary ;-)

I’ve read stuff about Linux’s audio landscape (graveyard?) for a few hours. It reminded me of things long forgotten and made me discover a lot I did not know about. Briefly said, I read about ALSA, PulseAudio, Jack, OSS, GStreamer (not enough yet), . This has been pretty instructive I must say ;-)

I now have a better view of what’s hot and what’s not and moreover, about the possibilities. My conclusions are that:

  • I want to output sound towards PulseAudio, which will then forward it towards ALSA & the sound hardware
  • I want to leverage PulseAudio’s RTP support so that I can use the system for multi-room audio

While doing my research, I’ve also read more about the Music Player Daemon project, and I think that it’s exactly what I need. Since it’s an headless music player with a client/server architecture, I can rely on it for the server side of things: actually playing the songs, maintaining the playlist, interacting with PulseAudio & ALSA, etc. I can also leverage the different plugins it provides, such as the output ones.

Another benefit of using MPD as backend is that it automatically broadens the usability of the solution since there are (LOTS) of MPD clients (e.g., CLI, desktop, web based, Android apps, etc), which is pretty awesome as it provides the means of controlling music playback from many different places.

On the other hand, I can implement the client API of MPD in my audio engine (A) in order to extend the possibilities, as explained in my previous post (e.g., A2DP support, LCD display, etc).

It’ll soon be time to create the project’s GitHub repo ^^
I’ll try to find some time to update the schema and the rest of the previous post.. ;-)

Related links:


Raspberry Pi project — Car Audio improvement #2

Sunday, May 26th, 2013

I’ve worked a bit on my little side project. The more I think about it, the more I feel like it could be more than just a car audio improvement; it could be a full blown music box, as useful in the car as outside of it.

Here’s an overview of what I currently have in mind. Note that I’m still in the brainstorming process, so I can imagine crazy stuff too.. ;-)

audioPi

A: Audio Engine

The Audio engine would be the control center for the project. Its responsibilities:

  • Detect plugged-in USB devices and scan them for music to play
  • Receive orders from (B), (C), (F)
  • Fetch music from a configured NAS or other online source (e.g., web radios, etc)
  • Manage the playlist
  • Output audio towards (K)
  • Output song information towards (I)
  • Interpret orders from (N)
  • Expose a Web UI (e.g., Lighttp + python/django)

The Audio Engine could expose its services through Web Services (e.g., restful API)

B: Remote Control Host

This component (custom hardware extension?) could further extend the Audio Engine API by interpreting and forwarding commands received from remote control devices (e.g., RF commands).

To forward commands towards the Audio Engine, it could leverage the Web Services.

C: Bluetooth module

The Bluetooth module could further extend the Audio Engine API by exposing it to paired devices. The paired devices could then send commands towards the bluetooth module, which would interpret and forward the orders towards the Audio Engine.

Related links:

D: Phone application

As an example usage of the Bluetooth module, a smartphone application (e.g., Android, iOS, Windows Phone) could leverage the Bluetooth features to pair with the Rpi and control the Audio Engine. For example:

  • control music playback (play, pause, next, previous, enable/disable random mode, …
  • shutting down the Rpi
  • viewing the current playlist, …

Related links:

E: Remote Control Device

A custom remote control device could be created that would send commands towards the Remote Control Host Device (B).
These commands could be a subset of those of (D).

Possibilities:

  • Wired
  • RF
  • IR -> use LIRC (http://www.lirc.org/)

On the

F: A2DP Module

The A2DP module would provide standard A2DP functionality.

Open questions: link with the audio engine? Override the current playlist?

Related links:

G: USB Devices

USB mass storage devices could be automatically detected & scanned by the Audio Engine (A) in order to find & play music present on them.

Open questions: how to detect USB devices as they’re plugged in? Behavior if music is already played from other sources?
Idea: create a list of all possible audio sources and how to react when one of them is added/removed…

H: Car HUD

If we suppose that the Rpi does have a Bluetooth module, it implies that it can connect to the Car. Now, even if the car does not support A2DP, it could still expose some functionality through Bluetooth. One of these might allow for some level of integration with the car’s HUD.

Although, this is more of a bonus than anything, I would place it at the bottom of my goals list for the project…

I: LED Display

A LED display could be added to the project and could be used in different fashions. For example:

J: Online audio

The Audio Engine (A) could fetch music from the Web if it gets Internet access (e.g., via Wi-Fi or Ethernet). There, possibilities are numerous: get music from a NAS, from Web radios, from online music services, etc.

The Internet access could also be used to send information about playing/played music online (e.g., towards LastFM, Facebook, etc).

K: Audio output

The project could either use the onboard audio capabilities or an USB sound card or DAC. From there it could be plugged in different types of speakers.

L: Smartphone music streaming

As explained for (F), if the project supports A2DP, music could be streamed from a smartphone or other device…

M: SD card audio

If audio files are present on the SD card, these could also be played.

N: Voice recognition

Again I consider this as bonus, but it would be nice to be able to plug in a microphone and give orders to the Audio Engine (A) by speaking to it. It could be as “simple” as recognizing orders such as “Play, Pause, Next, …”.

Related links:


The project could go even further than that, for example by providing a full blow Web interface, …


Raspberry Pi project – Car Audio improvement

Wednesday, May 22nd, 2013

Update 2013-05-24:
Thanks to Laurent, I now know more about the audio capabilities of the Pi. Sad news is that the on-board audio output ain’t that great (to say the least :p). One possible solution could be to use an USB sound card or

A second solution would be to hook an A2DP adapter to the RCA inputs of the car, such as this one from Logitech.

Although the second solution seems overall better (possible to pair different devices to the A2DP adapter and stream anything to the car’s audio system of relying on the presence of an USB stick on the Pi, I think I’ll go with the Pi at first (otherwise all the fun is gone :p).

My current idea is to use an USB sound card, maybe with the addition of an USB Wi-Fi / Bluetooh adapter so that I can obtain at least the same functionalities as with the A2DP adapter. I found some, tutorials to do what I have in mind. I’ll check that out in the coming days.. :)

Some other links that might be useful (to me that is :p):


In my last posts, I’ve explained what I currently do with the two Raspberry Pi I own. In this post, I’ll describe one project I now have in mind that I will probably start working on in the coming days.

My goal with this project is to extend the audio system of my car.

Currently, all I can do in my car is to either listen to CDs (classic or MP3, which is pretty standard by now) or the radio. Apparently, I can’t stream music towards the car using Bluetooth because either my car, its specific firmware version or my bluetooth device does not support the correct Bluetooth profile (A2DP protocol).

Rather boring eh? Clearly, the Raspberry Pi could help here ;-)

Fortunately, my car has an RCA stereo socket that I can take advantage of.

For starters, my idea is to have the Raspberry Pi hooked up on the RCA socket and automatically playing any audio files it finds (either on the SD card itself or on any plugged in USB disk). So that I don’t have to worry too much about it, I also want it to do that without any interaction, meaning that from the moment it is booted up:

  • it should start playing the music it finds
  • if a USB device is plugged in, it should scan it for audio files to queue

Optionally, it should remember the last played song and start from there, or it could just play songs randomly. For this first phase, I think that console music players such as these might help me get started: cmus, sox, …:

  • http://archive09.linux.com/feature/124907
  • http://www.tuxarena.com/2011/12/10-console-music-players-for-linux/
  • http://ubuntuforums.org/showthread.php?t=1699260

Later on (and if I’m not satisfied with what I’ve described above), I have additional ideas:

  • since I want to learn electronics, I could add some switches to support basic controls (play, pause, next, previous)
  • since I also have music on other devices with Wi-Fi, I could add a USB Wi-Fi dongle and be able to send music towards the Rpi
  • if I have the USB Wi-Fi dongle, I could also find ways to remotely control music playback using a smartphone
  • I could try to find a way to plug into the car’s display system and use it, like that thing does:

As with any project, the possibilities are endless and so are the possible paths from start to finish. We’ll see how I get there! ;-)


Raspberry Pi SSH server

Wednesday, May 22nd, 2013

In this post, I’ll describe my Rpi SSH server configuration. The media center Rpi is also interesting, but I didn’t have to customize many things since OpenELEC is more like an appliance and apart from installing extensions and tweaking the system settings, there’s not so much one needs to do to get up and running (which is good!).

RPi SSH server

I use my Rpi SSH server as a gateway to reach home when I’m outside (on the train over 3G or on some Wi-Fi network). It basically allows me to access anything on my personal network in a secure fashion (more over this after the setup details).

The configuration is built on top of ArchLinux and uses OpenSSH (who would’ve guessed ^^).

I’ve chosen ArchLinux mainly because I’m already familiar with it, I could also have installed the Debian distribution, I don’t think it would’ve prevented me from doing any of the following..

For the basic setup of ArchLinux, I’ve followed this guide: http://elinux.org/ArchLinux_Install_Guide

After booting it up for the first time, I still had a few things to configure.. :)

  • First things first: changing the password
    passwd
  • Updating everything
    pacman-key --init (init pacman)
    pacman -Syy (update the packages db)
    pacman -Syu (full update)
    pacman -Syu (just because I'm a tad crazy)
  • Modifying the timezone
    nano /etc/timezone
  • Modifying the hostname
    hostnamectl set-hostname rpissh
  • Setting a static IP
    actually not done yet, I rely on a DHCP reservation for now..
  • Modifying the keymap
    localectl list-keymaps
    localectl set-keymap be-latin1
  • Updating the hosts file in order to easily access my home machines
    nano /etc/hosts
    ...
  • Resizing the root partition (because it sucks to use only a part of the available space on the SD card)
    fdisk /dev/mmcblk0
    
    Welcome to fdisk (util-linux 2.22.1).
    Changes will remain in memory only, until you decide to write them.
    Be careful before using the write command.
    Command (m for help): d
    Partition number (1-4): 2
    Partition 2 is deleted
    Command (m for help): n
    Partition type:
    p primary (1 primary, 0 extended, 3 free)
    e extended
    Select (default p): p
    Partition number (1-4, default 2): 2
    First sector (194560-31512575, default 194560):
    Using default value 194560
    Last sector, +sectors or +size{K,M,G} (194560-31512575, default 31512575):
    Using default value 31512575
    Partition 2 of type Linux and of size 15 GiB is set
    Command (m for help): w
    The partition table has been altered!
    Calling ioctl() to re-read partition table.
    WARNING: Re-reading the partition table failed with error 16: Device or resource busy.
    The kernel still uses the old table. The new table will be used at
    the next reboot or after you run partprobe(8) or kpartx(8)
    Syncing disks.
    
    After a reboot:
    
    We’re deleting the rootfs partition, and creating a new one. Since there is no space between the boot and the root partition in the first place, the new partition will start at the exact same position as the just deleted partition. This means, we’ve got a bigger partition, with a smaller filesystem in there.
    We also observe the re-reading of the partition failed, since the partition is currently in use. Therefore we have to reboot in order for the new partition table to be known to the kernel. After reboot we can perform the resizing of the file system itself
    
    And finally, I could resize the partition:
    
    resize2fs /dev/mmcblk0p2
    
    resize2fs 1.42.6 (21-Sep-2012)
    Filesystem at /dev/mmcblk0p2 is mounted on /; on-line resizing required
    old_desc_blocks = 1, new_desc_blocks = 1
    Performing an on-line resize of /dev/mmcblk0p2 to 3914752 (4k) blocks.
    The filesystem on /dev/mmcblk0p2 is now 3914752 blocks long.
  • Adding a user (which will be the only one allowed to log on via SSH)
    useradd -m -g users -s /bin/bash johndoe
        -m: create home folder
        -g: default group
        -s: shell
    passwd johndoe
    
    The same can apparently be done using:
    pacman -S adduser
    adduser
    > johndoe
  • Configuring/Hardening the SSH daemon
    Reference: https://wiki.archlinux.org/index.php/Secure_Shell
    
    nano /etc/ssh/sshd_config
    
    ...
    Port xxxxx # because the default port (22) is too dangerous to expose since it is targeted by all script kiddies & bots
    ServerKeyBits 4096 # because I'm paranoid even though it doesn't have huge security benefits :p
    LoginGraceTime 30 # 30 seconds to log on, after which the client is disconnected
    PermitRootLogin no # root cannot log in, even though I only allow public key authentication (again, doesn't protect me that much more, but still)
    PasswordAuthentication no # I don't allow password authentication, only public key auth
    ChallengeResponseAuthentication no # ...
    PrintMotd no # the less people know, the better I feel :)
    PrintLastLog no # same logic
    UsePrivilegeSeparation sandbox      # Default for new installations.
    AllowUsers johndoe # only user allowed to authenticate
    MaxStartups 10:30:100 # limit the number of connections -> http://stackoverflow.com/questions/4812134/in-sshd-configuration-what-is-maxstartups-103060-means

    I can probably do more than this, but for now I’m ok with that. See my todo list below for more around this

  • Generating & importing my private keys
    ...

Finally, since my plan was also to be able to wake up computers at home in case I need them, In installed the wol package which allows to send magic packets. All you need to use it is the mac address of the device you want to send a wake up call towards ;-)

pacman -S wol
su johndoe
cd ~
touch wol-pc1.sh
chmod +x wol-pc1.sh
nano wol-pc1.sh
> wol aa:bb:cc:dd:ee:ff

With that in place, I can now create a secure tunnel from anywhere towards my Raspberry Pi at home and feel “pretty” secure. It may not be so (I’m no security expert), but at least I’ve taken the necessary steps to ensure that only a motivated attacker will be able get in (using that channel that is :p).

Once the SSH tunnel is established, I can (for example) use the Raspberry Pi as a socks proxy to surf the Web more securely (e.g., if I’m on a public Wi-Fi hotspot).

I can also access any machine within my home network (router, NAS, PCs, etc) and wake them up if they’re not up and running. This means that when I leave home, I can shut down everything and just leave the Raspberry up (3W ain’t gonna kill me :p) and use it to wake up the device(s) I need. I can also transfer files over SFTP, etc.

What I also do from time to time is establish a Remote Desktop session towards one of my Windows PCs using port forwarding and it works surprisingly well..

My todo list for this project

  • install/configure fail2ban
  • configure and automate backups of the configuration
  • install/configure logwatch and send mail notifications once in a while (just in case)

Raspberry Pi

Wednesday, May 22nd, 2013
Raspberry Pi

What it looks like

The Raspberry Pi has opened up a lot of possibilities for many people. Even though there are probably better alternatives on the market by now, it remains a very attractive platform for hackers, schools and even businesses (who would’ve guessed). Many others have already covered this in great lengths, so I won’t try to convince you for too long that the Rpi is pretty cool ^^.

This should tell you enough imho: being able to build a small (size of a credit card), powerful (capable of playing videos in full HD), low power (ARM based, around ~3W) computer able to run multiple Linux distributions (Debian, ArchLinux, etc) for as cheap as 50-70 EUR is just pure awesomeness ;).

In the upcoming posts, I’ll describe my current projects with the Raspberry Pi as well as some I still have in mind for later on.

My current config

Currently, I own two of these little beasts and a third one might join these soon (more on this later). I use the first one as an SSH server, while the other one serves as a media center running XBMC (OpenELEC distribution).

Building those two didn’t take me long, although it’s the kind of never-ending project, there’s always something to tweak, improve, fix, … you know what I mean.

Still I’m pretty happy with their current state ;-)


elementZapper v1.0

Sunday, May 12th, 2013

Update 2014-12-23:
Yes I am aware that this Chrome extension is now broken. No I won’t fix it, I have other things on my mind and meanwhile another extension has popped up on the Chrome Web Store that provides the same functionality (and that one does work heh): Page Eraser.

I’ve just uploaded a first version of elementZapper, a very small Google Chrome extension that’ll allow you to quickly & easily remove elements on any Web page.

Its usage is rather simple: select anything on the page, right click and select “Zap!” and the selected elements will be removed from the page. It’s particularly useful for printing only what is relevant to you.

My goal with this extension was to discover Google Chrome’s extension development, mainly out of curiosity.. Now I can say that it’s pretty neat and easy to get started :)

elementZapper is available on the Chrome Web Store: https://chrome.google.com/webstore/detail/elementzapper/efeljanahmlnjhckmohcfbgkfdjdmnog?hl=en

Also, for those interested, the source code is available on GitHub: https://github.com/dsebastien/elementZapper