[pulseaudio-discuss] Stream Class in PulseCore
Justin Tulloss
jmtulloss at gmail.com
Mon Jul 30 15:58:14 PDT 2007
That sounds great.
I'd be happy to implement some of this stuff, but unfortunately, we're
working with PA 0.9.6 since we wanted a stable release. I suppose I could
sync down the lennart branch and start looking into implementing some of
this tagging stuff. Due to the lack of documentation, I'm pretty familiar
with the pulse sources :). Did you have a specific plan in mind for how to
implement metadata tagging? I don't think it would take long to add. The
policy language would obviously be substantially more involved and would
require more forethought on how it should work.
Finally, how stable is the lennart branch? If at all possible, I would like
to adapt the modules I've written to the new core so that it doesn't need to
be done by somebody less familiar with the source when I've moved on to
other things. At the same time, I need to deliver a fairly stable rendition
of pulse, so if the core isn't relatively stable, I can't justify it.
Thanks,
Justin
On 7/30/07, Lennart Poettering <lennart at poettering.net> wrote:
>
> On Thu, 12.07.07 16:12, Justin Tulloss (jmtulloss at gmail.com) wrote:
>
> > Hello,
>
> Hi!
>
> > Right now I'm using the names of streams to indicate class. I was
> wondering
> > if, going forward, there would be support for adding a "class" tag to
> all
> > streams, along with the accompanying facilities to control streams by
> class
> > instead of just by name.
>
> My plan is to add the ability to attach a complete set of meta
> information to each stream. Besides a "class" (which i called "role")
> this would be among other stuff:
>
> IDENTIFIER
> NAME
> DESCRIPTION
> CLIENT_IDENTIFIER
> CLIENT_NAME
> CLIENT_DESCRIPTION
> ROLE
> X11_DISPLAY
> X11_WINDOW
> LANGUAGE
> ICON_DATA
> ICON_NAME
> ICON_FILE
> PROCESS_ID
>
> This set of course would be extensible, a little bit like X11
> properties. The properties we already have (like the name) should the
> be folded into this set of properties.
>
> This information can be used for a10y stuff, for "window managers for
> sound" and for fixed policy routing.
>
> As next step we would than add some kind of policy language which
> could be used to specify the routing of streams. I envision something
> similar to HAL .fdi files, though hopefully easier to optimize.
>
> But anyway, right now I am focused on the real-time lock-free
> stuff. This stuff is probably th next thing I will focus on.
>
> > Also, if people do want to see this, would the lead development team
> > (Lennart, as far as I know), be willing to accept patches to the current
> > trunk that would enable the support, or is all development going forward
> > going to be in the lennart branch?
>
> Everything that is more than simple bug fixing should go only into the
> "lennart" branch.
>
> Lennart
>
> --
> Lennart Poettering Red Hat, Inc.
> lennart [at] poettering [dot] net ICQ# 11060553
> http://0pointer.net/lennart/ GnuPG 0x1A015CC4
> _______________________________________________
> pulseaudio-discuss mailing list
> pulseaudio-discuss at mail.0pointer.de
> https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/pulseaudio-discuss/attachments/20070730/a7c36b94/attachment.htm>
More information about the pulseaudio-discuss
mailing list