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

[Vinod Koul]

On Wed, Nov 23, 2016 at 10:21:58AM +0000, Richard Fitzgerald wrote:
> 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.

Oops, sorry to confuse you, reading back I dont think I was clear enough..

I am not Ok to add support for any other format apart from bespoke (file
dump) and PCM wav header and save to file.

I am okay to add support to dump data to stdio for any format, so that we
dont bother to support those file formats.

Is this clear enough, does that work for you folks?

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

Agreed

-- 
~Vinod