[pulseaudio-discuss] Moving sources and sinks
rextanka at comcast.net
Sat May 3 16:48:05 PDT 2008
On May 3, 2008, at 1:55 PM, Tanu Kaskinen wrote:
> On Sat, May 03, 2008 at 11:48:04AM -0700, Nick Thompson wrote:
>> I fully accept that my use of pulse might be somewhat unorthodox
>> it is in a speciailsed embedded system, however I also think that
>> multiple device support and routing is of great interest, especially
>> to the music community.
> If you're part of the music community, you probably should
> be looking at Jack (http://jackaudio.org/). Except that even
> though it has marvelous support for routing audio, it
> doesn't support multiple devices directly. You might have
> success by using a program called Jack Diplomat (which
> connects multiple Jack servers). Better support for multiple
> sound cards is planned for future versions, but I don't
> expect it to happen anytime soon.
Thanks for this. My project is purely ALSA and pulse based for an
embedded system, however it was my contention that a facility for
switching all streams on a virtual device to a sink, then possibly
reconfiguring all the streams to render on another sick would be a
good thing for music people on x86 and other platforms (unfortunately
not what I'm using for deployment :) Although I am doing experiments
on x86 to understand how pulseaudio works.
I don't think Jack currently has what I need, but thank you for the
>> Phew. Anyway the second question was not really answered fully. It
>> might be my imprecision in stating the problem so let me try to
>> distill it to the bare bones: For pulseaudio I'd like to know how or
>> if a virtual stream can be created in pulse allowing on the fly
>> redirection to an ALSA sink, that is the crux of the question that
>> searching for an answer. I'd like in an alsa program (or set of
>> programs) to write to a virtual device and have pulse route all audio
>> on that device to a sink, and be able to switch sinks on the fly.
>> I've spent a couple weeks looking into this and I think I've made
>> quite a lot of progress but that part is not clear.
> It's not possible with current virtual devices. The virtual
> devices that you can create don't allow their streams (the
> ones from the virtual device to the destination sinks) to be
>> I could write a pulse module that will implement routing policy for
>> individual stream, but since streams are created often I'd need to to
>> track them (not too hard) and know when they are created (harder) and
>> set the routing before the stream starts (no sure how to do this).
>> seems there might be an easier way, but I don't know what that is.
> Writing a module is one possibility. A virtual sink, of
> which master sink can be changed, doesn't sound a bad idea
> to me. module-remap-sink could be a good starting point, but
> I believe it would still take quite a bit of time to figure
> out the internal APIs.
I think I'm going to have to figure out the internals of pulse to do
this, no way round that.
Given what you say (above) about per device routing not being possible
I think the area I'd like to concentrate on is figuring out how a
module can detect streams as they are being created. That way it
could get the call in to switch sink input before the stream is
started. So figuring this out would be a great start.
I've been looking at a client app (it is, I think necessary to have
one to relay policy info about routings to the module), but I don't
think stream routing via a client would be a good way to address the
issue. There is likely to be a fair lag between a stream being
created, a notification being received that the stream has been
created, to communication to the client, and the communication back to
the client to switch a sink input. There doesn't appear to be a means
to do most of this from a command line, and its not clear to me how
the ipc mechanism between the client and the daemon can be exploited
to this end.
So I think a client would provide the current policy for a pulse
module and the module would bang on the streams as they are created to
ensure their routing meets the requirements of the currently
implemented policy. But the actual work of switching the streams
would, I think, happen in a pulse module.
Unfortunately more questions :)
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the pulseaudio-discuss