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
