On Tue, 2011-02-15 at 12:33 -0600, pl bossart wrote:
> > Please review/comment. Once we have some consensus, I'll send in patches
> > to actually get this done.
[...]
> - 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.
This one will probably be somewhat contentious. I was going to put this
information in the format_info structure's proplist so clients can read
and match as they please. There is one stumbling block here in that
proplists do not allow list or range types.
We can either support these by abusing the proplists a bit (for ranges
have a "prop.min" and "prop.max", for lists have "prop.num_elements",
"prop.elem_0", "prop.elem_1", etc.), using simple strings (the way
GstCaps are done) or add first-class list and range types. Listed in
increasing order of effort.
IMO the first is too hacky. The second is quite flexible, but
potentially too generic? The third is the most disruptive, but also most
exactly suited to what we need.
I'm leaning towards the second (string representation like "(type) [min,
max]" for range and "(type) { val1, val2, val3 }" for list). In the
current context, the type might be implicit in the key, but since this
literally becomes part of the API, I'd like to plan ahead.
Thoughts?
-- Arun
