[linux-audio-dev] question re: hammerfall cards

[Paul Davis]

>> 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