...over "Digital Input Source:Analog Input". It makes life a little
easier for users of Dell xps m1330.
Just an old Ubuntu delta I never upstreamed until now.
The patch was originally written by Daniel T Chen <crimsun@ubuntu.com>.
BugLink: https://bugs.launchpad.net/bugs/453966
Signed-off-by: David Henningsson <david.henningsson@canonical.com>
If the mainloop is just about to enter polling, but m->state
is not POLLING yet when some other thread calls
pa_mainloop_wakeup(), the mainloop will not be woken up.
It's safe to write to the wakeup pipe at any time, so let's
just remove the check.
Based on feedback in the bug below (comments 128, 129, 131).
BugLink: https://bugs.launchpad.net/bugs/946232
Signed-off-by: David Henningsson <david.henningsson@canonical.com>
Previously, if there was a hole in a recording stream,
pa_stream_peek() would crash. Holes could be handled silently inside
pa_stream_peek() by generating silence (wouldn't work for compressed
streams, though) or by skipping any holes. However, I think it's
better to let the caller decide how the holes should be handled, so
in case of holes, pa_stream_peek() will return NULL data pointer and
the length of the hole in the nbytes argument.
This change is technically an interface break, because previously the
documentation didn't mention the possibility of holes that need
special handling. However, since holes caused crashing anyway in the
past, it's not a regression if applications keep misbehaving due to
not handing holes properly.
Some words about when holes can appear in recording streams: I think
it would be reasonable behavior if overruns due to the application
reading data too slowly would cause holes. Currently that's not the
case - overruns will just cause audio to be skipped. But the point is
that this might change some day. I'm not sure how holes can occur
with the current code, but as the linked bug shows, they can happen.
It's most likely due to recording from a monitor source where the
thing being monitored has holes in its playback stream.
BugLink: http://bugs.launchpad.net/bugs/1058200
Refactor code to fetch avail, delay and timestamp values
in a single call to snd_pcm_status().
The information reported is exactly the same as before,
however it is extracted in a more atomic manner to
improve timer-based scheduling.
Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
This reverts commit 1569601864.
Rethinking this, it makes more sense to not add this to the check
framework. This is mostly useful for exposing ALSA driver issues, and
it's handy to be able to build this as a standalone executable.
To reproduce, add resampler-method = ffmpeg in daemon.conf
then start PA, and load module-loopback
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0xb2f1db40 (LWP 23047)]
0x00000000 in ?? ()
(gdb) bt
0 0x00000000 in ?? ()
1 0xb7c463cb in pa_resampler_set_input_rate (r=0x80e9438, rate=44011) at pulsecore/resampler.c:365
2 0xb7c6321d in pa_sink_input_process_msg (o=0x80e87a0, code=3, userdata=0xabeb, offset=0, chunk=0x0)
at pulsecore/sink-input.c:1833
3 0xb7e9840b in sink_input_process_msg_cb (obj=0x80e87a0, code=3, data=0xabeb, offset=0, chunk=0x0)
at modules/module-loopback.c:538
4 0xb7c2709b in pa_asyncmsgq_dispatch (object=0x80e87a0, code=3, userdata=0xabeb, offset=0, memchunk=0xb2f1d17c)
at pulsecore/asyncmsgq.c:322
5 0xb7c4c6e3 in asyncmsgq_read_work (i=0x80dd580) at pulsecore/rtpoll.c:564
6 0xb7c4b34a in pa_rtpoll_run (p=0x80fb7e0, wait_op=true) at pulsecore/rtpoll.c:238
7 0xb7dd90af in thread_func (userdata=0x80afe88) at modules/alsa/alsa-sink.c:1785
8 0xb7bf3291 in internal_thread_func (userdata=0x8095d08) at pulsecore/thread-posix.c:83
9 0xb7ab9d4c in start_thread (arg=0xb2f1db40) at pthread_create.c:308
10 0xb79f3ace in clone () at ../sysdeps/unix/sysv/linux/i386/clone.S:130
As a packager, I want to be able to do "git format-patch
v3.0..origin/master" and I want the generated patches to apply cleanly
against the 3.0 tarball. The patches don't currently apply cleanly if
there are any changes to the .gitignore files, because the .gitignore
files are not shipped in the tarball. This patch fixes that problem.
A rewind may erase data that sink_input counted in playing_for or
underrun_for earlier. Add code adjusting those values after a rewind.
One visible symptom of this bug was problems recovering from an
underrun. When a client calls pa_stream_write() with a large block of
memory, the function can split that into smaller pieces before sending
it to the server. When receiving new data for a stream that had
silence queued due to underrun, the server would do a rewind to
replace the queued-but-not-played silence with the new data. Because
of the bug, this rewind itself would not change underrun_for. It's
possible for multiple rewinds to be done without filling the sink
buffer in between (which is what would eventually reset underrun_for).
In this case, the server rapidly processing the split packets would
rewind the stream for _each_ of them (as underrun_for would stay set),
erasing valid audio as a result.
As Peter Meerwald <p.meerwald@bct-electronic.com> discovered, our ARM
svolume code performance is quite terrible when the incoming samples are
not word-aligned. This can very easily be the case, since the
architecture only requires that the samples be 16-bit aligned, and we
might end up running the innermost loop after processing modulo-4
samples. The performance degradation was ~50x on a Cortex A9
(Pandaboard).
This reworks the svolume logic to first consume enough samples to make
sure the rest is word aligned, and reordering the processing to work
with 4 samples at a time first, and then finally deal with the
remainder.
With this, performance is comparable for arbitrary alignments (~3x
faster than the C code).
The callback relies on the sample spec being finalized, which is not
true with the NEW hook.
In case you're wondering about the "hook EARLY - 1, to match before
stream-restore" comment that was not changed even though the code that
the comment concerned was changed: the comment was apparently written
at a time when module-stream-restore used the NEW hook too, and later
stream-restore has been changed to use the FIXATE hook. So, the
comment was wrong/nonsensical before this patch. Since these two
modules now use the same hook again, the comment makes sense again.
BugLink: https://bugs.freedesktop.org/show_bug.cgi?id=55135
Previously thread_func() used PA_SINK_IS_OPENED() to check whether
some data should be rendered. process_render_null() used a different
check: it would return immediately if the sink was not in the RUNNING
state. This caused a busy loop when the sink was in the IDLE state,
because process_render_null() didn't update the timestamp, and
thread_func() still kept the timer active using the old timestamp.
pa_rtpoll_run() would return immediately because of the old timestamp.
This is fixed by using the same check in both thread_func() and
process_render_null(). Since the checks are the same, it's actually
redundant to have the check in process_render_null(), so it is now an
assertion.
BugLink: https://bugs.freedesktop.org/show_bug.cgi?id=54779
The sink has different frame size than the sink input, so
the max_request and max_rewind values of the sink input need
to be converted when setting the sink max_request and
max_rewind values.
The conversion is already done correctly in
sink_input_update_max_request_cb() and
sink_input_update_max_rewind_cb().
Once the sink input has been routed in pa_sink_input_new(),
the sample spec and channel map have already become fixed.
The sink input and source output must use the same stream
format, because the data is copied as-is.
When module-loopback is loaded without arguments, the ss and
map variables are initialized with dummy values. This caused
a problem, because also pa_memblockq_new() was called with
the dummy values, making it work incorrectly. The base was
set to 1 instead of the real frame size, which in turn
caused alignment related crashes.
This fixes at least one crash that has been observed. The
multiplication in trivial_resample() overflowed when
resampling from 96 kHz to 48 kHz, causing an assertion
error:
Assertion 'o_index * fz < pa_memblock_get_length(output->memblock)' failed at pulsecore/resampler.c:1521, function trivial_resample(). Aborting.
Without the assertion, the memcpy() after the assertion
would have overwritten some random heap memory.
When compiling without HAVE_SYMLINK the runtime dir is a real directory,
which is attempted to be created. In the case it already exists we shouldn't
error out. The HAVE_SYMLINK-enabled code already does this.
Currently, Windows versions of pacat and friends fail because the current
poll emulation is not sufficient (it only works for socket fds).
Luckily Gnulib has a much better emulation that seems to work good enough.
The implementation has been largely copied (except a few bug fix
regarding timeout handling, to be pushed upstream) and works on pipes
and files as well. The copy has been obtained through their gnulib-tool utility,
which gives a LGPLv2.1+ licensed file.
This fixes the "Assertion (!e->dead) failed" error coming and lets pacat
and friends stream happily to/from a server (I didn't actually test parec).
With some optimised sconv implementations (read NEON), rounding
inaccuracy might lead to a difference of 1 with the reference
implementation. The inaccuracy is worth the performance gain.
Also increases floating-point accuracy while printing errors to make
errors easier to analyse.
Rounding with 0.5 causes us to always round up for any value of the form
x.5. IEEE754 specifies round-to-nearest-even as the behaviour in this
case. This might not always be possible with NEON code, but this change
gets us much closer to it.
final:
* includes some minor style fixes and build-time changes to allow
building a single binary for neon and non-neon systems
v4:
* fix for sample length < 4
v3:
* convert from intrinsics to inline assembly
v2:
* load and store data with vld1/vld1q and vst1/vst1q, resp., to work
around alignment issues of compiler-generated vldmia instruction
* remove redundant check for NEON flags
Ubuntu/Linaro gcc 4.6.3
arm-linux-gnueabi-gcc -O2 -mcpu=cortex-a8 -mfloat-abi=softfp -mfpu=neon
runtime on beagle-xm:
D: [pulseaudio] sconv_neon.c: checking NEON sconv_s16le_from_float
I: [pulseaudio] sconv_neon.c: NEON: 3754 usec.
I: [pulseaudio] sconv_neon.c: ref: 58594 usec.
D: [pulseaudio] sconv_neon.c: checking NEON sconv_s16le_to_float
I: [pulseaudio] sconv_neon.c: NEON: 1831 usec.
I: [pulseaudio] sconv_neon.c: ref: 10528 usec.
I: [pulseaudio] sconv_neon.c: Initialising ARM NEON optimized conversions.
conversion may be off by one for some samples due to rounding issues
