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
