On 2014-06-25 11:47, Tanu Kaskinen wrote: > On Tue, 2014-06-24 at 15:37 +0200, David Henningsson wrote: >> >> On 2014-06-24 15:01, Tanu Kaskinen wrote: >>> On Tue, 2014-06-24 at 13:19 +0200, David Henningsson wrote: >>>> I remember thinking that pa_ext_volume_api_bvolume should include a "int >>>> mute" field. Then every mute specific stuff, including mute controls, >>>> can be skipped. >>> >>> I don't like that. Any struct that contains both volume and mute will >>> also need "bool has_volume" and "bool has_mute" fields (or a type enum >>> for either/or choice). >> >> Wouldn't be typical for a control to have both volume and mute? E g, a >> sink has both volume and mute, right? Instead of having two objects and >> leave to the client to group them together, it would make more sense to >> keep them as one object and let clients turn it into two if necessary. >> >> Or, why wouldn't a volume also have a mute? > > If we route things in domains where pulseaudio doesn't have access to > the audio data, we're at the mercy of whatever controls the domain > provides. For example, when routing audio from cellular modem to > speakers without ever seeing the audio data in pulseaudio, there's no > guarantee that the hardware has both volume element and a mute switch > for the audio path. It can have one or the other. I haven't worked with > such systems, though, so I don't know what the situation is with real > hardware out there. Well, with that argument we could just as well use pa_cvolume. Because we don't know if the hardware maintains balance when main volume is -inf either. We decided to have an extra "main" volume not to lose balance information, we can have an extra mute not to lose "main" volume when the stream/sink/etc is muted. > It can also be that e.g. a stream should have both volume and mute, but > those control entirely different things. For example, someone once > requested a feature where the stream volume would actually control the > sink volume. I don't think that was a silly request: I might want to use > such feature myself for selected streams: for example, I might want the > volume control in Totem to control the device volume to get some of the > benefits of flat volumes (easy access to full hw volume range in > full-screen mode) without enabling flat volumes for all streams. If > stream volume actually controls the device volume, it may still be > desirable to have per-stream mute, so different controls are required > for volume and mute. > > I'll quote Alexander[1] for another use case for volume and mute > separation: "Sooner or later, someone will implement optional and > runtime-switchable automatic gain control (AGC). A natural question is: > does the whole notion of the main input volume make sense at all if AGC > is enabled?" Main input volume doesn't make sense in this case, but main > input mute does. > > [1] http://article.gmane.org/gmane.comp.audio.pulseaudio.general/19694/ Right, and compressed audio is another case where we can do sw mute, but not sw volume. >> We've already added extra information in order not to lose the balance >> when the volume is -inf, we could just as well add a mute too. >> >>> I don't think pa_bvolume is the right struct to >>> do that. This would make more sense to me: >>> >>> struct pa_control_info { >>> uint32_t index; >>> char *name; >>> char *description; >>> pa_proplist *proplist; >>> pa_control_type_t type; >>> void *data; >>> }; Do you also plan to add stream and sink pointers to two pa_control_info structs then, one for volume and one for mute? I e for introspection of sinks/streams/etc. >>> type is either PA_CONTROL_TYPE_VOLUME or PA_CONTROL_TYPE_MUTE. data >>> points to one of these structs depending on the control type: >>> >>> struct pa_volume_control_data { >>> pa_bvolume volume; >>> int convertible_to_dB; >> >> Btw, could you explain what this field (convertible_to_dB) means? > > Sinks and sources have the DECIBEL_VOLUME flag. That's exposed here, so > that clients know when they can convert pa_volume_t to decibels. So in short, expect convertible_to_dB to always be true, if it's false, we're dealing with "bad" hardware that does not know what their volume steps mean? We could do the full capabilities thing that ALSA does - tell exactly what steps and so on that the hw supports. In which case we can merge volume and mute - a mute control is just a volume control with two steps. But this does not seem to be what you're planning. I can understand that mute and volume are the most common types of (volume) controls. But conceptually, we have everything in between too: Per channel mutes (common in hw and ALSA), volume with a limited number of steps, and so on. Considering this, and the boundary between volume and mute is fluid. But maybe that is just to over-generalising things and we should stick to volumes and mutes, like you suggest. -- David Henningsson, Canonical Ltd. https://launchpad.net/~diwic
