Description for virtual sinks

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

 



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



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

  Powered by Linux