[pulseaudio-discuss] Virtual source (microphone)

Grzegorz Kryza gkryza at gmail.com
Mon Jan 18 07:36:36 PST 2010


On Mon, 2010-01-18 at 15:41 +0100, Lennart Poettering wrote:
> On Mon, 18.01.10 13:29, Grzegorz Kryza (gkryza at gmail.com) wrote:
> 
> > Hello.
> > 
> > I'm trying to figure out how to add a virtual source device.
> > Virtual microphone available in all pulse enabled applications as a
> > sound source. Voice data for this source should be provided by a third
> > party application over a socket, pipe or any other inter process
> > communication method.
> 
> You'd have to write module that lives in the PA process first for
> that. We do not provide anything like that out-of-the-box since audio
> should best not be passed onto many other processes. For latency
> reasons you want to keep your pipelines short and every further
> context switch comes at a price, espeically if you serialize things
> onto a socket for that. Also notice that if you do implement this its
> substantially more work than simply providing a fifo a la
> module-pipe-source, since you need to implement proper timing control
> which is usually the most complex part of a feature like this.
> 
> > This can be done using 'module-pipe-source' but it was recently removed
> > from Fedora packages so I'm looking for alternative.
> 
> This won't work, since that device does not really provide any kind of
> timing control, and also also depends on apps on the other side
> read/write data in the right speed. It's mostly a toy.

Yes, but if a timing is done by a process on other side of a pipe?
We have already implemented a solution based on pipe sink/source which
takes care about providing a data in correct sample rate, format, etc.
It works well on all Linux distros with PA we tested except Fedora 12.

Writing a new PA module for sure is a better solution but it will makes
problems with distributing a new module across different distros/PA
versions. I'm also not sure if it will reduce a latency in our case...
Audio data are send across network and handled (compressed/decompressed)
by our process so some kind of interprocess communication is required
even with a new module.

Thanks for a answer.

> Lennart

Grzegorz Kryza





More information about the pulseaudio-discuss mailing list