Reverse detail from Kakelbont MS 1, a fifteenth-century French Psalter. This image is in the public domain. Daniel Paul O'Donnell

Forward to Navigation

Linux/Chrome on Chromebook using Crouton

Posted: Jun 04, 2017 12:06;
Last Modified: Jun 04, 2017 12:06


There are many articles about this on the web. This is just a reminder to me as to what I’ve been doing.

Change boot to developer mode

Doing the following deletes all local data on your system. You can always reinstall the Operating System (Chrome seems to do that remotely). But your data is wiped after you do this.

Download Crouton

Open a terminal

Install Crouton

The following installs to an encrypted partition a minimal version of the latest version of the Ubuntu LTS with the xfce and unity and the “Extension” utility that allows you to use a common clipboard between Chrome OS and Ubuntu.

Here are some help options

Run Crouton

After you’ve installed the versions you want, you start your Linux session by


Date-time missing from menu bar (Ubuntu 16.10)

Posted: May 11, 2017 16:05;
Last Modified: Jul 25, 2017 15:07


When I reinstalled Ubuntu 16.10 today, the date and time wasn’t showing up in the menu bar at the top of Unity (I’m going to miss it now that they are planning to stop supporting it in 17.10).

When I clicked on System and Date and Time, everything was correctly set.

The solution comes from here

sudo apt-get install indicator-datetime
sudo dpkg-reconfigure --frontend noninteractive tzdata
sudo killall unity-panel-service

Of these, really only the last was necessary in my case: the dialogue showed that it was up-to-date and when I rant the apt-get install is was clearly already installed.


Displaylink and Ubuntu 16.10 and 17.04

Posted: May 11, 2017 14:05;
Last Modified: May 11, 2017 14:05


I have a new supercool three screen setup in my office.

To run this, I am using two cables: A old-style displayport cable to the middle screen, and HDMI cables, via a Dell USB3 Docking station, to the side screens.

Running screens via a USB docking station requires me to use DisplayLink. Fortunately, Displaylink have an Ubuntu driver. Unfortunately, this doesn’t seem to work with 17.04 and getting it to work well with 16.10 LTS requires a little fiddling. The rest of this post is about that.


General requirements (16.10 LTS)

The first thing is general requirements.

You need to install two things in order to run the driver:

  1. Download the Ubuntu driver from here: “” (this is a zipped archive)
  2. Open a terminal and install dkms
    sudo apt-get install dkms
  3. Extract the displaylink .run file from the Zip file you downloaded in (1)
  4. Navigate in the terminal to the directory in which you expanded the zip file and run the following command:
    sudo ./ (where “n.n.nn” is your version number)

At this point, in 16.10 LTS, the driver should be working and you should be able to use your docking station.

Arranging the Screens (16.10 LTS).

Once the driver is installed and your docking station is connected, you will want to arrange your screens. At least in my case, the standard arrangement is that all three screens were placed on top of each other in space (meaning that they reflect the same area in the display space). It was also the case that my middle screen was not rotated 180° Clockwise, as I need it.

There is a graphic interface for doing this (System Settings>Screen Display). But the actual screens are hard to get in place (there seem to be hidden constraints on their movement). What I found after much trial and error was that it is best to work with two screens at a time. I.e. turn off all but your main screen (in my case the 30” oriented clockwise) and one of the other screens. Once you have those two in place, “Apply” and accept the settings. Then move the second screen to as close to where you want it as possible and turn it on as well. Then “Apply” and accept the settings. Then finally do any minor adjustments.

Ubuntu 17.04 doesn’t seem to work

As far as I can tell, the DisplayLink drivers simply do not work with 17.10. I read somewhere that all DisplayLink hardware reports on the hex location 17e9, so if you run lsusb -d 17e9 you should see your hardware if it is working. Unfortunately I couldn’t see anything in 17.04. And I simply could not get my side screens to show anything via the dock.

Other issues

Originally I was using DisplayLink with a 16.10 system that had been upgraded multiple times (probably from a clean-install of 15.04 or 15.10). I found that it threw a lot of errors. I’m now running it on a clean install from 16.10 LTS and it hasn’t thrown any.


Mounting University of Lethbridge "P," "R," and "W" drives under Linux

Posted: Feb 19, 2014 14:02;
Last Modified: Jul 20, 2016 16:07


