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
