Hi Tanu, Thanks for this review ! On Tue, May 29, 2012 at 2:24 PM, Tanu Kaskinen <tanuk at iki.fi> wrote: > > + sink = pa_namereg_get_default_sink(m->core); > > This still overrides the routing modules, right? > > I guess this is done, because otherwise you don't know how to initialize > ss and map? I think a better solution would be to specify the > PA_SINK_INPUT_FIX_FORMAT flag and its friends when calling > pa_sink_input_new() when neither sink or source has been given. After > the pa_sink_input_new() call, ss and map can be copied from the sink > input, which has got them from the sink to which it was routed. > PA_SINK_INPUT_FIX_FORMAT doesn't seem to work as expected. If I set this flag without defining the sample_spec, I get an assertion in pa_sink_input_new when pa_format_info_from_sample_spec is called. At first I considered that loading module loopback with specifying anything is not really a frequent use case. That make a lot of changes to add this feature I think. Now if sink or source is not set, the device description and icon name > properties are left at a suboptimal state. Instead of checking for the > sink and source pointers, maybe this proplist handling could be moved > after pa_sink_input_new() and pa_source_output_new() have been called? > At that time the sink and source would be available. > That makes sense. I'm just wondering if any application listening to sink creation will get updated from the sink creation, or if this would create an additional round of IPC for the property change ? Could this be a potential problem ? Fr?d?ric -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/pulseaudio-discuss/attachments/20120530/39ec0c6d/attachment.htm>