Here’s how to mount “P” (Personal), “R” (shared research), “W” (web), and department/committee drives at the University of Lethbridge.


“P” drives

Your “P” drive is the windows share that represents your standard network desktop (i.e. the thing you see if you log into a classroom or other computer on campus).

The address is$USER where $USER is your account username (the same as the lefthand side of your uleth email account, or, in my case, daniel.odonnell.

ulhome is a CIFS drive. To mount it, you seem to have to use the commandline (I can’t seem to find the right protocol to use to use the GUI that comes with the file navigator in Ubuntu. I found instructions that worked for me here:

And, to solve the permissions problem that first arose,

One-time mount

To mount the drive by hand for a single session, do the following:

  1. Make sure cifs-utils is installed
  2. Choose a mount point. This can be an existing directory (if the directory has local content, it will not be available while the network drive is mounted). Or you can create a custom mount point. I did the latter: mkdir ~/ulhome
  3. Mount the remote drive. sudo mount -t cifs -o username=$USER,password=$PWORD,rw,nounix,iocharset=utf8,file_mode=0777,dir_mode=0777 //$REMOTEURL $MOUNTPOINT (where $USER = username; $PWORD = password; $REMOTEURL = url of CIFS drive; and $MOUNTPOINT = the directory you chose or created in step 2. Note: your IT department may not give you the full remote URL, since Windows can use the first part of the subdomain; at the U of L, for example, IT tell you the share is called \\ULHOME. I guessed it is probably in the University’s main domain and was correct: \\ULHOME is the same as //


To permanently mount the drive you need to create a password file and use that in /etc/fstab:

1. Create a file /root/.smbcredentials with the following content:


p.2. Change the permissions such that only root can read the file.
sudo chmod 700 /root/.smbcredentials

3. Now add the following line in /etc/fstab file.

//$REMOTEURL $MOUNTPOINT cifs default,uid=1000,gid=1000,credentials=/root/.smbcredentials,rw,nounix,iocharset=utf8,file_mode=0777,dir_mode=0777 0 0

nb: the default,uid=1000,gid=1000 part comes from This is to answer the problem of them mounting RO. When I tried this out, I then had to go into the directory on my local machine and manually change the permissions from access only to read and create.

4. Test if the line added in the fstab file works.

# sudo mount -a

5. Now the remote share should be mounted at /mnt/storage.

Your “R” drive

The “R” or research drive is a shared drive you can use for collaborative research projects. It is found at$DRIVENAME where $DRIVENAME is the name IT gives the space (e.g. genee_students).

You access this using smb (Microsoft’s workgroup protocol)

  1. In Nautilus, choose “Connect to Server”
  2. In the dialogue that pops up enter the network name, prefixed by the smb protocol (smb://$DRIVENAME).
  3. In the authentication dialogue, your username is your (full) uleth email address; password is the same as your uleth network password.
  4. That’s it.

Your “W” drive

The “W” or public drive (the drive your web files are on) is found at This can be ssh’d into and so is a lot easier to use.

ssh $

Department and committee drives

A third kind of drive is department and committee drives. These are often made by IT with spaces in the name (grrr). An example might be: cifs:// Committee

There are different ways of handling spaces in file names depending on how you are mounting things. For use from the commandline for one-off mounting, several normal options (e.g. \ , \040, and %20) don’t seem to work. What does seem to work is putting the whole directory with the space in quotation marks. So in the above example, the following works (where $USER is your uleth username) : sudo mount.cifs //"BoGRC Committee" BOG -o username=$USER


Recovering encrypted drives

Posted: Sep 23, 2012 00:09;
Last Modified: Sep 23, 2012 00:09


I’ve been disappointed in Ubuntu for several years now, since they switched to the Unity desktop. And for a number of years, my notebook has been chewing up processor power for the simplest of tasks, something I believe may have to do with the fact that I encrypted my home drive during the last install.

I have a couple of serious deadlines coming up and I can’t afford to work on a computer that freezes for a minute or so everytime I try to add a new reference to Zotero or access Chrome.

So time to update the system. Here were the tasks I saw before me:

  1. Backup my files on the system (that will be /home, /var/www, and a dump of all the SQL)
  2. Install a new system, reformating /home and /var and copying the files from my backups.

To make the backups, I did two things: I backed the files up using scp to an online repository; and I copied all my /home files to /var/www, with the idea that I could leave this directory unmounted during installation, then mount it and copy all the files back to the new /home.

Of course things went wrong:

  1. Using scp I forgot to set the archive option. This meant that all my original date, ownership, and group metadata was lost (replaced by the current datestamp and the username I used to access the backup directory). This is a serious issue, since the files go back 15+ years, though it is less serious than having them all vaporised. In practice, however, this is best used as a backup backup.
  2. Despite my careful checking of notes, I ended up reformating my original /var drive rather than my original /home. This meant that instead of my backups, I had the original, encrypted drive preserved. So I deleted this second backup, but preserved the originals instead.

Unfortunately, this also meant that the problem that started all this also remained: the files were on an encrypted drive, and, worse, one that was now unmounted and unconnected to any files system. If I couldn’t find the hex passkey, all the data would be lost.

Fortunately, after many years of crashing computers, I have learned to keep passwords and the like when I’m told to. And so a quick look in my online backups found the file encryptionPassKey (this is more secure and less useful than it sounds: the file was in the encrypted file system, which means it would be safe should somebody try to crack my drive, but also useless to me if I needed to find it in order to unlock same drive; this is why it is a good idea to back things up twice!).

Mounting and extracting the information was simple from there on following the instructions here

  1. create a new mount point for your home directory, e.g. sudo mkdir /mnt/oldhome
  2. find and mount the partition with the encrypted drive to this location. This means the file .Private. you do this using ecryptfs-recover-private (which you may need to install first).
    1. if you don’t know where the file is, run sudo ecryptfs-recover-private with no options; it will scan your drives for .Private files.
    2. if you do know where the .Private file is, you can specify it directly (e.g. sudo ecryptfs-recover-private /mnt/oldhome/dan/.ecryptfs/.Private
  3. Follow the instructions. You may or may not be asked for your key. You may or may not be asked for the password you used to log in to the system you are currently working on. In my case, I was asked the second.
  4. The drive is mounted read only.

Using the M-Audio Audiophile USB Digital Audio Interface with Linux

Posted: Sep 07, 2008 10:09;
Last Modified: Nov 01, 2014 15:11


This describes how to get the M-Audio Audiophile USB Digital Audio Interface working with Linux/ALSA. It has been updated (2014-11-01) to reflect recent discoveries and now seems to work well.



Many of my courses deal with sounds of speech, and I am increasingly looking to supplement my course materials with additional digital video and audio material.

The University of Lethbridge, like most universities, I imagine, is well equipped with computer labs and IT personnel who are able to assist faculty and students with production of this kind of material. But I am looking for something that will allow me both to experiment without committing to the time involved for arranging studio and personnel time, and something that will allow me to respond quickly to opportunities that arise in the course of the year or moments of pedagogical inspiration. The University also has lots of computer labs, after all, but most faculty have a computer on their desk anyway.

Since I was an avid home recording hobbyist in my teens and twenties, I had most of the most useful hardware in a closet: a decent microphone (necessary), and a mixer and patchbay (optional, though not if you want to do quality-sounding work); and the various cables (RCA, ¼ inch, MIDI, etc.) that make things cheaper and easier to set up. My mixer and patchbay were refugees from an old 1980s Yamaha MM30/MT44 Multitrack home studio (see image). Any old mixer will probably do, and I imagine you might be able to get some cheap ones on the internet. Having a mixer makes life easier in the sense that you have more control over the volume, stereo position, and quality of the audio signal before it gets to the computer. Certainly to begin, however, you can work without one, plugging your microphone directly into the card that acts as an interface between you and your computers.

M-Audio Audiophile USB Digital Audio Interface

The one thing I needed, of course was a way of connecting my microphone and mixer to the computer. I was in a music store on the weekend looking for some supplies, and I found a cheap used M-Audio Audiophile USB Digital Audio Interface (DAI) for sale. While you can buy microphones, record and cassette players, and MIDI cables that all convert a single input directly to USB for recording, a more general DAI like the Audiophile USB allows you to do more. With this, I’ll be able to convert cassettes of accents I have for my class on World Englishes to audio form as well, for example. The M-Audio was an extremely popular DAI, so there are likely thousands of used ones floating around.

A quick search on my cell phone found a page that described how to get the interface working and suggested that it is reasonably well supported in Linux. So I took a flutter. When I got home, I installed the audio software from Ubuntu Studio (a full-featured home studio suite, that is, of course, free). And used some hobby time getting things set up. All in all, it took me about 5 hours, including writing up this description of what I did.

The M-Audio Audiophile USB works with Linux due to some heroic efforts by a couple of people, most particularly Thibault Le Meur, who wrote the kernel documentation. These people have ferreted out and developed patches for the various inconsistencies in the device’s use of the USB protocols. The instructions for getting it working, however, are not always that easy to follow, so I thought I’d collect what I found and write down what worked for me.


Getting the M-Audio Audiophile USB to work with Linux involves two discrete steps:

A third step, which isn’t applicable to my current project, involves getting the MIDI (Musical Instrument Digital Interface) input to work with digital instruments like synthesizers and drum machines. Since I’m at the moment only interested in recording relatively high quality spoken work and analogue feeds from cassettes and records, I haven’t tried it to see if the discussion below gets the MIDI working as well.

Getting the M-Audio Audiophile USB recognised by ALSA

As the kernel documentation indicates, the M-Audio Audiophile USB works partially with current versions of ALSA right out of the box. If have the right modules installed (and you almost certainly do, as USB sound is something I suspect all distributions support), ALSA will recognise your device as soon as you plug it in and turn it on.

So if you have headphones plugged in and have set the card to be the choice for playback (either using whatever utility your desktop uses for letting you set Sound preferences [in Ubuntu: System > Preferences > Sound Preferences], or by giving the hardware address explicitly to a program via the command line or configuration utility), you will be able to hear audio files sent to it.

The problem, however, is that you won’t be able to record anything—or at least anything meaningful. Due to a technical problem, the details of which thankfully don’t have to concern us, audio inputs to the device are recorded as white noise by ALSA if you use the default setting (If you are interested in the problem or planning to do development using the M-Audio Audiophile USB, you can read about the details of the issue in the kernel documentation).

The solution, developed by Thibault Le Meur and others, and recorded in the kernel documentation, is to reload the ALSA USB module with some device specific instructions:

  1. Turn off your M-Audio Audiophile USB sound card
  2. At the command line, remove the usb module: sudo modprobe -r snd-usb-audio
  3. Reinsert the module with explicit information about Audiophile’s location and setup, e.g. sudo modprobe snd-usb-audio device_setup=0x01
    1. Note: I used to specify both the index value index=0 and a different device_setup =0x09, but I found that the index wasn’t necessary with only one USB and that 0×01 worked way better than 0×09—in fact it answers the questions about noisiness in the comments below.
    2. Note the different possibilities are:
      1. device_setup=0×01 (this is the one I use now)
        1. 16bits 48kHz mode with Di disabled
        2. Ai,Ao,Do can be used at the same time
        3. hw:1,0 is not available in capture mode
        4. hw:1,2 is not available
      2. device_setup=0×11
        1. 16bits 48kHz mode with Di enabled
        2. Ai,Ao,Di,Do can be used at the same time
        3. hw:1,0 is available in capture mode
        4. hw:1,2 is not available
      3. device_setup=0×09 (This is the one I originally recommended, but it creates a lot of background noise).
        1. 24bits 48kHz mode with Di disabled
        2. Ai,Ao,Do can be used at the same time
        3. hw:1,0 is not available in capture mode
        4. hw:1,2 is not available
      4. device_setup=0×19
        1. 24bits 48kHz mode with Di enabled
        2. 3 ports from {Ai,Ao,Di,Do} can be used at the same time
        3. hw:1,0 is available in capture mode and an active digital source must be connected to Di
        4. hw:1,2 is not available
      5. device_setup=0×0D or 0×10
        1. 24bits 96kHz mode
        2. Di is enabled by default for this mode but does not need to be connected to an active source
        3. Only 1 port from {Ai,Ao,Di,Do} can be used at the same time
        4. hw:1,0 is available in captured mode
        5. hw:1,2 is not available
  4. Turn your M-Audio Audiophile USB sound card back on.

You are now able to record and playback audio files. You can test it out by plugging a microphone into the one of the two ¼” (unbalanced) input plugs on the right hand side of the back and making a recording from the command line using arecord; if you have a mixer, plug your microphone(s) into the mixer and connect the mixer’s audio out/line out plug to the Audiophile’s RCA Input jacks (second from the right when you are looking at the back):

arecord -D hw:1,1 -c2 -d 10 -t raw -r48000 -fS24_3BE test.raw

(this command uses the following options: -D hw1:1,1, the likely hardware address of your Audiophile USB card; -c2, two-channel recording [required for this card]; -d 10 duration of recording in seconds [default is infinite and is stopped by sending a break signal to the program]; -t raw, a .raw file type; -r48000, sampling rate; -fS24_3BE, number and order of bits).

You can then use aplay to play the recording back

aplay -t raw -r48000 -fS24_3BE test.raw

(the above command will output to your default sound card [i.e. probably the one that drives your speakers]; if you want to hear it in the headphones through your Audiophile, add -D hw:1,0 to the command).

Getting the M-Audio Audiophile USB recognised by JACK

update: I’m not sure the following is necessary any more. I was able to record well within Audacity without going to this step.

Command line recording is not a particularly user-friendly way of working, though knowing how to do it has its uses. For daily work, we are going to want to get the sound card working with the many excellent studio programs available for Linux, all of which (or at least all the most serious of which) work with the connection utility JACK. The fact that your Audiophile is recognised by ALSA, unfortunately, doesn’t seem to mean that it is recognised by JACK (actually your card does seem to be recognised by JACK without modification if you use the default module settings for snd-usb-audio; but it seems no longer to be recognised automatically by JACK or by the GNOME sound preferences manager after you add the device-specific options.

To get it recognised by JACK, you need to modify the JACK settings. You do this using jackctl (also known as qjackctl). While you can work from the command line with jackctl, Ubuntu Studio comes with a graphic version (Applications > Sound & Video > JACK Control).

  1. Once JACK Control is open, choose the “Setup” button;
  2. In Setup click on > beside “Input Device”;
  3. Choose the device that matches the hw: address you used above with arecord: probably hw:1,1 USB Audio #1
  4. Close the setup and start (or restart if you had already started) JACK.

Open up another JACK device (e.g. Ardour, the sound recording program, or even Meterbridge, the sound meter), and see if you are getting an audio signal from your microphone through your Audiophile USB sound card. If things are working, the audio will be available from system/capture 1 or capture 2 (if you used a microphone directly) or system/capture 1 and capture 2 (if you used a mixer); if these inputs are connected to something in the “Connection” button on the Jack Control, you should be able to record audio. If they or JACK are not working, you may need to play with some settings. I found, for example, that I basically was unable to record anything at under 1024 frames/period, and I got the best results by setting the frames/period to its maximum value of 4096. Unfortunately, this brings with it the cost of a very high latency (the time between a signal being triggered and its reception at the computer end): 171 msec. Many people, in contrast, seem to be working with latencies of <10 or even <5 msecs.

Since others appear to be able to get reliable functioning with much lower frames/period (and lower latency), I assume I still need to play with the various JACK settings and perhaps even some of the hardware connections. For the specific type of projects I have in mind at the moment, however—making single voice, spoken word recordings of sounds and words for my classes and converting tapes and records I have used in classes in the past to digital format—I suspect this is a relatively minor issue. I would appreciate any tips, however!


My first examples, recorded with a good mike, the mixer mentioned above, but otherwise unprocessed and recorded with my computer fan roaring in the background are available here:


In addition to the latency issues mentioned above, I’m aware of/suspect there may be some additional issues.

  1. I’m not sure how the Audiophile USB card, or the special device specific instructions required to set the module up for it will affect other USB sound cards I use, particularly the USB headset I use for audio conferencing.
  2. Setting the JACK input to the Audiophile USB card looks like it may disable your ability to use other inputs in Jack without changing things back: I did a quick test with Hydrogen (a drum machine), for example, and it looks like I need to change the input back to get it to record in Ardour (though I’m not 100% certain this is true, since none of my spoken word requirements—at the moment!—require a drum track or other instrumentation).

Back to content

Search my site


Current teaching

Recent changes to this site


anglo-saxon studies, caedmon, citation, citation practice, citations, composition, computers, digital humanities, digital pedagogy, exercises, grammar, history, moodle, old english, pedagogy, research, student employees, students, study tips, teaching, tips, tutorials, unessay, universities, university of lethbridge

See all...

Follow me on Twitter

At the dpod blog