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
_______________________________________________
pulseaudio-discuss mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
