On Thu, 2012-04-05 at 16:13 +0100, Colin Guthrie wrote: > 'Twas brillig, and Tanu Kaskinen at 05/04/12 14:24 did gyre and gimble: > > Specifying the volume when creating a new stream is not an > > equivalent act as setting the volume with a volume control > > application. When creating a new stream, stream-restore > > shouldn't save the volume, but when changing the volume, > > then saving it is ok. For example, when I say > > "paplay --volume=10000 somefile.wav", I mean that I want the > > new stream to have volume 10000. I don't mean that also > > future paplay invocations (without the --volume option) > > should have that same volume. > > My initial reaction on seeing this commit was, I would consider passing > a volume with a new stream as user input... > > > This patch effectively reverts > > 546bcf3f2f9711f0d08c21c3b775994844e7e2a2. > > ... which is exactly what Lennart said in this commit! Spooky! > > But on reflection, I'm not sure what I really feel about this. > > All in all, I think we want to discourage clients from setting volumes > like this anyway (paplay is arguably a special case), as they are trying > to outsmart us and override user settings (e.g. how does the app know if > it is controlling a category wide volume or just itself, or the volume > as was on the Headphones port vs. the Speaker - so it shouldn't even try!) > > But yeah, I don't see any massive problem here regarding not considering > it user input, but wouldn't be surprised if a counter argument cropped up... No counter arguments received - I've pushed the patch now. -- Tanu
