[pulseaudio-discuss] [RFC] Passthrough support

[Arun Raghavan]

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