On Wed, 2011-02-16 at 19:17 +0530, Arun Raghavan wrote:
> > Can you elaborate on what you had in mind regarding UIs?
>
> As for UIs, it would probably be nice to have some sort of (hidden by
> default) way to show supported format in a sink. Of course, pactl/pacmd
> would expose this data too. Other than informative purposes, it would
> also make debugging simpler ("Hey, my BT headset isn't playing MP3s
> automatically" .. "Can you check if it's actually supported using these
> simple steps?")
Yes, the supported formats should be provided in the sink introspection
data. This isn't necessarily relevant when creating streams, though.
> > > > Does the assumption, that all sinks support PCM streams, cause some
> > > > actual consequences in terms of API? I can't immediately see any
> > > > consequences - it seems like an implementation detail that can be
> > > > changed later. (I'd like to reserve the possibility to have
> > > > passthrough-only sinks in the future, just in case.)
> > >
> > > Fair enough. The only niggling API change would be adding a
> > > PA_FORMAT_PCM_ANY (it would be unwieldy to return one pa_format_info for
> > > each PCM format).
> >
> > I think the PA_SAMPLE_* enumeration should be left alone. Let it be a
> > legacy thing for clients that aren't interested in anything else than
> > PCM. pa_format_info doesn't need the pa_sample_spec member. The encoding
> > type can be provided with a new enumeration with PA_ENCODING_PCM,
> > PA_ENCODING_MP3 etc. Then the proplist, or whatever is chosen for
> > representing the format set, can contain information saying that
> > everything is supported.
>
> I didn't get the last bit about what you'd add to the proplist. The
> separate enum would work well for the format_info struct, but would you
> also suggest extending the API to use the encoding type while setting
> up/connecting streams?
I would suggest that the sinks and the clients use the same presentation
for describing the supported formats. It may be a proplist or something
else. In a purely proplist-based solution there may be no need to extend
the stream creation API. However, a purely proplist-based solution would
look hacky to me, but that's a matter of taste.
If I had to decide the format set representation now, I might do it as
follows:
typedef enum pa_encoding {
PA_ENCODING_PCM,
PA_ENCODING_MP3,
...
}
typedef struct pa_format_desc {
pa_encoding_t encoding;
pa_proplist *params; /* string -> string: parameter name
* to parameter value. The parameter
* value has syntax for representing
* also lists and ranges. Missing
* parameter means that anything is
* allowed, unknown parameters are
* ignored. */
} pa_format_desc;
Uh, that ended up pretty identical to your pa_format_info proposal, even
though I didn't mean to :) I tried to replace the proplist with a
solution that doesn't require any string parsing, but that ended up very
complicated.
I'm proposing that a new function is added for creating streams that
takes a list of pa_format_desc structs (or maybe pa_format_info is a
better name) instead of sample spec and channel map.
--
Tanu
