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. I'm looking at the current repository right now trying to figure out how the Mixers will be working.
It looks like the output plugins and the mixer plugins are completely decoupled, and I think this will be an issue with the RAOP plugin. There are two different tcp socket connections that are made to each RAOP Device (Airport Express unit), one (command) http/text based, the other (data) for the audio stream. The command channel sets up the connection, gets the port number for the data channel, and is used for flushing the buffer, tearing down the connection, and changing the volume. While the mixer needs the ability to change the volume, the audio plugin needs everything (muting when the stream is paused). 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.) 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.) 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. Or maybe add a create_mixer method to audio_output_plugin? Sorry to pop in so late in the game, but I didn't know about the project until a couple days ago when looking for something that could better control raop_play over the network. I've tried looking at the archives for this mailing list, but it has been overwhelmed with spam. Dustin ------------------------------------------------------------------------------ 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
