> 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: - change raw to PCM, it's less ambiguous. - 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. - 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? - 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. - you want to add E-AC3 as a basic format. It uses a different IEC syntax - 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. - Changing the monitor is tricky, we may want to keep it but either tag the data as IEC as well, or just zero out. - 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 am sure others will have some remarks as well. -Pierre
