Subject: Re: [linux-audio-dev] Alsa Recording Software Programming HOWTO
From: Paul Barton-Davis (pbd_AT_Op.Net)
Date: Tue Jun 20 2000 - 03:16:37 EEST
Juhana -
a few comments on your very useful compilation:
>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.
The meter hold time should be configurable, not fixed. The meter being
on or off should be configurable, and may follow "auto-input" schemes,
whereby it shows playback levels during playback and record levels
during recording, or nothing at all.
>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.
But recording where is also inadequate. As previously discussed, it
matters whether an overflow lasted 2 or 200 samples.
>Alsa could generate events for overflows so that the recording software
>doesn't have to poll.
It can't do this. It would have to inspect every sample, which may
result in highly inefficient operation of some program designs.
>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.
This seems completely absurd to me. You don't mess with this stuff in
a professional recorder *while* recording. If you want to normalize
the data later to a given level, then snd or ecasound or mix or a
number of other programs can help do this. AGC has only ever existed
in the domain of cheap consumer recorders.
>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.)
This seems unnecessary to me. You cannot guarantee data in a real-time
data acquisition system without NV-RAM (though you can get fairly
close, as journalled file systems demonstrate) If you really want to
avoid the ugly effects of a system crash, you need a UPC.
>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.
The CVS version of Ardour now has support for regular 16 bit stereo
interleaved soundcards.
Ardour also satisfies item 11, though not as fully as documented.
On point 14: Ardour has no concept of a "record level". It assumes
that such things are either set via the soundcard h/w mixer using a
mixer program (e.g. the "input gain" control) or are not alterable
from the computer without modifying the input signal (as is the case
with a digital-only card).
>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.
This is simply not true. If I am overdubbing, then there are
situations where I definitely want to use the original file. One
example would be the case of recording 35 minutes of
pre-MIDI-sequenced material as a backing track. If I decide to alter
the sequence, and re-record it, I don't want another 280MB of data
written instead of re-using the original allocation.
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.
Well, its a judgement call. I would say that most people used to
working with tape systems would say that it should be the other way
around.
>Technically, overwriting a file causes computer spend a lot of time in
>deleting the overwritten file, and that may cause severe dropouts.
Why would you ever "delete" the overwritten file, instead of just
truncating it to the correct length, and re-using it ?
--p
This archive was generated by hypermail 2b28 : Tue Jun 20 2000 - 03:55:26 EEST