[pulseaudio-discuss] Playing samples with different sample_spec's

[Colin Guthrie]

Sorry for the crazy late reply.

'Twas brillig, and Roman Dmitrienko at 19/06/12 14:56 did gyre and gimble:
> Hi all,
> 
> I am developing an application that receives a stream of audio samples
> from a remote server via custom UDP protocol. The stream consists of
> small sequences of samples, each sequence may have different number of
> channels (interleaved) and rate.
> 
> As I understand, the sample_spec of the stream can only be set during
> the stream's creation (pa_simple_new, pa_stream_new, etc) and there is
> no way to switch it afterwards.
> 
> My question is: what would be the most efficient approach to these
> samples' playback in PulseAudio? I see three options:
> 1. Keep a single PulseAudio stream, manually resample the sample
> sequences and mix channels when needed (in order to feed PulseAudio
> with samples of the same sample_spec)
> 2. Keep a single PulseAudio stream, close and reopen it with new
> sample_spec when specs change
> 3. Keep a number of streams, one for every kind of samples I have to work with
> 
> Option 1 seems like a lot of manual work, and pretty much
> resource-consuming, too. Option 2 seems to be terribly inefficient.
> Option 3 looks like probably the best one, but I am concerned about
> resource consumption. Is there something I may be missing?

Yeah I think option 3 is also the best option, but even then it will be
complicated as you'll have to keep feeding all the streams to avoid any
underruns, although you should be able to "cork" (aka pause) the stream
if you were not receiving audio which would likely help but how you feed
audio into the sink inputs might require some thought.

I guess if a given stream is unused for x amount of time you could tear
it down and recreate it later on demand so you only have a few streams
alive at any time.

There is currently a limit of 32 streams per sink, so you should keep
that limit in mind when considering how many streams you should use!

That said we are thinking of increasing that limit in future releases as
it is somewhat arbitrary.


Col






-- 

Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/

Day Job:
  Tribalogic Limited http://www.tribalogic.net/
Open Source:
  Mageia Contributor http://www.mageia.org/
  PulseAudio Hacker http://www.pulseaudio.org/
  Trac Hacker http://trac.edgewall.org/