Linux MusicStation

SLab 2.30 is the current stable version of a hard disk recording system for linux. It's GUI represents a reasonably standard mixing desk with faders for each channel and send and return busses for effects. Anyone who has had experience of real mixing desks will have little trouble finding their way around. SLab 3.0 (in alpha form) looks very much the same. The mixer has new tape buttons and there a few other small alterations. In the background are a whole bunch of new effects and substantial differences in the way samples are handled.

SLab is available here.

Here are some notes on the upcoming Slab 3.0 and beyond by Nick Copeland ...

Until 3.0, SLab only mixed with 32 bit integers. The filters were applied to 16 bit samples, and the bussing and final mixdown was done with 32 bits, which was basically a 16 bit sample with 8 bits of headroom and 8 bits of accumulation (tailroom?). This is fine, but for filtering and any major DSP work, using floats is far more acceptable since it can support almost infinate headroom with no loss of resolution. SLab 3.0 introduced a full floating point mix, including filters and in-line DSP (echo/reverb/chorus without needing to use the send busses). You have to request floating point mixing explicitly from the audio->algorithms menu, and the default is to use integer. Also included in the floating point mixing is the ability to re-order the mixing operations, so you can apply filtering before FX, or FX before filtering - build your own mixer, plus a few other features for real "dual mix" configurations.

Where is SLab going? When 3.0 is finalised I want to work on some audio driver improvements to give better synchronisation across multiple soundcards (3.10), and whilst this is going on I will buy a CD burner and finish off a cdrecord/cdwrite frontend.

Release 4.0 will be able to burn master CDs, not on its own, but by linking into somebody elses CD-W driver. These releases would have other features in as well - I will see what I need to do for a multitrack viewer. After that? Loads of things - MIDI synchronisation to allow SLab to play along with a MIDI recording system. I do not intend to write a MIDI recorder/mixer, other people have done this already and have done a pretty good job. I would like SLab to respond to MIDI controllers, so that you could use an external controller block to mix each track - hands on to knobs is better than mouse control. SMPTE sync would also be interesting, but there is rather limited soundcard support for SMPTE interface signalling. I would like to add an oscilloscope which can be tapped into the mixing algorithm at (almost) arbitrary points, help to track down distortion and control volume levels. The automated mixing requires an overhaul to improve is granularity. Fortunately this is backend stuff, since each controller already sends events to the session recorder, it is only the recorder that needs to be reworked.

On top of that I would like to build something like DrumSLab so you can put down a beat, and record it into SLab. This would potentially be via the effects send/returns, you would attach a drum to a send bus, or perhaps just via the data API into the diskfile. A couple of synths would be interesting as well, especially a decent Hammond box, but that would bring me back to MIDI again! WaveSLab needs some work as well. I would like to add timestretch and pitchshift controls, and work on the cut and paste controls. What I would like WaveSLab to do is be a complete librarian rather than a song editor. It should support some form of "play lists" where samples, riffs and beats could be chained together and then played out via the mixer. This would reduce disk space requirements at the expense of extra memory and CPU operations.

Finally at some point I want to make SLab work in real time. At the moment it only really mixes from tracks on a disk. I intend to allow it to mix from up to 16 inputs to the same number of outputs with all the filtering and in-line effects. This is actually quite a lot of work, and will require a serious CPU.

Other Technical Info from the current Readme...


A suite of applications for direct to disk digital audio recording, mixing and
signal manipulation. MixSLab itself is a launchpad for the remaining 
applications. The applications themselves may consists of several programmes
and/or processes.


Maximum configuration: (see below for more realistic operational limitations)

64 Tracks.
16 Send/Return busses (8 pre fader, 8 post fader).
4 Stereo busses.
8 audio devices, 44.1kHz, 16 bit stereo, provides 16 inputs and outputs.

Each Track:
    Input device select.
    Output device select.
    Input gain.
    PreSends, with bus selection.
    Dynamics Section, 6 algorithms, with optional bypass:
        NoiseGate: Gate signal on threshold with AD envelope.
        Compressor: Gate signal, and force to fixed gain with ADSR envelope.
        Compressor2: Same algorithm with preloaded attack.
        Limitor: Limit excess signal level.
        Limitor2: Gate signal, limit excess signal level with ADSR envelope.
        Compander: Gate signal, expand low level signal with ADSR envelope.
    Digital Filter (DDF) Section, 7 algorithms with optional bypass:
        EQ: HI Gain, LO Gain.
        EQ: HI Cutoff and Gain, LO Cutoff and Gain.
        EQ: HI Cutoff/Gain/Feedback, LO Cutoff/Gain/Feedback.
        BandPass: gain, frequency and Q controls.
        Notch: gain, frequency and Q controls.
        EQ: Hi/Lo gain and frequency, dual pole.
        EQ: Hi/Lo gain and cutoff, parametric Mid control of Freq/Gain/Q.
	Digial In-line Effects:
    PostSends, with bus selection.
    Stereo panning.
    Boost (6 dB signal gain).
    Stereo Bus Selection (grouping).
    Volume Fader.
    Track notes scratchpad.

