[alsa-devel] [PATCH] crec: Add option to specify codec ID

[Richard Fitzgerald]

On Wed, 2016-11-23 at 09:11 +0530, Vinod Koul wrote:
> On Fri, Nov 18, 2016 at 04:17:37PM +0000, Charles Keepax wrote:
> > On Fri, Nov 18, 2016 at 08:39:38AM -0600, Pierre-Louis Bossart wrote:
> > > 
> > > >>If you're debugging you may not care about the file format, you're
> > > >>actually interested in the raw data you get from the codec so dumping
> > > >>the output to a raw file would be useful even if you can't load that
> > > >>file into a music player.
> > > >
> > > >While I agree with you on this, am worried that adding codecs may make
> > > >people think that we can record mp3 file for exmaple, which is not the case.
> > > >
> > > >I think we can add pcm and bespoke as formats supported and allow any format to
> > > >be dumped to stdio. That way it is pretty clear to people ...
> > > 
> > > Crec as is it is pretty useless with PCM only...If we added the profile
> > > selection and things like bitrate information it'd be straightforward to
> > > support elementary bitstreams like MP3 or AAC ADTS, you just dump the data
> > > to a file. Things that require a header or MP4 integration would require
> > > additional libraries, this is no longer 'tiny'.
> > 
> > What about this as a suggestion, if we remove the code that adds
> > the WAV header. Then all the output from crecord is raw data and
> > the addition of any headers or additional wrapping is up to the
> > user. That keeps crecord 'tiny' and allows us to support all the
> > formats in a consistent way so no one gets confused.
> 
> Naah, crecord is a utility. If you need to do above you have tinycompress
> APIs to get the data and pack it the way you like.. You don't and shouldn't
> use crecord for that.
> 

But you can't call APIs from a shell command line, it needs a tool. For
debugging and testing we need a utility that can extract the raw data
from a codec. It's not the case that you _must_ have this data wrapped
in a file format just because normally it would be - for debugging the
raw dump may be sufficient, you aren't necessarily only interested in
playing it in a music app, for debugging you are likely to be more
interested in the actual bytes and in fact it could be preferable to
have it raw and not modified into a container file.

> > We haven't actually used the WAV header stuff since the very
> > early versions of our firmware that didn't use compression on the
> > stream and actually did output PCM data and I don't think anyone
> > else has ever used the compressed interface for PCM.
> 
> Thats fine by me. The only reason we have a WAV header is that we can pack
> PCM files, for rest of the formats it become tricky as Pierre mention so lets
> not go that road :)
> 

I'm confused now about what you want.
If we don't want to allow raw dumps in crecord we need another tool -
say cdump - that can dump raw, but obviously it would be 99% identical
to crecord except that it's blessed with the ability to dump raw, and I
don't see the point of having two near-identical tools.

The alternative is that Cirrus maintains its own branched version of
tinycompress with useful tools but that doesn't seem like a sensible
road to go down either.