On 2009/06/02 00:50, Dustin Puckett <puck...@pobox.com> wrote: > I'm working on an output plugin for RAOP/AirTunes/Airport Express. I > am at the point where I am able to stream to one or more devices, but > it is a mess, and there are still issues with managing the connection > (pause, cancel, close). Currently, it is using the software mixer > (because I'm building off the 0.14 source), which is annoying because > it takes ~20 seconds for any volume changes take effect.
You mean this problem? http://musicpd.org/mantis/view.php?id=2356 > Since there can be multiple RAOP devices, each RAOP mixer would need > a reference to some information in the RAOP output. (I don't believe > sharing the configuration information is enough, because we can't > just open a second command channel to send volume requests.) > Should the mixer look up the Audio Output which it is managing, and > access everything it needs through that? (I think that would violate > all sorts of standards for decency.) No, the API should provide a way for the mixer_plugin's init() function to receive a reference to the associated audio_output object. Patch welcome. > Right now, each mixer plugin has a corresponding output plugin. Are > there going to be mixer plugins that apply to multiple output > plugins? I can imagine software mixers applying to multiple output > plugins, but it seems like the hardware mixers are going to be > closely tied to each other. > (I guess it would be possible that the output is hooked up to a > physical mixer which could have its volume controlled.) The software mixer is a special case, that's not a mixer_plugin. I am not sure if mixers could ever be associated with more than one audio output. I don't think so. The APIs are separate mostly for historic reasons, and for the reason that ALSA and OSS don't provide a way for identifying the "right" mixer control for a specific PCM device. > What if, the mixer_plugin method is removed from audio_output_plugin, > and replaced with get/set volume methods. > If an output has a mixer associated with it, that mixer will be used > to control the volume. > If an output's output plugin supports setvolume, it will be used to > control the volume. > Otherwise a software mixer will be used. > This should be able to do everything the current design can, it > removes an outside dependency (mixer_api.h), and offers access to > richer functionality offered by audio devices. mixer_api.h isn't included from output_plugin.h. I think the mixer_plugin should stay separate from output_plugin (on the API side), but internally, you could have one "module" exposing an implementation for both output and mixer API. > Or maybe add a create_mixer method to audio_output_plugin? That sounds like a good idea. I'm really unsure how to design the "perfect" output/mixer API, and how they should interconnect - some users expect the ALSA mixer to work even when not playing, but the Pulse mixer cannot work without its output being open - just to name one difficult design decision (somewhat solved that with the mixer_plugin.global flag). Max ------------------------------------------------------------------------------ OpenSolaris 2009.06 is a cutting edge operating system for enterprises looking to deploy the next generation of Solaris that includes the latest innovations from Sun and the OpenSource community. Download a copy and enjoy capabilities such as Networking, Storage and Virtualization. Go to: http://p.sf.net/sfu/opensolaris-get _______________________________________________ Musicpd-dev-team mailing list Musicpd-dev-team@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/musicpd-dev-team
