[pulseaudio-discuss] [RFC] Passthrough support

[Arun Raghavan]

Hello,

On Wed, 2011-02-16 at 09:56 -0600, pl bossart wrote:
> >> > 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 agree with Tanu. Changin the PA_SAMPLE_ enum will open a can of
> worms since it will create an issue with the byte-to-ms conversion. I
> tried in the past and it became a nightmare, I had to change code
> everywhere and had to lie on the results. For the passthrough to work,
> you want the IEC bistream to look like PCM 16/32 bit stereo so that
> these conversions are well handled. You would use a tag/flag/proplist
> to make sure the binary data isn't modified/resampled/etc.

For a quick proof-of-concept, I hacked up a patch to do this by changing
PA_SAMPLE_*. The bytes_to_ms conversion is handled correctly, and I
disabled monitors to start with, but we'll probably need to make this
more intelligent once we squash the passthrough profiles with the
non-passthrough ones and attach multiple formats to the sink.

http://people.collabora.co.uk/~arun/0001-pulse-Add-sample-formats-for-compressed-formats.patch

It's possible I'm missing something, but I did some quick testing on top
of your BT passthrough sink as well as with normal ALSA and A2DP+SBC
without triggering any asserts. It's certainly not complete (we need to
handle things like the Rygel sink that depend on the monitor, but that's
not a problem related to this approach).

I'm open to going with another approach if that's the consensus, but I
thought it would be easiest to just try to code it to prove feasibility
one way or the other.

Cheers,
Arun