'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... Col -- Colin Guthrie gmane(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited http://www.tribalogic.net/ Open Source: Mageia Contributor http://www.mageia.org/ PulseAudio Hacker http://www.pulseaudio.org/ Trac Hacker http://trac.edgewall.org/
