[pulseaudio-tickets] [PulseAudio] #593: How to modify pacat to route source to sink with minimum latency

PulseAudio trac-noreply at tango.0pointer.de
Tue Jul 14 01:20:43 PDT 2009


#593: How to modify pacat to  route source to sink with minimum latency
--------------------------+-------------------------------------------------
  Reporter:  knightk      |       Owner:  lennart
      Type:  enhancement  |      Status:  new    
 Milestone:               |   Component:  clients
Resolution:               |    Keywords:         
--------------------------+-------------------------------------------------

Old description:

> I'm capturing stereo analog audio at rate=44100, format=s16le channels=2
> using module-alsa-source.
> I'm sinking out to USB at rate=44100, format=s16le, channels=2 using
> module-alsa-sink.
>
> pacat -r --format=s16le --rate=44100 --channels=2 | pacat -p
> --format=s16le --rate=44100 --channels=2
>
> is working but the latency is 1-2 seconds and a lot of packets are
> dropped.
>
> I want to modify pacat to route source to sink internally without piping.
>
> Can anyone confirm that my approach is OK, which is as follows:-
> 1) in main() comment out stdio_event = mainloop_api->io_new (because I
> don't want the daemon to poll stdin/stdout callbacks.
> 2) in context_state_callback() create both sink_stream and source_stream
> but only callback on the source_stream. Set up attr so that prebuf is 0
> and call pa_stream_trigger(sink_stream, stream_trigger_complet_cb, NULL)
> [for immediate playback], then connect for both source and sink streams.
> 3) When source_callback is called pa_stream_peek(source_stream, &data,
> &length) then pa_stream_write(sink_stream, data, length,
> PA_SEEK_RELATIVE).
>
> I'm unsure about using zero_copy i.e. data points to captured packet in
> the source buffer. Am I transferring from the source buffer to the sink
> buffer?

New description:

 I'm capturing stereo analog audio at rate=44100, format=s16le channels=2
 using module-alsa-source.
 I'm sinking out to USB at rate=44100, format=s16le, channels=2 using
 module-alsa-sink.

 {{{
 pacat -r --format=s16le --rate=44100 --channels=2 | pacat -p
 --format=s16le --rate=44100 --channels=2
 }}}

 is working but the latency is 1-2 seconds and a lot of packets are
 dropped.

 I want to modify pacat to route source to sink internally without piping.

 Can anyone confirm that my approach is OK, which is as follows:-
  1. in main() comment out stdio_event = mainloop_api->io_new (because I
 don't want the daemon to poll stdin/stdout callbacks.
  2. in context_state_callback() create both sink_stream and source_stream
 but only callback on the source_stream. Set up attr so that prebuf is 0
 and call pa_stream_trigger(sink_stream, stream_trigger_complet_cb, NULL)
 [for immediate playback], then connect for both source and sink streams.
  3. When source_callback is called pa_stream_peek(source_stream, &data,
 &length) then pa_stream_write(sink_stream, data, length,
 PA_SEEK_RELATIVE).

 I'm unsure about using zero_copy i.e. data points to captured packet in
 the source buffer. Am I transferring from the source buffer to the sink
 buffer?

--

Comment(by coling):

 To be honest I wouldnt' take this approach at all. pacat is a toy, a
 testing tool and what you are trying to do is quite hard core.

 I would create a new pulseaudio module that can be loaded with source= and
 sink= arguments that does this active passthrough. The module would be
 able to handle things much nicer.

 In addition, as the clocks of your input and output devices will vary, you
 need to have some kind of active logic in the loop to do some resampling.
 This is non-trivial code, but a similar set of code exists already in
 module-combine. It also has to deal with devices with varying clocks and
 does on-the-fly resampling.

 I strongly believe that a module is the right approach here, not a
 modification to pacat.

 I am currently working on a GUI that will allow the definition of various
 modules to load, so if you created this module, I'll happily add GUI
 support for defining such "passthroughs".

-- 
Ticket URL: <http://pulseaudio.org/ticket/593#comment:2>
PulseAudio <http://pulseaudio.org/>
The PulseAudio Sound Server


More information about the pulseaudio-bugs mailing list