16 Return Busses:
    Volume control, up to +6dB return signal.
    Left, Right controls.
    Output Device Selection to any of the 8 available audio devices.
    Effects attachments, with effects chaining.
    Bus bypass, effects bypass options.

4 Stereo Busses:
    Volume pot,
    Left, Right fader controls.

VU Meters:
    16 independant fully configurable VUs.
    Simultaneous peak and RMS display.
        any input, left or right,
        any output, left or right,
        any track, pre or post dynamics/EQ/FX.

Master Controls:
    Master Left, Right controls.
    Dynamic Digital Filter per L/R.

    OSS audio device options controller.


This is a set of DSP algorithms running as modules, with the "EffectSLab"
being a 19 inch rack window. The Following algorithms are available:

    Echo      - configurable delay, decay and feedback.
    Reverb    - Spread, depth and feedback - hall/room type effect.
    Streverb  - Spread, depth and feedback - Stereo hall/room type effect.
    Streverb2 - Spread, depth and feedback - Stereo hall/room alternate algo.
    Chambre   - Stereo reverb, filtering/damping, early/late reflect controls.
    Chorus    - configurable speed and breadth.
    stChorus  - Stereo chorus, configurable speed and breadth.
    stNewAPIChorus - Same as above, but uses alternative API definitions.
    Flanger   - Speed and breadth.
    Phaser    - Speed, depth, feedback, Max and Q parameters.
    MultiTap  - Spread, depth and feedback. Delay line with 4 taps.
    Spacial   - The MultiTap algo, 4 tap delay line, with each tap at a
        configurable delay and level.
    Spacial2  - Stereo MultiTap algo, 4 tap delay line, with each tap at a
        configurable delay and level, taps 1 and 3 left, 2 and 4 right.
    Rotary    - Stereo rotary speaker algorithm.
    Overotary - Stereo rotary speaker with vanzeggelaars valve overdrive
        algorithm mixed in for full rotary speaker simulation.
    Leslie    - Full stereo rotary speaker algorithm and frontend.
    Limitor   - Limit, Factor. Simple excess signal compression.
    Limitor2  - Sensitivity/Threshold/Attack, Sensitivity/Threshold/Decay
        Level/Factor params, gated limitor algorithm.
    NoiseGate - Sensitivity/Threshold/Attack, Sensitivity/Threshold/Decay
        gating algorithm.
    Compressor - Sensitivity/Threshold/Attack, Sensitivity/Threshold/Decay
        and signal Level params.
    stcompressor - Stereo Compressor
    Sciompressor - Filtered sidechain input gating compressor.
        and signal Level params.
    Ducker     - Duck main input based on filtered sidechain input.
    Distortion - Speaker distortion algorithm, very noisy.
    OverDrive  - VanZeggelaars valve overdrive, 2 algorithms of creamy valve
        distortion and one transitor algo with control over input bias
        and gain.
    BlueValve - VanZeggelaars creamy valve overdrive, with 3 bands of
        active EQ.
    BlueValveIt   - Bluevalve with extended user interface and user memories.
    Equalizer     - 8 band equalizer, with SLab user interface.
    Stereographic - 8 band stereo graphic equalizer with spectral analyser.
    DimensionC - MultiTapped "helicopter" flanger.
    DimensionD - Stereo MultiTapped flanger, with feedback.

Most effects use the integral user interface definitions. APIs are provided
for creation of new effects. Source code of the echo, flanger and stereo
chorus are provided as examples using the API. Most of the effects are mono,
but stereo support is provided in the APIs via ability to register for
multiple busses (see source for stereo chorus). There are hooks available
to allow the effects code itself to generate the values displayed in the
GUI. This allows the effect to indicate literal values and parameter
units in the display.

The StereoGraphic, Leslie and BlueValveIt use their own interface:
The effects API provides for the capacity to allow the effect to only link
into the data stream for a given bus, but decline to use the GUI. To programme
with this method, do not add any controllers during effect init. The engine
will interupt the effect (SIGUSR1) when data is available on the bus,
allowing asynchronous notification of user data availability. As yet there
are no example sources for how this can be achieved, this will be remedied 
in the next release. If you have questions, send an EMail.
These external effects are not under control of mixdown session recording,
since they are outside of the SLab control. They do however have memories,
4 locations each, and the memories are saved per song in the dataBase
directory for that song. This allows configurations to be saved and retrieved
between mixing sessions, so the same mix can be recovered.


Visual wave/sample editor, operates on multiple tracks or with multiple
waveSLabs.  Tools will operate on tracks or selections, with tooling for:


