The same logic is applied to the sample rate adjustments in module-rtp-recv,
module-loopback and module-combine:
- Each time an adjustment is made, the new rate can differ at most 2‰ from the
old rate. Such a step is equal to 3.5 cents (a cent is 1/100th of a
semitone) and as 5 cents is generally considered the smallest observable
difference in pitch, this results in inaudible adjustments.
- The sample rate of the stream can only differ from the rate of the
corresponding sink by 25%. As these adjustments are meant to account for
very small clock drifts, any large deviation from the base rate suggests
something is seriously wrong.
- If the calculated rate is within 20Hz of the base rate, set it to the base
rate. This saves CPU because no resampling is necessary.
Move the mainloop to monotonic based time events.
Introduces 4 helper functions:
pa_{context,core}_rttime_{new,restart}(), that fill correctly a
timeval with the rtclock flag set if the mainloop supports it.
Both mainloop-test and mainloop-test-glib works with rt and timeval
based time events. PulseAudio and clients should be fully functional.
This patch has received several iterations, and this one as been
largely untested.
Signed-off-by: Marc-André Lureau <marca-andre.lureau@nokia.com>
The primary reason for this change is to allow time graphs that do not
go through the origin and hence smoothing starting from the origin is
not desired. This change will allow passing time data into the smoother
while paused and then abruptly use that data without smoothing using the
'quick fixup' flag when resuming.
Primary use case is allowing recording time graphs where the data
recorded originates from a time before the stream was created. The
resulting graft will be shifted and should not be smoothened to go
through the origin.
Erich Boleyn <erich@uruk.org> wrote:
> Using RTP for multi-room music streaming, updated to Pulse 0.9.14 from
> 0.9.9, RTP reception new crashes with a segfault on all machines at
> the first "Updating sample rate" log message.
>
> Source of the segfault appears to be null pointer for
> "impl_update_rates" function in resampler routine, perhaps
> uninitialized resamplers in general?
A fresh look after work made the resampler initialization code pop out.
The problem is in the sink connection being made from
"module-rtp-recv.c", the "PA_SINK_INPUT_VARIABLE_RATE" flag should be
passed into "pa_sink_input_new", but is not there. Made the change and
tested it, fixes the problem. Checked and head-of- tree off of the
pulseaudio.org source browsing link does not have this fix either.
One-liner patch attached.
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
* modify pa_sink_input_new() to take initial volume settings as argument
* call pa_sink_input_set_volume() when changing stream volume in protocol-esound.c to make sure that subscribe events are issued properly
git-svn-id: file:///home/lennart/svn/public/pulseaudio/trunk@858 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
