On Wed, 2012-05-30 at 11:36 +0300, Dalleau, Frederic wrote: > 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. You can probably get around that by setting some dummy values to the sample spec, but I believe this is a bug in pa_sink_input_new(), and it should be fixed (you don't have to do that, though). pa_sink_input_new() should do something more intelligent than call pa_format_info_from_sample_spec() if the FIX_FORMAT, FIX_RATE or FIX_CHANNELS are set. > 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. I don't understand this paragraph. > 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 ? Clients won't be able to see the intermediate state between sink creation and the proplist update. The communication with the clients is done only after the main thread execution has returned to the event loop. -- Tanu
