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 > ..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 i felt safe shifting these changes back up to the alsa layer because nothing else appears to use this pa_device_init_description() mechanism (says grep) > The code causes a compiler warning: sorry i missed that, additional parenthesis in the attached cheers, Pete -------------- next part -------------- A non-text attachment was scrubbed... Name: alsa_.use.card.description.in.default.sink.source.prefix.when.available.diff Type: text/x-diff Size: 3245 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/pulseaudio-discuss/attachments/20140311/02a40e9a/attachment-0001.diff>
