[pulseaudio-discuss] [PATCH v4] Make module loopback honor requested latency

[Alexander E. Patrakov]

This is mostly for Tanu's patch-status page.

I have split the patch into 11 components and sent the result to Georg 
privately. I have not done a careful self-review of the resulting 
components, and can't say that I 100% agree with the result. But there 
are definitely some things worth cherry-picking. I expect one or two 
more rounds of exchanging patches via private email.

Anyway, the original submission (i.e. the patch that I am replying to) 
has a bug: it crashes PulseAudio in the Bluetooth A2DP -> HDA test if 
one changes the sink profile from Stereo Output to 2.1 Surround Output 
while the loopback is active. Before the patch, there was no such crash.

Valgrind says:

==3812== Invalid read of size 8
==3812==    at 0x4E7588C: pa_sink_input_set_rate (sink-input.c:1463)
==3812==    by 0x22A6F515: sink_input_may_move_to_cb (module-loopback.c:899)
==3812==    by 0x4E791B7: pa_sink_input_finish_move (sink-input.c:1756)
==3812==    by 0x4E7BB55: pa_sink_move_all_finish (sink.c:916)
==3812==    by 0x19890F63: card_set_profile (module-alsa-card.c:259)
==3812==    by 0x4E5BA64: pa_card_set_profile (card.c:279)
==3812==    by 0x18C55246: command_set_card_profile (protocol-native.c:4782)
==3812==    by 0x5C3BF0C: pa_pdispatch_run (pdispatch.c:341)
==3812==    by 0x18C5DC7F: pstream_packet_callback (protocol-native.c:4896)
==3812==    by 0x5C3E7FA: do_read (pstream.c:880)
==3812==    by 0x5C40DDC: do_pstream_read_write (pstream.c:193)
==3812==    by 0x50EF1B3: dispatch_pollfds (mainloop.c:655)
==3812==    by 0x50EF1B3: pa_mainloop_dispatch (mainloop.c:898)
==3812==  Address 0x348 is not stack'd, malloc'd or (recently) free'd
==3812==
==3812==
==3812== Process terminating with default action of signal 11 (SIGSEGV)
==3812==  Access not within mapped region at address 0x348
==3812==    at 0x4E7588C: pa_sink_input_set_rate (sink-input.c:1463)
==3812==    by 0x22A6F515: sink_input_may_move_to_cb (module-loopback.c:899)
==3812==    by 0x4E791B7: pa_sink_input_finish_move (sink-input.c:1756)
==3812==    by 0x4E7BB55: pa_sink_move_all_finish (sink.c:916)
==3812==    by 0x19890F63: card_set_profile (module-alsa-card.c:259)
==3812==    by 0x4E5BA64: pa_card_set_profile (card.c:279)
==3812==    by 0x18C55246: command_set_card_profile (protocol-native.c:4782)
==3812==    by 0x5C3BF0C: pa_pdispatch_run (pdispatch.c:341)
==3812==    by 0x18C5DC7F: pstream_packet_callback (protocol-native.c:4896)
==3812==    by 0x5C3E7FA: do_read (pstream.c:880)
==3812==    by 0x5C40DDC: do_pstream_read_write (pstream.c:193)
==3812==    by 0x50EF1B3: dispatch_pollfds (mainloop.c:655)
==3812==    by 0x50EF1B3: pa_mainloop_dispatch (mainloop.c:898)
==3812==  If you believe this happened as a result of a stack
==3812==  overflow in your program's main thread (unlikely but
==3812==  possible), you can try to increase the size of the
==3812==  main thread stack using the --main-stacksize= flag.
==3812==  The main thread stack size used in this run was 8388608.


01.02.2015 03:43, Georg Chini wrote:
> This is the final version of my patch for module-loopback. It is on top of the
> patch I sent about an hour ago and contains a lot more changes than the previous
> versions:
>
> - Honor specified latency if possible, if not adjust to the lowest possible value
> - Smooth switching from fixed latency to dynamic latency source or sink and vice versa
> - good rate and latency stability, no rate oscillation
> - adjusts latency as good as your setup allows
> - fast regulation of latency offsets, adjusts 100 ms offset within 22 seconds (adjust
>    time=1) to 60 seconds (adjust_time=10)
> - usable latency range 4 - 30000 ms
> - Avoid rewinds and "cannot peek into queue" messages during startup and switching
> - works with rates between 200 and 190000 Hz
> - maximum latency offset after source/sink switch or at startup around is 200 ms
>
> I also introduced a new parameter, buffer_latency_msec which can be used together
> with latency_msec. If buffer_latency_msec is specified, the resulting latency
> will be latency_msec + buffer_latency_msec. Latency_msec then refers only to
> the source/sink latency while buffer_latency_msec specifies the buffer part.
> This can be used to save a lot of CPU at low latencies, running 10 ms latency
> with latency_msec=6 buffer_latency_msec=4 gives 8% CPU on my system compared to
> 12% when I only specify latency_msec=10.
> Additionally you can go beyond the safe-guard limits that are built in, you can
> access the range 1 - 3 ms or lower the buffer latency for fixed latency devices.
> Some of my USB devices run fine at a buffer latency of fragment size + 4 ms
> instead of the dfault fragment size + 20 ms.
>
> I tested it all with Intel HDA, USB and bluetooth sound devices. I would like to
> see some test results from other people.
>

-- 
Alexander E. Patrakov