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%. John.
