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 <div>On 7/30/07, Lennart Poettering <<a href="mailto:lennart@poettering.net">lennart@poettering.net</a>> wrote:<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> On Thu, 12.07.07 16:12, Justin Tulloss (<a href="mailto:jmtulloss@gmail.com">jmtulloss@gmail.com</a>) 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 <a href="http://0pointer.net/lennart/">http://0pointer.net/lennart/</a>           GnuPG 0x1A015CC4 _______________________________________________ pulseaudio-discuss mailing list <a href="mailto:pulseaudio-discuss@mail.0pointer.de">pulseaudio-discuss@mail.0pointer.de</a> <a href="https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss">https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss </a> </blockquote></div>