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
_______________________________________________
pulseaudio-discuss mailing list
pulseaudio-discuss@mail.0pointer.de
https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
