Source: Gustavii, B. (2012). How to Prepare a Scientific Doctoral Dissertation Based on Research Articles. Cambridge University Press.
The Leap Motion Leap sensor forms part of some research I’m working on atm, but the drivers only come as .debs packaged for Ubuntu or other Debian-based distros. As I’m on Arch (and don’t really want to run dpkg alongside pacman), I wanted a way to pull out the files from the .deb bundle and stick them in the right place. Luckily, it’s pretty easy to do – here’s how…
Download and Extraction
So, let’s say you go to https://developer.leapmotion.com/downloads and get yourself a copy of the most recent Linux driver, which at the time of writing is: Leap_Packages_1.0.9+8411_Linux.tgz.
Extracting the archive will give you two files:
- Leap-1.0.9+8411-x64.deb, and
If you look at either of those two files with Archive Manager you’ll see the file data.tar.gz within ‘em. Pick your flavour (32-bit is x86, while 64-bit is x64) and extract it.
Inside the data folder you’ve just extracted you’ll find three directories:
- lib, and
In the folder with the above etc, lib and usr folders, create a file (call it anything you like, install-leap.sh for example) and dump the following into it:
# ----- Install ----- # Initialisation sudo mv ./etc/init/leapd.conf /etc/ # Device rules sudo mv ./lib/udev/rules.d/25-com-leapmotion-leap.rules /lib/udev/rules.d/ # Daemon sudo mv ./usr/sbin/leapd /usr/sbin # Executables sudo mv ./usr/bin/LeapControlPanel /usr/bin/ sudo mv ./usr/bin/Recalibrate /usr/bin/ sudo mv ./usr/bin/Visualizer /usr/bin/ # Move libs folder sudo mv ./usr/lib/Leap /usr/lib/ # Move shared folder sudo mv ./usr/share/Leap /usr/share/
Now chmod +x the file so it’s executable and we’re almost ready to go. Unfortunately this doesn’t allow for that easy uninstallation, but you can just manually ‘nix it by throwing the following into another script:
# ----- Removal ----- # Initialisation sudo rm /etc/init/leapd.conf # Device rules sudo rm /lib/udev/rules.d/25-com-leapmotion-leap.rules # Daemon sudo rm /usr/sbin/leapd # Executables sudo rm /usr/bin/LeapControlPanel sudo rm /usr/bin/Recalibrate sudo rm /usr/bin/Visualizer # Remove libs folder sudo rm -rf /usr/lib/Leap # Remove shared folder sudo rm -rf /usr/share/Leap
Optional: Reload udev rules
Try skipping this section for now and come back to it if your device doesn’t register, ok?
Apparently udev uses the inotify mechanism so you don’t need this (source: http://unix.stackexchange.com/questions/39370/how-to-reload-udev-rules-without-reboot) but I did this anyway and it worked:
udevadm control --reload-rules
Start the daemon & visualiser
Now that’s all done, you should be able to start the Leap daemon with:
Then plug your leap sensor in and it should work when you run ‘Visualizer’ or such. Handy tip – make sure the camera is pointing upwards not directly down at your desk and it should all be good to go In the case of the SDK you don’t need to install anything, just extract the SDK archive and stick it wherever you want to. Cheers!
My wife got me a FiiO E17 USB headphone amp (thanks, hon!) to go with my Sennheiser HD650′s the other day, and it can handle 96KHz 24-bit audio – but by default pulseaudio and alsa are configured for 44.1KHz 16-bit audio. At the 44.1/16-bit settings everything sounds great, but I figure if the quality can go higher and I’m not fussy about a bit of extra CPU usage then I may as well bump the quality settings up a bit to take full advantage. Here’s how to do it:
1 – Check current settings
To see what your current settings are, you can either run the following for the full details:
Or to cut to the sample rates directly use:
pacmd list-sinks | grep sample
Depending on how many sound devices are connected you should see something like this (in my example I have an Intel HDA internal soundcard as the first sink, and HDMI audio out as the second sink):
$ pacmd list-sinks | grep sample sample spec: s16le 2ch 41000Hz sample spec: s16le 2ch 41000Hz
You might want to play an mp3 at this point and then look at the pulseaudio cpu usage via the top command so you can compare the current and HQ CPU usage as it might be a factor for you (i.e. depending on the spec of your PC, you might not want to sacrifice 10% or more CPU usage for higher quality audio – but seeing as you’re here and reading this I’ll assume that you are!). As a baseline, with the default settings pulseaudio uses around 2-3% CPU to play an mp3 on my Intel i7.
2 – Modify for high quality
Pulseaudio’s global settings are stored in /etc/pulse/daemon.conf, so edit that with your editor of choice and look for the following lines (the ‘resample-method’ line is above the default-sample-* lines btw – that is, they’re not all together as below):
; resample-method = speex-float-1 ; default-sample-format = s16le ; default-sample-rate = 44100
These are the defaults, and are currently commented out (you can use either ; or # to indicate a comment). Uncomment each line and modify it to the below (or even better – just add an uncommented line below each one so you can still see the default values), so you end up with:
resample-method = src-sinc-medium-quality default-sample-format = s24le default-sample-rate = 96000
The Arch Audiophile Playback wiki recommends medium quality for resampling, you might want to try src-sinc-best-quality if you’re going for broke. A description of the libsamplerate resampling methods can be found here if you’re interested: http://www.mega-nerd.com/SRC/api_misc.html.
I get about 10% CPU usage on the pulseaudio daemon with 96KHz @ 24-bit audio with medium quality resampling as above, whilst using src-sinc-best-quality results in a rather significant 24% CPU usage just to play an mp3! ( It’s like having a Pentium 100MHz all over again! ) The ‘s24le’ means 24-bit samples, little-endian order, btw.
3 – Restart pulseaudio and check the settings
Now that’s done we need to restart the pulseaudio daemon (don’t run these as sudo – pulseaudio runs per user so just execute as normal!):
pulseaudio -k pulseaudio --start
Once that’s done, you should be able to check the settings have taken by issuing:
$ pacmd list-sinks | grep sample sample spec: s32le 2ch 96000Hz sample spec: s32le 2ch 96000Hz
It’s jumped up to 32-bit samples in this case, but that’s fine. Check the audio still works, and maybe have a look at the CPU usage when playing an mp3 via top again if you want to see how much this is affecting the CPU usage on your machine.
FiiO E17 Amp Check
Now that we’ve set higher quality default settings, if you’ve got some suitable hardware for them like the above-mentioned amp, plug that bad-boy in, switch it on – and it should validate that it’s getting the higher sample-rate and sample-depth:
$ pacmd list-sinks | grep sample sample spec: s32le 2ch 96000Hz sample spec: s32le 2ch 96000Hz sample spec: s24le 2ch 96000Hz <--- FiiO E17 detected, working at 96KHz 24-bit
Sound Quality Differences
So – does changing these audio setting make a definite, perceivable difference to the audio quality? The short answer is yes!
How much it changes the audio quality is going to depend on your hardware (amp, headphones etc.) as well as the actual audio file(s) you’re playing on it. I don’t have any 24-bit audio to try it out on, but I rip everything at the highest possible quality VBR mp3s using lame – so I’ve been testing on the first track of Alt-J’s album (intro) with some Sennheiser HD650′s – and my honest answer? I’d go as far as to say it’s a strong yes (html joke ;-)). The high-frequency elements in particular seem a little brighter with the 96KHz 24-bit sampling, at least when run through the FiiO E17. Now, this could be placebo – that is, you expect something to sound different/react in a particular way so you look for it and (internally, subconciously) try to convince yourself of it. But I’ve honestly swapped back and forth and listed to the same track a number of times during the writing of this article and I genuinely believe it’s sounding better with the HQ settings.
Unfortunately, the schoolboy error I’ve made here is that I’ve changed two (if not three!) things at once: I’ve enabled the higher sampling-rate and sample-size/depth, but I’ve also modified the resampling algorithm to one of higher quality at the same time – so figuring out what elements of the audio sound better because of the audio settings and which are from the resampling-method (because I’m not playing native 96KHz @ 24-bit audio files to test with) can’t really be done. To get any real results I’d need to strip back to default settings and modify each in turn, doing listening tests with notes as I go, which frankly isn’t all that high up there on my priority list of things to do because…
…I’m delighted with the audio quality after these changes! It really does sound great =D
Ideally, I’d prefer to have things set to 44.1KHz on each audio device EXCEPT the Fiio – that way, when I’m playing games there’s minimal CPU used on the audio side (which isn’t really going to benefit that much from upsampling and such, I’d imagine) and then have the HQ settings for the FiiO only so that when I plug it to listen to music I get the HQ audiophile kick. However, my understanding is that I’d need to go into the alsa side of things to configure device specific settings – and again, it’s not really a high priority at the moment.
I’d love to hear what difference (or lack thereof!) any of you find when changing over to HQ audio (asides from the bump in CPU usage) – and if you run or have played with different samplerate/re-sample settings for diff devices I’d be especially interested! Cheers!