On 8/11/23 14:39, John Watts wrote:
On Tue, Aug 01, 2023 at 12:28:29AM -0700, Dmitry Torokhov wrote:
If we want to extend the API we will need to define exactly how it will
all work. I.e. what happens if userspace mixes the old SND_TONE and
SND_BELL with the new SND_BELL_VOL or whatever. Does it play with
previously set volume? The default one? How to set the default one? How
to figure out what the current volume is if we decide to make volume
"sticky"?
As far as userspace I expect it is more common to have one program (or
component of a program) to set volume and then something else requests
sound, so having one-shot API is of dubious value to me.
I hope we can go with Takashi's proposal downthread, but if not I wonder
if the sysfs approach is not the simplest one. Do we expect more beepers
that can control volume besides pwm-beeper?
Thanks.
--
Dmitry
(Just to duck in as someone that has written a little program to play beeps and
tones using the EV_TONE API)
It might be worth distinguishing between the goals of having some beeps with
different volumes compared to all beeps with different volumes.
Sound card mixers generally control some sort of global volume while I would
imagine the tone API would control per-tone volume. I don't know too much about
safety guarantees but writing an input then sysfs or mixer then input again
seems like it could get jumbled up.
In that speicfic case I think it would make more sense to send volume and tone
from whatever beep API is being used, with the volume being a multiplier of the
loudest volume. This is similar to how audio works with PCM output. Existing
beeps would have the volume set to 100%.
I agree binding tone frequency and volume together would be better.
The API would be nicer and easier to use in my opinion too.
