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