On Thu, 26.03.09 19:16, Maarten Bosmans (mkbosmans at gmail.com) wrote: > It's good to think about a generic way to set all these properties, on > all sources, sinks, etc. This way we avoid all the separate patches, > like the ones for module-remap-sink and airport. > > On Thu, Mar 26, 2009 at 3:40 PM, Lennart Poettering > <lennart at poettering.net> wrote: > > The only non-trivial issue here is that the two parsers don't > > interfere with each other. i.e. that doing stuff like > > > > ? proplist="foo='bar waldo' yippieh='wow'" > > > > is parsed properly. And that it still is possible to include quotation > > marks of all kinds in the property strings. > > May be it is easier to avoid the double quoting and recognize all the > defined properties as module parameters. You could just parse all the > recognized options and pass the rest to pa_proplist_from_string(). For > example: > > load-module module-combine slave=sink1,sink2 device.description="my > device" application.icon_name="my icon" Nah, this approach might hide typos: i.e. you wanted to type "sink_name=blah" and typed "sink.name=blah" accidently and Pa wouldn't notice and just take the parameter as property. I am against hiding typos. Also, for modules that register more than just one sink, or more just one source, or more than just one card it is certainly interesting to allow the user to set different properties for those different sinks/sources/cards. Having a single list of properties doesn't really allow that. However, my suggested solution would allow this: i.e. "sink_proplist=..." is independant from "source_proplist=..." and so on. > Another approach is separate set-*-property commands. I would really > like to be able to fire up pacmd and just say: > > set-sink-input-property StreamName media.artist "Artist Name" > > These commands could even entirely replace the suggested syntax for > load-module. You could just do: > > load-module module-alsa-sink device="hw:0,0" sink_name=asink > set-sink-property asink foo "bar waldo" > set-sink-property asink yippieh wow Doesn't really work either. It is important that those properties are set right when the sink/source/card is created instead of later on. Why? Some properties are relevant for policy decisions, i.e. setting device type to "headset" might have the effect that all "phone" tagged streams are moved over to it. And we want to make sure that only one atomic policy decision needs to take place, not many with incomplete property sets. Lennart -- Lennart Poettering Red Hat, Inc. lennart [at] poettering [dot] net ICQ# 11060553 http://0pointer.net/lennart/ GnuPG 0x1A015CC4
