<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">Hi Tanu,<div><br><div><div>On May 3, 2008, at 1:55 PM, Tanu Kaskinen wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><span class="Apple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0; ">On Sat, May 03, 2008 at 11:48:04AM -0700, Nick Thompson wrote:<br><blockquote type="cite">I fully accept that my use of pulse might be somewhat unorthodox since <br></blockquote><blockquote type="cite">it is in a speciailsed embedded system, however I also think that <br></blockquote><blockquote type="cite">multiple device support and routing is of great interest, especially <br></blockquote><blockquote type="cite">to the music community.<br></blockquote><br>If you're part of the music community, you probably should<br>be looking at Jack (<a href="http://jackaudio.org/">http://jackaudio.org/</a>). Except that even<br>though it has marvelous support for routing audio, it<br>doesn't support multiple devices directly. You might have<br>success by using a program called Jack Diplomat (which<br>connects multiple Jack servers). Better support for multiple<br>sound cards is planned for future versions, but I don't<br>expect it to happen anytime soon.</span></blockquote></div><br></div><div>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.</div><div><br></div><div>I don't think Jack currently has what I need, but thank you for the suggestion.</div><div><br></div><div><blockquote type="cite" class=""><span class="Apple-style-span" style="color: rgb(0, 0, 0); "><blockquote type="cite">Phew. Anyway the second question was not really answered fully. It <br></blockquote><blockquote type="cite">might be my imprecision in stating the problem so let me try to <br></blockquote><blockquote type="cite">distill it to the bare bones: For pulseaudio I'd like to know how or <br></blockquote><blockquote type="cite">if a virtual stream can be created in pulse allowing on the fly <br></blockquote><blockquote type="cite">redirection to an ALSA sink, that is the crux of the question that I'm <br></blockquote><blockquote type="cite">searching for an answer. I'd like in an alsa program (or set of <br></blockquote><blockquote type="cite">programs) to write to a virtual device and have pulse route all audio <br></blockquote><blockquote type="cite">on that device to a sink, and be able to switch sinks on the fly. <br></blockquote><blockquote type="cite">I've spent a couple weeks looking into this and I think I've made <br></blockquote><blockquote type="cite">quite a lot of progress but that part is not clear.<br></blockquote><br>It's not possible with current virtual devices. The virtual<br>devices that you can create don't allow their streams (the<br>ones from the virtual device to the destination sinks) to be<br>moved.<br><br><blockquote type="cite">I could write a pulse module that will implement routing policy for <br></blockquote><blockquote type="cite">individual stream, but since streams are created often I'd need to to <br></blockquote><blockquote type="cite">track them (not too hard) and know when they are created (harder) and <br></blockquote><blockquote type="cite">set the routing before the stream starts (no sure how to do this). It <br></blockquote><blockquote type="cite">seems there might be an easier way, but I don't know what that is.<br></blockquote><br>Writing a module is one possibility. A virtual sink, of<br>which master sink can be changed, doesn't sound a bad idea<br>to me. module-remap-sink could be a good starting point, but<br>I believe it would still take quite a bit of time to figure<br>out the internal APIs.<br></span></blockquote><div><br></div>I think I'm going to have to figure out the internals of pulse to do this, no way round that.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>Unfortunately more questions :)</div><div><br></div><div>Nick</div><div><br></div></body></html>