CCRMA Documentation links: index contents overview rooms account staff about
(contents of this file: links to each section)
CCRMA maintains dozens of desktop workstation computers throughout the building, including all studios, classroom, seminar room, most offices, most labs, and a large cluster in the Ballroom. They have largely silent fanless cases (where the whole thing is a huge heat sink) and fairly modern CPU, memory, LCD monitor, etc.
We run the Fedora Linux distribution, with a huge collection of software (Planet CCRMA) installed, plus Matlab.
Get help from Sysadmins, for example, if you would like them to install additional packages to support your work.
You should learn to run programs from the Unix shell with a program such as Terminal
You log in to CCRMA Linux Workstations with a CCRMA user account and password. When you are done you log out.
Sit down in front of the machine, look at its video monitor, and wiggle the mouse if necessary to “wake up” the machine. There should be a login screen asking for your user name and password; just enter them in the appropriate fields. Beware of CAPS LOCK possibly being set, and be careful not to type your password into the name field.
When you’re done you log out of the entire workstation via the Linux menu (lower left hand corner). There’s a menu button that looks like this:
If you click that button it will bring up this very useful menu:
Just above the menu icon is a red button (for restarting or shutting down the computer, which you normally shouldn’t have to do), and just above that is a black button named “Logout / Leave the session”, which looks like this:
After a few minutes of inactivity the screen will automatically lock and you’ll need to re-enter your password to unlock. If somebody else abandoned the machine without logging out, then the best practice is to follow these steps (listed in decreasing order of politeness) until you succeed:
Try to find the person and ask them either to log out or to confirm that they are no longer using the machine.
Ask a system administrator to log them out.
Open the front “door” of the workstation and hit the circular button labeled “reset”, which will completely reboot the machine.
Power cycle the machine with a different button on the front.
Power cycle the machine using the switch on the back, waiting 10 seconds before restarting.
Power cycle the machine by unplugging and replugging the power cord, again waiting 10 seconds between.
All the CCRMA Linux Workstations support remote login, i.e., they are running ssh servers and can be logged into from other machines (including each other).
All CCRMA Linux machines keep track of failed login attempts (i.e.,
you mistyping your password or hackers
trying guesses) and after three failues “ban” you from logging in. For
remote login this manifests as an
ssh error message
port 22: Connection refused.
This ban lasts three hours and then automatically lifts. The ban applies only to a particular user on a particular computer; if you get banned from one machine you can still use any other instead. If you urgently need your access restored immediately then contact a system administrator.
Why can’t I use sudo (wikipedia Sudo) on CCRMA
Linux Workstations?
Short Answer
Because our system administrators
maintain these machines, including all hardware and software
installation and upgrades, so anything you might be tempted to
sudo (like by following online instructions aimed at people
who maintain their own personal Linux machines), you should instead
discuss with them. Indeed, your failed sudo attempt
automaically alerts the sysadmins of what
you tried; you need to talk with them about why.
Long Answer
On Mar 17, 2019, at 3:45 PM, Fernando Lopez-Lezcano <nando@ccrma> wrote local-users@ccrma:
Hey,
Lately we are receiving more and more warning emails, like this one
Subject: *** SECURITY information for xxx.stanford.edu *** cmnxxx.stanford.edu : Mar 17 03:14:11 : yyy : user NOT in sudoers ; … (details omitted)
(where xxx is the name of one of our Linux based workstations and yyy is the account name of one of our users).
These emails are sent to us sysadmins when someone tries to use the
sudocommand.The Linux command
sudoelevates privileges to the "super user" (root) so that you can run commands that require full access to the operating system - for installing software, for example. That is fine if you have Linux installed in your workstation or laptop and the user account you created for yourself has administrative privileges.That is not the case if you have a ccrma account and you are using one of our Linux workstations. You will not be able to use
sudoand any such use will be automatically reported to sysadmins. While we will ask what you need and try to help, it is not the best way to "contact" your IT team!Please try to learn about what you are about to do, and why, before doing it. If you need additional software installed, contact us. If you read somewhere that you need to do
sudo somethingdon’t do it[*].Tell us what you need and we will try to help!
Thanks, – Fernando
[*] most of the warnings we receive are about installing software that is actually not compatible with the version of Linux we are running (Fedora). Our workstations are not running Debian or one of its derivatives like Ubuntu.
All your same files appear in your home directory on whichever computers you use, thanks to a networked file system: The actual files are on a special server and all the Workstations access them over the local network.
Your home directory is automatically backed up.
Your files should stay in your home directory “forever” until you delete them.
Please remove larger files from your home directory once you no longer need them.
By default all the files you make go somewhere inside your home directory. There are some other special places you can put files for faster access and convenience. They’re faster because they’re local disks, physically inside each workstation, as opposed to other file systems served over the network. The capacity is hundreds of gigabytes on most machines.
The /zap directory is for temporary local files.
Everything inside zap is automatically
deleted when you log out.
The /scratch directory is for local copies of
files that you want your program to be able to access quickly on a given
machine, possibly large datasets. Files inside /scratch are
not backed up but they stay on each machine until you
delete them.
Please clean your files out of of scratch when
you’re done using them.
Desktop Linux distributions such as Fedora try to make audio “just work” in a simple user-friendly way so that users can hear youtube etc. In our case this consists of PortAudio plus ALSA.
If you’re trying to do something more advanced, you probably want to use JACK, which gives full flexibility in terms of routing arbitrary numbers of input and output signals to and from arbitrary numbers of hardware I/O channels and (JACK-enabled) audio programs running at the same time. If you like connecting text processing programs together with Unix pipes then you’re a JACK kind of person.
Most Linux audio software by default tries to output sound via PulseAudio, for
example the Firefox
web browser, commandline sndfile-play, or the GUI drum
machine hydrogen.
PulseAudio is a desktop audio system which at CCRMA sits on top of ALSA, the “Advanced Linux Sound Architecture”, the device drivers that interface with the audio interface hardware (the lowest level access to audio), consisting of both kernel drivers and user level shared libraries that provide abstract access to the kernel drivers.
One “feature” of PortAudio is that when the operating system notices
that you have an 8+ channel sound card (such as MOTU 1248), it “helpfully” upmixes
your software’s stereo output to 7.1 based on an assumed 7.1 home
theater layout (as shown in the Test Sound window):
And of course by default you must want every system beep to come through all 7.1 of these channels: everybody knows more speakers is better. So indeed by default, when you play a mono or stereo sound, it comes through all 8 of these channels (but low-pass-filtered on channel 6 and possibly with other filtering and/or delay compensation).
So when you play sound “normally” from Linux, e.g., by playing an online video with the Firefox web browser, then by default it will come out of all the speakers (which may be more than 2).
One way to defeat this questionable upmixing behavior is to run a
Linux program called alsamixer (or its perhaps-even-uglier
GUI cousin alsamixergui) and set the gains to zero on every
channel except the front pair (1+2). Then system sounds come out only
the front, and only JACK can access the surround speakers. This setting
is remembered on a per-user basis.
You will probably need JACK to use Ardour, Pd, jacktrip, or any other Linux software for multi-channel audio.
When properly configured, JACK “sees” the audio interface (“sound card”) and gets sound exactly to the audio outputs (and hence speakers) you explicitly route to.
In general, throughout all CCRMA’s Linux machines, the interface
hw:0 should be the main multichannel audio interface, aka
“sound card” (because of having disabled the motherboard’s low-quality
built-in stereo audio I/O, plus any video monitor’s potential for audio-over-HDMI,
in the BIOS), so you should always be able to use this. (Here’s more info on
selecting sound cards in JACK.)
If you configure and start/stop JACK using the QjackCtl
graphical interface (which is generally recommended unless you’re such a
JACK wizard that you launch
jackd from the command line), then beware that your
Linux account remembers the interface you most recently used with
QjackCtl and defaults to that the next time, so for example
if you had previously launched QjackCtl while connected to
a MOTU 16A on the Stage, then in Studio D QjackCtl will
attempt and fail to open 16A rather than the correct
1248. That’s why always using hw:0 is
advised.
This page of CCRMA documentation last committed on Thu Dec 15 08:31:24 2022 -0800 by Matthew James Wright. Stanford has a page for Digital Accessibility.