[pulseaudio-discuss] [RFC] Passthrough support (extending proplists)

[Colin Guthrie]

'Twas brillig, and Arun Raghavan at 16/02/11 04:42 did gyre and gimble:
> 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?

Random suggestion:
 1. The range thing seems simple enough the prop.min and prop.max seems
like an easy enough thing to list and support (perhaps even with a
wrapper function if it saves a bit of sanity checking).

 2. The lists are slightly harder, so how about we just support JSON
style syntax here for simple array storage? i.e. "['val1','val2','val\'s
beyond']" ? Again a  wrapper function or two can help create/decode
these? Using a format like JSON should be pretty simple and we could
easily enough push out the whole proplist as a single JSON encoded thing
at some point in the future if needed too.

Col



-- 

Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/

Day Job:
  Tribalogic Limited [http://www.tribalogic.net/]
Open Source:
  Mageia Contributor [http://www.mageia.org/]
  PulseAudio Hacker [http://www.pulseaudio.org/]
  Trac Hacker [http://trac.edgewall.org/]