>> > 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.
