Subject: [linux-audio-dev] Alsa Recording Software Programming HOWTO
From: Juhana Sadeharju (kouhia_AT_nic.funet.fi)
Date: Mon Jun 19 2000 - 22:18:13 EEST
Hello. I wrote up the following Alsa recording software programming
HOWTO. I just want to raise the quality of free recorder programs.
I limited the scope to Alsa recording software but sure the same
quality issues relates to any recorder.
Paul pointed to Alsaplayer when we wondered if Arecord could be improved
but the author of Alsaplayer is out of reach. Anyone?
OK, now lets wait who's recorder satisfy all the needed features!
At meanwhile, I would like to continue the series of these HOWTOs next
with the following topic:
Audiofile management
How to organize audiofiles, audio segments inside audiofiles and soundfiles,
directories (library dirs, tmp dirs, CD-ROMs), filenames? How to handle
different edit versions (GIMP seems to handle it somehow)? What tmp files
are still needed? And so on.
This should be standardized so that we don't have to keep multiple libraries,
one per software.
For example, I would like to build a catalog of sounds for a sound effect
CD without extracting the sounds to disk and cataloging them. This catalog
would then be shared among persons who own the same CD. Last I read it is
not trivial to create exact references to CDs and so, the catalog should
contain a few samples from the sound so that the sound can be located sample
accurately with other CD-ROM devices.
The traditional way to extract sounds and keep them in individual files
simply is not enough. Imagine if you extracted a sound from the CD and
later you notice the sound misses 0.2 seconds from the end: you would
have to extract the sound again and keep two copies of the same sound.
With audiofile management you would just move the begin and end of the
sound a bit (because they are references). Of course, you would keep
the extracted sound on the disk but audiofile manager would notify you
that the file needs a change and would do the job automatically. It also
would keep the longer version of the old and new versions, and only
keep references to shorter version.
Note that the old version should be kept available so that your earlier
compositions don't break up.
Comments and ideas?!
The recorder programming HOWTO follows...
Juhana
Alsa recording software programming HOWTO
=========================================
Copyright 2000 Juhana Sadeharju
License: GPL version 2 or later
Version: June 18, 2000
This HOWTO is about a reliable disk recording software. Latest version
can be found from "http://www.funet.fi/~kouhia/waves/gasp/". Author can be
reached from "kouhia at nic funet fi".
While this HOWTO implies Linux software using Alsa drivers, the listed
features could be useful in any recorder (software or hardware).
-*-
Glossary
--------
Audio card buffer: A buffer in the kernel to which the audio card records
continuously the audio --- when the buffer end is reached, recording is
continued from the start of the buffer.
Fragment: The audio card buffer is equally divided to segments called
fragments. After the end of a fragment is recorded, the recording software
is notified that the fragment is available.
A/D reader: The routine which waits for the notify of crossing fragment
boundary. Typically the routine uses read(2) with blocking mode for reading
the audio from A/D. This way the reader releases the CPU for other processes
but is able to get the turn immediately when the audio is available.
Disk writer: The routine which writes the audio to disk.
-*-
Requirements for a minimal reliable recorder
--------------------------------------------
All these required features are important. Ability to get something
out of A/D without knowing how it succeeds and ability to save
something to disk without knowing what actually is saved makes
no reliable recorder program.
If you're a _serious_ recorder software author, please consider this list
as a TODO listing. If you're a recordist in a need of a reliable recorder,
please show this HOWTO for author of the software you prefer to use.
Following features are equally important, numbered only for convenience.
1. Large audio card buffer.
Having a large buffer helps if the Linux freezes for a moment. While
Linux is jamming, the audio card can continue its work.
2. Multiple fragments in audio card buffer.
Multiple (and therefore small) fragments keeps the A/D reader routine of
the recorder uniformly loaded.
3. Separate processes/threads for the A/D reader and the disk writer.
It is natural to separate the two routines because the audio card
and the disk behaves in totally different ways. Using two processes/
threads makes it easier to tune the recorder for maximum reliability.
4. Large audio buffer between the A/D reader and the disk writer.
The relatively short audio buffer is not enough for reliable recording
when there are other activities with the disk. The large buffer has
two purposes: (i) it extends the audio card buffer and therefore allows
larger disturbations in disk writing, (ii) it allows the use of different
buffer sizes in A/D reader and in disk writer making it possible to tune
the recorder for maximum reliability.
The A/D reader process writes to the buffer and the disk writer process
reads from the buffer. It would be a good idea to show the buffer usage
level during the recording so that recordist may see how reliable the
recorder actually is.
Even the A/D reader and the disk writer would be running in the same
process, the large buffer can be useful: it may be used for delaying the
start of the disk writing routine for preventing dropouts at the beginning
of the recording. It also makes possible to use different buffer sizes in
A/D reader and in disk writer in non-blocking disk write but I'm not sure
how it practically works.
5. At least A/D reader should run as realtime (soft-RT) process.
The audio card buffer is relatively short and therefore the A/D reader
should not compete about the CPU time with another processes. Running
the A/D reader as soft-RT process, prevents it from the competition.
Also, detecting the fast arriving fragment boundary notifies as soon as
possible increases the reliability.
The disk writer may run as normal user process if the large audio buffer
between the A/D reader and the disk writer is used for allowing
large disturbations in disk writing.
6. The large buffer should be locked to physical memory.
If the large buffer starts swapping continuously, it sure makes recording
less reliable.
7. Separation of the recording process from the program execution
If the recorder is executed everytime the recording is started,
a lot of time is spend at initializations and important audio may be
missed. Also, if recording is stopped with killing the program (ctrl-c),
the end of recording is lost.
The recorder should have separate recording mode which is activated
separately from the program execution.
The A/D reader and the disk writer processes should also exists
in early so that no time is wasted in creating them when recording
is started.
8. Misses of beginnings
Recordist should be able to record at minimum the last couple of ten
seconds of audio. This is actually very important feature.
The A/D reader should continuously fill the large buffer so that
when recording (the disk writing) is started, the prior audio can
be saved from the buffer to disk as well. When the end of the large
buffer is reached, the filling is continued from the beginning.
This can be extended by filling continuously a file on the disk.
That makes it possible to take a short break and still not miss
the beginnings.
9. Allowing the disk change during recording
Typical computer may have several disks and several disk partitions.
It may happen that the recording stops due lack of disk space even there
would be a plenty of disk space left in other disks and partitions.
The recorder should know the available disks and switch the disk without
stopping the A/D process.
This feature can be extended by allowing the recordist change the file only
or the disk. The cut point between the files could have a recordist defined
overlap. The file used for filling can be useful here too.
10. Accurate recordings
The recordings should be accurate. If the large buffer is filled
continuously, the disk saving should be started from the point
at which the "record" button was hit. Similarly, the large buffer
should be saved up to point at which the "stop" button was hit.
Stopping the recording by killing the program sure will miss the end
of the recording.
11. Monitoring the reliability
Often not everything which was recorded is equally important and the
recordist would at least know if the dropouts happened on the important
parts of the recording. The recorder should periodically look if dropouts
happened, and keep a list of the blocks which has dropouts. This list
can later be used in a wave editor for visual cue or in a player for
aural cue, for example.
Alsa could generate events for overruns so that the recording software
doesn't have to poll.
12. Recording level meter.
The recording level meter is metering the recorded signal. The meter
should be on during the recording. The meter should have a 2-3 seconds
peak meter.
13. Overflow indicator
The overflow indicator should keep a list of the overflow locations
so that the recordist can later examine if overflows happened in most
important parts of the recording.
Traditional overflow indicator which only tells that an overflow happened
is not enough.
Alsa could generate events for overflows so that the recording software
doesn't have to poll.
14. Saving the recording levels
The mixer settings should be monitored and changes kept in a list. This
feature allows the recordist later to bring the signal levels of the entire
recording to the same level. Use of this technique adds extra bits to the
sample size which might be useful.
This feature would have been useful when an audio engineer decreased
the recording volume while symphony orchestra played a composition with
a slowly increasing volume.
This can be extended for automatic gain control. While recordist can
take the advantages of the AGC, he is still able to remove the AGC
effects of the recording.
Alsa could generate events for each recording level change if possible.
15. Don't overwrite
Each new recording should go to a new file. For sure, recordist doesn't
want the recorder overwrite files without asking. But there is no time to
ask recordist whether to overwrite a file, and there is neither time to ask
for a new filename. Unless recordist explicitly executes "delete" for the
old file, the recorder should record to a new file with automatically
generated filename.
Technically, overwriting a file causes computer spend a lot of time in
deleting the overwritten file, and that may cause severe dropouts. Totally
different case is the one where recording is done to the same file, but
read the above paragraph again.
16. Secure recording
Disk writing should start as soon as possible. Some mechanism should
be used to make sure the audio is really written to disk.
Note that fsync is not recommended --- it doesn't work with large files.
The fsync slows down when the file size increases. (fsync can also be
used for getting more disk priority to the recorder.)
17. Gate recording
A possibility to start recording automatically when something audible
comes in. Check also the feature 8.
Recordist could set the threshold levels for the start and stop gates,
and the release time which is the amount of silence coming continuously
in before recording is stopped. Be prepared to activate the recording
(with possible feature 8) even immediately previous recording is stopped.
The recorder should keep a list of recorded and non-recorded segments
so that the true timeline can be restored later.
An useful feature is the ability to change file for each new segment.
The gate could be extended by examining the signal in spectral domain
where presence of any signal is observed more better than in the time
domain.
-*-
Recording software supporting Alsa
----------------------------------
Arecord (Alsa-utils, http://www.alsa-project.org)
Arecord is a simple command-line recorder meant to be an example
implementation of a recording program. It satisfies only the feature 1.
While it has worked okay for me, it tends to make dropouts at the
beginning of the recording and to lost the end of the recording
(due it doesn't satisfy the feature 7).
-*-
Ardour (http://www.sourceforge.net)
Ardour is a multitrack recorder. It satisfies features 1, 2, 3, 4, 5,
6, 7, 10 and 12. Please verify that feature 10. At the moment Ardour
works only with a multitrack audio card.
-*-
Ecasound (http://www.wakkanet.fi/~kaiv/ecasound/welcome.html)
Ecasound is much more than a recorder. I yet have no information about
what features it satisfies.
-*-
Yarec (http://www.soundforge.net)
Yarec is a recorder program with GUI. I yet have no information about
what features it satisfies.
==END==
This archive was generated by hypermail 2b28 : Mon Jun 19 2000 - 22:57:50 EEST