[pulseaudio-discuss] Stream Class in PulseCore

[Lennart Poettering]

On Mon, 30.07.07 15:58, Justin Tulloss (jmtulloss at gmail.com) wrote:

> 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

We finally have some (terse) documentation for the PA internals -
although only for the "lennart" branch:

http://pulseaudio.org/wiki/ThreadingModule

and

http://pulseaudio.org/wiki/WritingModules (thanks to tanuk!)


> 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.

Yes, the policy language needs a lot of thought.

What I currently have in mind is an API where you can assemble a set
of properties into a property set object. And than attach a property
set object to a stream, client, sink, source or the core.

We already have an API in this style in pulsecore/props.h but it is
too simple and only allows attaching props to the core object, not to
streams, clients, and so on. 

The property system doesn't need to by typesafe, but should be able to
take arbitrary data (to properly support setting of icon images)

The API should probably look like this:

pa_propset *pa_propset_new(const char *name, const char *data, ...)
void pa_propset_free(pa_propset *p);
void pa_propset_set(pa_propset *ps, const char *name, const char *data, ...);
void pa_propset_set_arbitrary(pa_propset *ps, const void *data, size_t size);
void pa_propset_merge(pa_propset *ps, pa_propset *m);
void pa_propset_get(pa_propset *ps, const char *name);
void pa_propset_remove(pa_propset *ps, const char *name);

The constructor and _set() would be variadic functions to allow easy initialization:

ps = pa_propset_new(
        PA_PROPERTY_NAME, "Playback stream", 
        PA_PROPERTY_IDENTIFIER, "org.gnome.Totem.Playback",
        PA_PROPERTY_LANGUAGE, "en_US",
        NULL);

and then one could attach this to a pa_sink_input, or a pa_sink, or a
pa_stream with a single _attach() call or similar.

The PA_PROPERTY_xxx constants should be strings and should have a
namespace, similar to filesystem xattrs. The namespace "pulse." would
be special and reserved for PA. Whenever one of the properties of the
"pulse." name space is modified in a pa_propset an implicit validity
checking would take place (i.e. UTF-8, and so on.) We would then
define macros like this:

#define PA_PROPERTY_NAME "pulse.name"
#define PA_PROPERTY_IDENTIFIER "pulse.identifier"
#define PA_PROPERTY_ROLE "pulse.role"
#define PA_PROPERTY_LANGUAGE "pulse.language"
...

That's basically what I have in mind for now.

> 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.


The "lennart" branch is not very stable. Neither in API not during
runtime. Sorry.

Lennart

-- 
Lennart Poettering                   Red Hat, Inc.
lennart [at] poettering [dot] net    ICQ# 11060553
http://0pointer.net/lennart/      GnuPG 0x1A015CC4