4 Mar
2003
4 Mar
'03
11:07 a.m.
in general,
the best answer is typically:
arecord -d plughw:0
Ok, so this is probably associated to the output of arecord -L then, which
seems to be listing all "plugins" that can be used as pcm input ? I think
I'm starting to understand slowly. Is there some doc explaining output of
arecord -L a bit more so I can follow what goes on, or is that an
ALSA-specific question ? the
"plughw" name allows to specify parameters (sample rate, bit
depth, channel count etc.) that are *not* supported by the hardware,
which is good because the hammerfall h/w supports *only* 26 channels,
24-in-32 bit samples, non-interleaved.
Ah, didn't know that - so you are saying that whatever you record, it
always record 26 mono tracks at the same time ? So how do I tell arecord
I'm only interested in the stereo S/PDIF signal coming in on ADAT1 ?
you need to set up a "route" plugin. search the archives of this list
or alsa-devel for "ttable" and you'll hopefully get the idea.
I'll probably end up doing one in GStreamer for
diagnostics purposes. I'd
if you are going to spend time on such a thing, please don't do one
"in Gstreamer". Gstreamer is an internal architecture for use in
streaming media applications. it has very little to do with the
problem at hand.
and as i will discuss at the LAD meeting at ZKM in 2 weeks, writing
audio software like this has the easy-to-fall-into trap that arecord
demonstrates: a basic design that falls apart as soon as a few basic
assumptions turn out to be false.
imagine ALSA is great once it's set up correctly,
but the setting up
correctly bit is killing me.
i would recommend either using PortAudio or see http://jackit.sf.net/
Something very simple - at first just trying to record
an incoming S/PDIF
signal coming from a DAT tape. I've been recording with arecord and
encoding with oggenc, because I know that oggenc uses very little bitrate
when the signal is zero. So that's my hacky test for "do I have incoming
signal or not ?" :)
just open the file in an audio editor, or run sox on it to produce a
floating point data dump (sox infile.wav -f dat -)
ALSA also has the deep problem that the syntax in the file produced by
alsactl that relates to S/PDIF configuration (things like the "pro"
bit setting etc) is even more arcane than even a ~/.asoundrc file. i
have absolutely no idea anymore how you can change these bit
settings, and for recording to/from DAT, they can be really
important.
--p