[pulseaudio-discuss] GSoC Proposal: Configurable maximum volume for sinks and sources

[Matěj Laitl]

On 26. 3. 2012 Tanu Kaskinen wrote:
> On Sun, 2012-03-25 at 16:45 +0200, Matěj Laitl wrote:
> > Hi Tanu and pulseaudio-discuss,
> > I'd like to participate as a student in GSoC 2012 working on PulseAudio.
> > Among suggested ideas I've chosen Configurable maximum volume for sinks
> > and sources, below is a very draft of my proposal.
> > I've also thought about extending
> > the proposal a bit to add code to deal with stereo microphones where one
> > channel is inverted (supposedly common problem) -- but I've heard on
> > #pulseadio this is already being worked on. What do you think?
> 
> IIRC, if someone is working on this, it's David Henningsson. My
> impression is, though, that there's no implementation work done yet. So,
> hopefully David can give a status update. Probably this microphone fix
> would be a fine extra project for the summer. Do you have this
> microphone problem yourself?

No, but by girlfriend does (which is probably worse) :) and it is further 
worsened by proprietary Skype crap that keeps adjusting mixer levels even if 
told not to do so.

> Note, however, that there's another "extra" job that you'd preferably do
> before starting with the volume things (or at least before starting to
> extend the client API), which reduces the probability of running out of
> stuff to do. One of the project ideas is a "configuration system". There
> was a discussion between me, Colin and Arun, and we thought that it
> would be really good if the volume limit feature could use the
> configuration system's client API as the client interface. Since the
> configuration system doesn't exist, designing the client API for it
> would have to be part of the volume limit project. The API probably can
> be quite simple, since all it has to do is to provide means for getting
> and setting configuration values and for subscribing to updates. You
> wouldn't have to implement the whole configuration infrastructure, only
> as much as is needed to make the limit configuration to work. We should
> update the idea page to reflect this...

Okay, no problem. So, what are goals of such configuration system? How should 
it fit into existing pulseaudio configuration possibilities in /etc/pulse? It 
looks like a simple key->value storage, but at least volume limits should be 
per-port as mentioned, others may be per-{server,module,stream,source,sink}?

> BTW, as you obviously have found #pulseaudio, what's your nick?

My nick is strohel, but due to school, I hang there very infrequently 
currently. (and I have yet to setup a bouncer)

> > 
> > Implementation
> > =========
> > [this section is based on my rather incomplete understanding of the code;
> > please correct me where I'm wrong]
> > 
> > PulseAudio's architecture is based on modules that can provide Sources
> > (audio inputs), Sinks (audio outputs), networking protocols and more.
> > Sinks are represented with a C struct pa_source defined in
> > pulsecore/sink.h; Sources use analogous structure pa_sink. Modules then
> > implement Sources and Sinks by setting various callbacks in the structs
> > to their functions and filling fields with their data.
> > 
> > [TODO: this project should focus on ALSA, right?] Relevant for this
> > project is the module-alsa-card (which shares Sink and Source code with
> > module-alsa-sink, module-alsa-source) that implements Sinks & Sources
> > atop of the most prevalent Linux sound system, ALSA. For the first
> > iteration, the module(s) will be made to accept volume_limit parameter
> > that will be enforced in
> > {sink,source}_set_volume_cb() (TODO: this seems to only work for 
> > hardware volumes?)
> 
> It should be possible to set limits for any devices, not only for alsa
> devices. There may be need to adapt the backend modules to the changes,
> but the focus should be in working with sinks, sources and device
> ports[1] in general, not with some specific backend. The set_volume_cb
> functions indeed only work with hardware volumes, so they aren't really
> the right place to do the limit enforcement.

Okay, I will reformulate that the work will concert mainly pulsecore, 
modifying modules where needed to comply to new requirements.

> Volume handling is pretty complex in Pulseaudio, so getting a good
> picture of the whole volume system will probably take some time. Here's
> one hint: you'll want to apply the limit to reference_volume. That's the
> volume that you see in KMix.

Thanks. I'm reading [2] and [3] too, I didn't get everything yet, but give me 
some time.

> I wrote in the wiki that the project would start with making it possible
> to configure the limits with module arguments, but actually I don't
> think that is a very important feature in the end. You can do that if
> you start with implementing the volume limits and you need the module
> arguments for experimenting in the beginning, but if you start with the
> client API, that should make experimenting easy without any new module
> arguments.

Okay. I forgot to make it clear that module arguments would be just an 
intermediate mean to test things out that will eventually go away. But as you 
say, I may rather start from client API down without ever introducing some new 
module parameters.

> [1] The limits need to be handled separately for each port. It's not
> sufficient to have per-sink limits.

Hmm, is there any documentation on ports? I seem to find much less information 
on them compared to sinks & sources.

> Sounds very promising so far! Sorry for ruining your timeline
> planning :)

Good. Never mind that, the timeline was very quickly written just to get the 
discussion started.

Regards,
			Matěj

[2] 
http://www.freedesktop.org/wiki/Software/PulseAudio/Documentation/Developer/Volumes
[3] 
http://www.freedesktop.org/wiki/Software/PulseAudio/Documentation/User/PulseAudioStoleMyVolumes