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

[David Henningsson]

On 03/26/2012 06:20 PM, 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.
>
> Excellent!
>
>> I'd be very grateful for any comments, suggestions, pointed-out omissions and
>> general questions that may arise. 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?

Nothing has happened since our IRC discussion a few weeks ago, where I 
think we opened up to making the change in PulseAudio. Since then, I've 
been figuring if it would be possible to fix in alsa-lib by making a 
separate profile for the internal mic (i e, you open the ALSA devices 
string "internalmic:0" or something, instead of today's "front:0" for 
all inputs).

But I haven't raised this on alsa-devel yet, so not sure how doable this 
is. I just feel that it should be alsa's responsibility to give us a 
correct signal. Or if it can't, at least signal to us when it gives us 
an inverted signal, so we don't have to write quirk tables here.

(snip)
> It should be possible to set limits for any devices, not only for alsa
> devices.

Agreed. This is a feature for the core, not the driver backend.

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

And per-port volumes should move into the core, instead of just residing 
in module-device-restore.

There are a lot of things to do, and making a good selection for a GSoC 
student, and what others can commit to to make that work out, isn't 
always trivial...


-- 
David Henningsson, Canonical Ltd.
http://launchpad.net/~diwic