[pulseaudio-discuss] Moving sources and sinks

[Nick Thompson]

Hi Tanu,

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  
>> since
>> 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  
suggestion.

>> 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  
>> I'm
>> 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
> moved.
>
>> 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).   
>> It
>> 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 :)

Nick

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/pulseaudio-discuss/attachments/20080503/6c7d2205/attachment.htm>