Re: [PATCH] ALSA: Add rate defines for 352k8 and 384k

From: Clive Messer <clive.messer@digitaldreamtime.co.uk>
To: Takashi Iwai <tiwai@suse.de>
Cc: alsa-devel@alsa-project.org
Subject: Re: [PATCH] ALSA: Add rate defines for 352k8 and 384k
Date: Mon, 06 Jun 2016 22:22:20 +0100	[thread overview]
Message-ID: <1465248140.11487.65.camel@digitaldreamtime.co.uk> (raw)
In-Reply-To: <s5hporucb7t.wl-tiwai@suse.de>

On Mon, 2016-06-06 at 22:29 +0200, Takashi Iwai wrote:

Takashi,

> I'm asking about "the current tree".  In other words, after applying
> your patch, how many codes in my current tree can be reduced?

Well, in the current tree, the pcm5102a codec isn't enabled for 384k.
You want me to submit a patch for doing that, using constraints and
then re-submit my patch to add the sample rate defines and then a 3rd
patch, removing the constraint code from the pcm5102a codec, now it
would result in a one line change with the sample rate defines?

> So, please prove the cleanup results as patches, and send together
> with your patch as a complete patchset.  Then it'll become more
> convincing.

There must be something I am missing. I don't understand what this has
to do with "cleanup"? I never proposed anything other than adding a
couple of defines, for what are now becoming more common high-res
sample rates.

There has been resistance to adding these defines in the past. I didn't
understand why then, and I don't understand why now. What is it you
need convincing of? That DXD (352k8/24) is a standard resolution? That
192k used to be the max fs of most DAC chips.... Time marches on....
Now many are max fs 384k? 

The last time, 20160127, someone from Cirrus tried submitting a patch
to add a 384k define, the thread ended with you inviting them to re-
submit it. AFAIK, it never was re-submitted. 

http://mailman.alsa-project.org/pipermail/alsa-devel/2016-January/103506.html

And again, I don't understand why you are talking about "cleanup". I am
not proposing to cleanup any code, only add a couple of defines to a
header, which would result in one line changes, at the point someone
wanted to add 352k8/384k support to an existing codec driver, rather
than adding multiple lines of methods/code to add 352k8/384k support
via KNOT/constraints. The point I was trying to show, with the pcm5102a
example.

Regards

Clive
-- 
Clive Messer <clive.messer@digitaldreamtime.co.uk>
Digital Dreamtime Ltd

_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel