On Tue, 2011-02-22 at 21:25 +0000, Colin Guthrie wrote: > 'Twas brillig, and Tanu Kaskinen at 22/02/11 16:35 did gyre and gimble: > > It would be nice if someone would test this with passthrough streams > > also, but personally I think it would be ok to commit this patch to > > master now. > > OK, I've applied this to master in my tree now after giving it a bit of > a review (and removing the last bit of the commit message!) Thanks! > Only question I had really was related to this inline if which appears a > couple times: > > has_volume ? !pa_sink_input_is_volume_writable(s) : FALSE > > > Would it make sense to just return FALSE from > pa_sink_input_is_volume_writable in the case when there is no volume? The inline if is used when determining whether a stream has read-only volume. If the ternary operator is removed, and only the middle part is left, then the result is that read_only_volume gets assigned TRUE also when there is no volume at all. I don't think that makes sense, although it wouldn't be the end of the world, it would just have to be documented that read_only_volume doesn't guarantee that the volume is actually readable. I don't remember if I had any good reasons for having "has_volume" and "read_only_volume" in the client api instead of "volume_readable" and "volume_writable", except that I thought that the variables that I chose were somehow a more "natural" encoding of the two bits. If I would have chosen to put "readable" and "writable" to the client api, then this conversion of course wouldn't be needed. -- Tanu
