pa_memblockq_push() expects all memchunks to be aligned to PCM frame
boundaries, and that means both the index and length fields of
pa_memchunk. pa_rtp_recv(), however, used a memblock for storing both
the RTP packet metadata and the actual audio data. The metadata was
"removed" from the audio data by setting the memchunk index
appropriately, so the metadata stayed in the memblock, but it was not
played back. The metadata length is not necessarily divisible by the PCM
frame size, which caused pa_memblock_push() to crash in an assertion
with some sample specs, because the memchunk index was not properly
aligned. In my tests the metadata length was 12, so it was compatible
with many configurations, but eight-channel audio didn't work.
This patch adds a separate buffer for receiving the RTP packets. As a
result, an extra memcpy is needed for moving the audio data from the
receive buffer to the memblock buffer.
BugLink: https://bugs.freedesktop.org/show_bug.cgi?id=96612
FSF addresses used in PA sources are no longer valid and rpmlint
generates numerous warnings during packaging because of this.
This patch changes all FSF addresses to FSF web page according to
the GPL how-to: https://www.gnu.org/licenses/gpl-howto.en.html
Done automatically by sed-ing through sources.
On FIONREAD returning 0 bytes, we cannot return success, as the caller
(rtpoll_work_cb in module-rtp-recv.c) would then try to
pa_memblock_unref(chunk.memblock) and, because memblock is NULL, trigger
an assertion.
Also we have to read out the possible empty packet from the socket, so
that the kernel doesn't tell us again and again about it.
Signed-off-by: Alexander E. Patrakov <patrakov@gmail.com>
The syntactically correct error meant that the timestamp was always
marked as found and only the first header was checked.
In the case where the timestamp was the first header, things
would have worked as expected.
Thanks to pino for reporting via bug refs #818
pa_memblock is now an opaque structure. Access to its fields is now done
through various accessor functions in a thread-safe manner.
pa_memblock_acquire() and pa_memblock_release() are now used to access the
attached audio data. Why? To allow safe manipulation of the memory pointer
maintained by the memory block. Internally _acquire() and _release() maintain a
reference counter. Please do not confuse this reference counter whith the one
maintained by pa_memblock_ref()/_unref()!
As a side effect this patch removes all direct usages of AO_t and replaces it
with pa_atomic_xxx based code.
This stuff needs some serious testing love. Especially if threads are actively
used.
git-svn-id: file:///home/lennart/svn/public/pulseaudio/trunk@1404 fefdeb5f-60dc-0310-8127-8f9354f1896f
pa_logXXX(__FILE__":
and replace them by
pa_logXXX("
git-svn-id: file:///home/lennart/svn/public/pulseaudio/trunk@1272 fefdeb5f-60dc-0310-8127-8f9354f1896f
is to allocate all audio memory blocks from a per-process memory pool which is
available as read-only SHM segment to other local processes. Then, instead of
writing the actual audio data to the socket just write references to this
shared memory pool.
To work optimally all memory blocks should now be of type PA_MEMBLOCK_POOL or
PA_MEMBLOCK_POOL_EXTERNAL. The function pa_memblock_new() now generates memory
blocks of this type by default.
git-svn-id: file:///home/lennart/svn/public/pulseaudio/trunk@1266 fefdeb5f-60dc-0310-8127-8f9354f1896f
* fix building of padsp
* remove a warning when compiling padsp.c
git-svn-id: file:///home/lennart/svn/public/pulseaudio/trunk@972 fefdeb5f-60dc-0310-8127-8f9354f1896f
* use server cookie as RTP SSRC
* enable SVN keywords
* add new option "loop" for RTP sender module
git-svn-id: file:///home/lennart/svn/public/pulseaudio/trunk@716 fefdeb5f-60dc-0310-8127-8f9354f1896f