On Thu, Nov 05, 2015 at 11:27:39AM +0530, Vinod Koul wrote:
On Wed, Oct 21, 2015 at 04:36:14PM +0100, Charles Keepax wrote:
On Wed, Oct 21, 2015 at 09:02:49PM +0530, Vinod Koul wrote:
On Tue, Oct 20, 2015 at 08:37:11PM +0100, Mark Brown wrote:
On Tue, Oct 20, 2015 at 12:47:58PM -0500, Pierre-Louis Bossart wrote:
If you need to set parameters maybe we should also change the definition of snd_enc_generic so that the reserved fields can be used for custom parameters, or document that their use is permitted for this sort of ID.
It does mean the core can't grab them but quite what the core is supposed to usefully do for something like this is unclear to me so...
Well in case of compressed formats, core doesn't do anything, we just act as a transport and shove down data and information.
I do like Pierre's idea of giving some meaning to formats and use some reserved fields, but somehow I can't think of a clean solution for this!
Personally, I feel a bit like doing nothing at the moment might be the best solution. If BESPOKE is for icky stuff that won't be generic trying to pull out generic fields to go in snd_enc_generic seems like a challenging exercise, and we can look submissions that use it and keep an eye out for anything that might be generic enough to go in there, rather than adding a bunch of stuff that ends up never getting used.
So what is the conclusion here..? Are we all okay with this approach?
I was planning to send out a v2 shortly, just adding a comment by the reserved fields in snd_enc_generic to say its ok to use them if using BESPOKE and see where that gets us.
Thanks, Charles