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
_______________________________________________
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
