[pulseaudio-discuss] [RFC] Passthrough support
arun.raghavan at collabora.co.uk
Wed Feb 16 13:13:19 PST 2011
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.
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.
More information about the pulseaudio-discuss