[pulseaudio-discuss] Description for virtual sinks
lennart at poettering.net
Thu Mar 26 11:38:09 PDT 2009
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
> 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
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
> 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 Poettering Red Hat, Inc.
lennart [at] poettering [dot] net ICQ# 11060553
http://0pointer.net/lennart/ GnuPG 0x1A015CC4
More information about the pulseaudio-discuss