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