>> + ? ?PA_SINK_PASSTHROUGH = 0x0100U >> + ? ?/**< The latency can be adjusted dynamically depending on the >> + ? ? * needs of the connected streams. \since 0.9.22 */ >> + > > Copy-paste mistake in the documentation. No this was done on purpose. We are already at 0.9.21 so the next version is logically 0.9.22? > Also, PA_IDXSET_FOREACH can be used here. Or actually you don't need to > iterate through the set at all, you could just check the first input - > if that's a passthrough input, then it's the only input anyway, and if > it's not a passthrough input, then none of the inputs is a passthrough > input. Yes. I wrote some code but somehow I dropped it. Will fix it. > I wonder if we should return a more descriptive error in case the sink > is used by other streams. Returning just "invalid argument" doesn't > allow apps to give informative error messages. What do you think? Maybe adding an error code for passthrough connections would do. INVALID is too vague I guess? > somewhere in pa_sink_input_new, and checks in protocol-native.c to > prevent that assertion from firing. That is, refuse to create > passthrough streams that also have volume specified by the client. I think it's better to ignore volume settings rather than refuse the connection?
