[pulseaudio-discuss] RFC: Loopback module and DONT_MOVE flags + dormant state
frederic.dalleau at intel.com
Wed Dec 14 08:58:45 PST 2011
On Fri, Dec 9, 2011 at 5:05 PM, Colin Guthrie <gmane at colin.guthr.ie> wrote:
> At the moment there are some DONT_MOVE flags added when some arguments
> are passed to the loopback module: sink_dont_move=true etc.
> 1. rather than defaulting to FALSE, the value of sink_dont_move should
> be dependent on whether or not a sink= argument was passed. If you
> provide a sink, then it defaults to TRUE, otherwise, FALSE.
What is the sink/source selected if no argument is passed? Is it the default?
If true, then your choice is reasonnable.
> 2. Should the module itself be dormant? By that I mean should you be
> able to pass sink="wibble" source="foo" and if those devices do not
> exist rather than fail as it does now, it just sits and waits for the
> devices to appear. When they do appear it all kicks in, and all is well.
> When they disappear it goes back to it's dormant, waiting state until
> they appear again.
This feature is useful in the bluetooth area. Pulseaudio could sit
waiting for A2DP phone start streaming and music could be loopbacked
to default sink (local speaker?). And the same for Handsfree Carkit
role where pulseaudio could loopback between bluetooth and local
IMO the dormant state is a bit restrictive in what can be achieved.
I'd rather choose the module-loader. This could be more flexible in
the end. For example : loading several modules for one sink or
One of the issue I foresee with bluetooth is that sink name is quite
complicated and not easy to guess in advance. Some matching may be
More information about the pulseaudio-discuss