[pulseaudio-discuss] [PATCH 0/4] Third try at making port properties configurable

[Tanu Kaskinen]

On Wed, 2012-04-11 at 14:39 +0200, David Henningsson wrote:
> On 04/11/2012 02:16 PM, Tanu Kaskinen wrote:
> > On Tue, 2012-04-10 at 17:02 +0300, Tanu Kaskinen wrote:
> >> Back in December I sent a patch series that implemented
> >> configurable port properties:
> >> http://thread.gmane.org/gmane.comp.audio.pulseaudio.general/12070
> >>
> >> David Henningsson pointed out that having a separate
> >> "Property List" section would be nicer syntax than having
> >> just one option in the "General" section containing all
> >> properties. I implemented that then:
> >> http://thread.gmane.org/gmane.comp.audio.pulseaudio.general/12075
> >>
> >> This time David suggested that "Properties" would be
> >> a better section name than "Property List".
> 
> Or maybe even better, make it configurable... :-) but that can maybe 
> come later, if there is ever a need.

Yes, but I think it's quite unlikely that there would ever be need for
that. "Properties" is such an awesome section name :)

> >> Also, Maarten
> >> Bosmans suggested further refactoring in the configuration
> >> parsing code: the parse callbacks could also take the parser
> >> state struct as a parameter, instead of passing all
> >> the state information in separate parameters. This third
> >> patch set implements those suggestions.
> >
> > Sorry, I was stupid and sent the patches without proper testing. The
> > second patch makes Pulseaudio crash, so please ignore this submission.
> > Also, while testing today and trying to read the port proplists with
> > pactl, I realized that it would be very nice to have the port proplists
> > included in the client protocol, and to print them in the pactl list
> > output. I'll implement those features and resubmit these patches.
> 
> The port proplist is already in v26 of the protocol.

That's correct, I just noticed that also myself. It's included only for
cards, however. I'll add it also to sink and source ports.

> In general, I totally agree with the parser_state refactoring (struct is 
> better than a lot of parameters), but I wonder if we're so close to a 
> release - and the patches are quite big - that it maybe should be 
> deferred to 3.0? I don't have a very strong opinion on the matter.

This is definitely for 3.0. I just don't want to sit on patches that are
"ready".

-- 
Tanu