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
