Subject: Re: [linux-audio-dev] question re: hammerfall cards
From: Paul Davis (paul_AT_linuxaudiosystems.com)
Date: Tue Mar 04 2003 - 18:02:31 EET
>> 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 ?
its completely ALSA-generic. it applies to all cards. the
documentation that exists right now is weak. the "best" there is so
far (that i've seen) is in alsa-lib/doc/asoundrc.txt. its not for the
faint-of-heart. its not even for people who cycle double centuries for
fun :)
>> 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 ?
no. thats the whole point of the "plughw" specification. its a
"plugin" between your code and the hardware that does whatever is
needed to emulate the parameters you asked for. its perfectly possible
to record just 2 channels. i just can't tell you how to do this
because i never do it (even though i have several hammerfalls) and i
have a real problem with the model that ALSA has followed for this.
> 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
This archive was generated by hypermail 2b28 : Tue Mar 04 2003 - 18:05:10 EET