[Patch] alsa: Use card description in default sink/source prefix when available

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, 2014-03-11 at 18:13 +0000, Pete Beardmore wrote:
> Quoting Tanu Kaskinen <tanu.kaskinen at linux.intel.com>:
> 
> thanks for coming back so quickly
> 
> > I don't know what you mean by abusing proplists,
> 
> i was referring to the (some might say) pollution of the hash with  
> what is really just a temp variable that needs passing to the  
> pa_device_init_description(). it's not really a proper PROP, e.g.  
> existing in proplist.h for users to utilise. but i'm happy if you are

Hmm, yes, the fact that it's just a temp variable is a bit ugly. The
fact that it's not defined in proplist.h, however, is totally fine. My
personal opinion is that we shouldn't have defined any "standard"
properties in proplist.h to begin with, because once a property is
documented in a public header, it becomes part of the stable API, and
very similar to a field in a struct. A field in a struct is much nicer
to work with, so there's no point in defining a stable API in proplists.

> > ..I'd prefer the PA_PROP_DEVICE_CARD_DESCRIPTION
> > initialization to happen in pa_sink_new()/pa_source_new() instead of in
> > the alsa code, because there's nothing alsa specific in this logic.
> 
> i tried it that way initially. however, by the time those functions  
> are called, their data->proplist args already contain a  
> PA_PROP_DEVICE_DESCRIPTION (ensured by the earlier call to  
> pa_device_init_description() from pa_alsa_sink/source_new), and this  
> in turn causes the pa_device_init_description() to return immediately  
> this second time around
> 
> one could look to override this description, but by then it appears  
> too late, as we may not be dealing with a default (sink/source) device  
> description at all, and so prefixing a card device description could  
> be the wrong thing to do. hence i couldn't see any reasonable way to  
> keep the logic there

Ok, I see the problem. I have an alternative proposal: pass the pa_card
pointer to pa_alsa_init_description() and pa_device_init_description(),
and then in pa_device_init_description() use the card's description to
set the sink/source description. This way non-alsa specific logic stays
in the generic part of the code. Also, we don't need to add the
device.card.description property.

-- 
Tanu



[Index of Archives]     [Linux Audio Users]     [AMD Graphics]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux