[pulseaudio-discuss] [RFC] Passthrough support

[Arun Raghavan]

On Tue, 2011-02-15 at 12:33 -0600, pl bossart wrote:
> > Please review/comment. Once we have some consensus, I'll send in patches
> > to actually get this done.
> 
> Thanks Arun,
> this is a good start. Couple of comments:

Thanks for the detailed review. Responses inline ...

> - change raw to PCM, it's less ambiguous.

Ack.

> - I am not sure I understand how/when the query would be used. Seems
> to me like a notification with the formats exposed by the sink
> currently selected would be more usable. And if a change in routing
> happens (new accessory, audio policy, etc), the client is informed and
> can reconfigure to PCM if need be.

In this scheme, how would the client first determine what formats are
available? The notification will also be required - we can either
piggyback in sink, sink-input and card change notifications, or
introduce a new one for a change in available formats (I prefer the
latter).

> - I think we need to look at the 'start_move' and 'finish_move' as
> well. If a reconfiguration to PCM is needed, we may need to wait until
> the client sends PCM again?

Ah, this isn't clear in the proposal at all. As Tanu pointed out, when
moving, the client needs to disconnect the existing stream and connect
with a new stream anyway. That said, it would be nice to give the client
fair warning instead of pulling the stream out from under it's feet.
I'll dig in a bit and try to find a more elegant approach here.

> - I am not sure the channel map matters for compressed data. The
> receiver will adjust anyway to the actual number of speakers, e.g.
> downmix if you use a headset.

I presume you mean in the query API? I've kept all the arguments we pass
to pa_stream_new() and pa_stream_connect_playback() to be future-proof.
In most cases, everything but the stream flags and proplist will be
NULL, but if, at some point in the future, any of the other parameters
start to be used in routing.

(not very practical example: if the receiver expects input as a
particular channel map, but the compressed data has a different mapping,
we would claim to not support that format so the client would have to
decode and then remap in PA)

> - you want to add E-AC3 as a basic format. It uses a different IEC syntax

Ack.

> - The receiver may support the same format at different sampling
> frequencies (eg MPEG at 32, 44.1 and 48kHz but not any other for BT).
> We will need to list explicitly which sampling frequencies are
> supported for each format.

[taking this up in a separate thread]

> - Changing the monitor is tricky, we may want to keep it but either
> tag the data as IEC as well, or just zero out.

Right.

> - On deprecating the PA_SINK_INPUT_PASSTHROUGH: yes it can be removed
> as long as you have some means to signal that the data isn't your
> ordinary PCM. Extending the pa_sample_spec would break the API, I vote
> for a proplist here.

I think we might need to break the API here in order to keep it clean.
IMHO it is somewhat hackish to expect clients to set their sample format
to s16 stereo + passthrough flag to signal compressed data. Besides UIs
will all need to check this flag and the sink input's properties to be
able to tell what format is being played.

The only real API break is that PA_SAMPLE_MAX will change. I was
thinking of something along the lines of:

PA_SAMPLE_U8 = 0
... other PCM formats ...
PA_SAMPLE_PCM_MAX
... compressed formats here ...
PA_SAMPLE_MAX
PA_SAMPLE_INVALID = -1
PA_SAMPLE_PCM_ANY = -2

The last addition (PCM_ANY) is for convenience in the query API (you
don't need one pa_format_info for each PCM format, then).


-- Arun