Interface implements drag and drop operations. Full suite of "undo" options
so edits are non-destructive. Full status bars and floating menus. Implements
sample zooming, on-line magnification rotary controls for sample inspection,
and a wave scrolling mechanism. Zero crossing search algorithm for 'deglitched'
sample looping. Full Bar and Beat editing is possible, with selection
"snapping" to metronome pulses.

The mouse can be used to highlight sections of each wave, and the edit tools
can be applied to the highlighted waves, in turn to each wave in the SLab
if desired. Any number of tracks can be loaded into a single WaveSLab using
the add buttons, or by dragging a track to this SLab. Multiple WaveSLabs may
be opened seperately, operating on the same track if useful.

It is possible to zoom in "sub sample" level, where each sample becomes a
visible bar in the wavemeter. At this point it is possible to paint waves
freehand using the Meta key and Button1, to either generate new waves or
clean up existing ones.

Each WaveSLab wavemeter has a status bar indicating the sample and its value
currently under the pointer, SMPTE offset of sample (in the current SMPTE 
format), selection start and end points, etc.


Tape Controls:

    Stop, Play, Forward, Rewind, SessionRecord, SessionPlay.
    SearchForward, SearchReverse, Pause, Record/Pause, Punch In/Out.

    Micro Tunable tape run speed.

    Track control menus.

    MixDown Session Recording facilities - continuous controller automation.

    8 memory locations for tape positioning.

    Full LCD SMPTE display of current location, memory locations and status.

SMPTE tape counters 24, 25 and 30 fps display (29.97 will also be included
when SMPTE synchronisation is implemented). The SMPTE format used by the
TapeSLab is mm:ss:ff.

There are 3 buttons per memory location. A Select button, used to select this
memory for search forward and search backward (the search buttons just spool
the tape to the next active memory location). A Set button which transfers the
current tape spool position to the given memory location, and a Clear button,
used to clear the given location.
The memory locations are saved in the baseline file.

SessionRecord and SessionPlay control the recording not of audio data, but
of changes to the studio continuous controllers. As a song is "SessionRecorded",
any changes made to volumes, pans etc, during the duration of the playing are
saved to the session recording code. The SessionPlay can then be used to replay
the dynamic mix. It is not intended to do audio recording and session recording
simultaneously, although it should be possible.
These features should really be used from the start of the tape, but may work
at arbitrary points.


Manages all the options of the OSS configured devices. The Studio MicroMixer
alters all the devices in unison. This slab will give access to each device
independently for independent alteration of device parameters.

This slab was introduced with support for multiple duplex audio devices -
the MicroMixer section could not support these features. It is possible to
configure the StudioSLab and DeviceSLob NOT to manage the controllers of any
given device. This is done in the "File->StudioFiles..." menu, with the
"NoControls" button. In this mode any changes made to the mix for a device
will be declined by the audio device libraries. This will allow a user to
configure the audio device with a third party application such as tkmix.

General Information

The mixing desk is split into 3 main areas. The mixing section, bussing section
and mastering section. The mixing section is for the tracks, the bussing 
manages the effects returns and stereo bus groups, and the mastering 
section is the final level controls, and output device controls.

User interface is TCL/TK, with widget extensions for potmeters (rotary controls)
VU meters, and wave editors. The mixing desk can be split into master controls
and track controls (for low res monitors), and the volume slider length can
be tuned. The actual track pane is scrollable to allow x out of y tracks to
be shown simultaneously. Interface uses, where possible, drag and drop to be
able to attach tracks to effects, effects to busses, to copy tracks between
each other, to apply editing facilities etc.

All interface parameters for a given mixdown can be saved to a config file
for later retrieval. By "all" I mean volumes, filters, bus selections, active
effects, effect parameters, VU meter selections, track notes etc. Multiple
"baseline" mixes can be saved. The intention is to be able to recall the 
exact same sound and interface configuration between two mixing sessions.

Similarly, controllers can be automated using "Mixdown Session Recording". This
feature allows the changes in the continuous controllers (potmeters, sliders)
to be recorded, replayed, and saved, providing dynamic mixes to be created.
There is also one default mixdown file, and the ability to save multiple mixes
per track.

The stereo busses allow for track groupings, where multiple tracks can be
sent to a stereo bus, and then controlled for their volumes and panning as a
"group" of tracks. This is effective, but somewhat different from ganging, 
where multiple volume sliders can be controlled collectively. That latter may
be implemented at a later date, but extensions to the stereo bussing is more
likely since it is more flexible.

The StudioSLab supports 8 completely independant full stereo mixes, although
only one is via the main mixing desk, which uses the first output device.
The rest are built using the effects send busses, and linking the returns
into one of the other audio devices.

Design Contraints

