On Thu, 2011-02-17 at 10:26 +0200, Tanu Kaskinen wrote:
> 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.
Ah, right. I was squashing things that aren't really related.
[...]
> 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.
Good to see we converged on the same structure. :)
<bikeshed> Building on the pa_sample_spec naming, pa_stream_spec,
perhaps? </bikeshed>
> 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.
Rethinking this, I'm starting to agree with you and Pierre on this. For
the PA_ENCODING_PCM, the proplist would basically just encode the same
data that's in pa_sample_spec. For other formats, we can add the data we
need.
I'm researching you other proposal and will update the proposal on the
wiki with both these in a while.
-- Arun