The 1.0 release was developed on a Pentium 133/16MB to the following specs:

    16 tracks at 22050Hz, 16bit, 2 active effects.
    8 tracks at 44100Hz, 16bit, 2 active effects.

The above design contraints were roughly met. The 8 track full speed results in
a maxing out of the CPU, but no noticable "ticking" of the signal. This has
been accepted, even though it leaves little headroom for other operations,
since the original design spec did not include the full bussing options,
nor the DDFs, nor the multiple output devices. Even if filtering and
bussing is disabled, there are a number of checks required in the code which
increase overhead, and force the CPU loading up. Using fewer active tracks will
allow more effects or filters to be active. The software should reasonably
allow, for example, 8 out of 16 tracks to be active simultaniously. The 
bottleneck is CPU based, and bound to sample processing, not really disk IO
based. This should allow for some extensive multitracking, and really becomes
useful when mixdown session recording is used. Mixdown Session Recording is the
capacity to record and replay controller changes in the StudioSLab in real time.

The above design constraints are for the 1.0 code release. Later releases will
negatively affect the above limits. A set of stripped mix algorithms are
available which should run to about 16 CD tracks or 32 track at 22kHz, but
do not implemented effects or filters.

There are no performance guidelines for later software releases, and it can 
be expected that as functionality increases, the CPU demands will similarly
be higher. There will be a garantee that the above performance measurements
will be available in backward compatibility - the same mix algorithms will be
provided in each release, and new functionality will be put into new algorithms.
If the user is willing to sacrifice performance, the new functionality can be

[Some performance hits have been taken to allow for 8 duplex audio devices.
This is in device window management and error checking, plus a rather large
hit on the mixiod when recording several inputs. Similarly the enhancements
for FX Chaining has had comsequences for performance. The existing algorithms
should not be affected, only duplex3 and submixAlgo5]


The basic application consists of several cooperating processes. Firstly the
GUI, then the engine. The engine spawns the mixengine, which in turn spawns
a disk IO daemon, and one audio input/output daemon per physical device.
IPC is with shared memory, allowing data sharing between the processes
(reduces overheads). Each sound effect is a seperate process which 
uses the API to connect to the relevant SHMEM segments, and requests services
of the GUI for effect controls. The process based architecture prevents
blocking of the mix algorithm on IO operations, and lends itself to a 
multiprocessor hardware platform. MultiStaged buffering is used to limit
effects of context switching in a multiuser environment.

The Mix Engine does the actual horsework for the application suite. It consists,
as explained, of several processes communicating via shared memory. There is
one main control process called the engine which creates a global control
buffer. On request of signals it will create the mixengine which runs the
signal processing code. This creates the shared disk buffer, and spawns the
mixiod. Then shared audio IO buffers are generated, and creation of the audio
IO daemons takes place. The data is read from the disk, and mixed according to
the GUI parameters (the GUI only really interfaces to the shared memory control
buffer), providing all necessary signal levels to each of the busses. It then
sums the busses onto their respective audio IO shared memory segment.

In addition to the mixing, the mixengine also generates some typical analogue
"signal distortions". There are algorithms for crosstalk, wow/flutter and
vinyl scratch which can be applied in varying amounts. The intention here is
to remove the typically "clinical" feel of digitally recorded audio by applying
analogous inaccuracies that are pleasing to the ear. These can of course all
be disabled as required, and in how far the are pleasing or annoying depends
on the listener.

Crosstalk eats CPU cycles, since we need to proactively scan each track a
couple more times.

The Scratch implements a few different algorithms, giving mono scratch (equal
amounts of same signal in each channel), stereo (complete signal diffusion)
and a hybrid of the two, where only certain scratches hit both channels


This runs and was developed on a P133 16 MB system. Get gobs of disk space
if you want to do some real recording, 16 tracks CD quality requires about
80MB a minute. Compression can be applied to reduce this requirement by up to
a factor of 4, at a consequent loss of signal quality since the compression
algorithms are as of this release (2.0) all lossy. In addition,
if new songs are created with a minimum of predefined run time (5 or 10 seconds)
then autoextension on the Linux filesystem will only write new track sections.
The consequence is, if you define 16 track, but only ever use 8 simultaneously
then the disk space requirements will only be half of the total (and processing
capacity is spared). Session recording will allow you to fade tracks in and
out as you need them.

IPC SHMEM required in kernel. Software was compiled on a 2.1.24 kernel, and
full duplex may require this kernel. OSS 3.8-beta2.
The software will run on a 2.0 kernel, with OSS 3.5.X, but duplex is 
unlikely to work without 2 soundcards (or sound devices).

Since the release of this readme Slab 2.30 has been partially tested with
the ALSA drivers and kernel 2.2.5 and seems to work fine.

Read what Jaroslav Kysela has to say about the ALSA driver project.

 home  music  news  opinion  software  tips  email