The point of writing a macro embedded in a 'do { ... } while (0)'
loop (particularly if the macro has multiple statements or would
otherwise end with an 'if' statement) is so that the macro can be
used as a drop-in statement with the caller supplying the
trailing ';'. Although our coding style frowns on brace-less 'if':
if (cond)
statement;
else
something else;
that is the classic case where failure to use do/while(0) wrapping
would cause the 'else' to pair with any embedded 'if' in the macro
rather than the intended outer 'if'. But conversely, if the macro
includes an embedded ';', then the same brace-less coding style
would now have two statements, making the 'else' a syntax error
rather than pairing with the outer 'if'. Thus, even though our
coding style with required braces is not impacted, ending a macro
with ';' makes our code harder to port to projects that use
brace-less styles.
The change should have no semantic impact. I was not able to
fully compile-test all of the changes (as some of them are
examples of the ugly bit-rotting debug print statements that are
completely elided by default, and I didn't want to recompile
with the necessary -D witnesses - cleaning those up is left as a
bite-sized task for another day); I did, however, audit that for
all files touched, all callers of the changed macros DID supply
a trailing ';' at the callsite, and did not appear to be used
as part of a brace-less conditional.
Found mechanically via: $ git grep -B1 'while (0);' | grep -A1 \\\\
Signed-off-by: Eric Blake <eblake@redhat.com>
Acked-by: Cornelia Huck <cohuck@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Acked-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
Message-Id: <20171201232433.25193-7-eblake@redhat.com>
Reviewed-by: Juan Quintela <quintela@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Since pulseaudio 1.0 it's possible to set the individual stream volume
rather than setting the device volume. With this, setting hardware mixer
of a emulated sound card doesn't mess up the volume configuration of the
host.
A side effect is that this limits compatible pulseaudio version to 1.0
which was released on 2011-09-27.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Message-id: 78853815be2069971b89b3a2e3181837064dd8f3.1462962512.git.pkrempa@redhat.com
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Clean up includes so that osdep.h is included first and headers
which it implies are not included manually.
This commit was created with scripts/clean-includes.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Message-id: 1453138432-8324-1-git-send-email-peter.maydell@linaro.org
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
qpa_audio_init did not clean up resources properly if the initialization
failed. This hopefully fixes it.
Signed-off-by: Kővágó, Zoltán <DirtY.iCE.hu@gmail.com>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Currently the opaque pointer returned by audio_driver's init is only
exposed to the driver's fini, but not to audio_pcm_ops. This way if
someone wants to share a variable with the driver and the pcm, he must
use global variables. This patch fixes it by adding a third parameter to
audio_pcm_op's init_out and init_in.
Signed-off-by: Kővágó, Zoltán <DirtY.iCE.hu@gmail.com>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Unfortunately, pa_simple is a limited API which doesn't let us
retrieve the associated pa_stream. It is needed to control the volume
of the stream.
In v4:
- add missing braces
Signed-off-by: Marc-Andr? Lureau <marcandre.lureau@redhat.com>
Signed-off-by: malc <av1474@comtv.ru>
Request reasonable buffer sizes from pulseaudio. Without this
pa_simple_write() can block quite long and lead to dropouts,
especially with guests which use small audio ring buffers.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Signed-off-by: malc <av1474@comtv.ru>
Limit the size of data pieces processed by the pulseaudio worker
threads. Never ever process more than 1/4 of the buffer at once.
Background: The buffer area currently processed by the pulseaudio thread
is blocked, i.e. the main thread (or iothread) can't fill in more data
there. The buffer processing time is roughly real-time due to the
pa_simple_write() call blocking when the output queue to the pulse
server is full. Thus processing big chunks at once means blocking
a large part of the buffer for a long time. This brings high latency
and can lead to dropouts.
When processing the buffer in smaller chunks the rpos handling becomes a
problem though. The thread reads hw->rpos without knowing whenever
qpa_run_out has already seen the last (small) chunk processed and
updated rpos accordingly. There is no point in reading hw->rpos though,
pa->rpos can be used instead. We just need to take care to initialize
pa->rpos before kicking the thread.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Signed-off-by: malc <av1474@comtv.ru>
Refactor the volume mixing, so it can be reused for capturing devices.
Additionally, it removes superfluous multiplications with the nominal
volume within the hardware voice code path.
Signed-off-by: Michael Walle <michael@walle.cc>
Signed-off-by: malc <av1474@comtv.ru>
Fix a rpos coordination bug between qpa_run_out() and qpa_thread_out(),
which shows up as playback noises.
qpa_run_out()
qpa_thread_out loop N critical section 1
qpa_run_out() qpa_thread_out loop N doing pa_simple_write()
qpa_run_out() qpa_thread_out loop N doing pa_simple_write()
qpa_thread_out loop N critical section 2
qpa_thread_out loop N+1 critical section 1
qpa_run_out() qpa_thread_out loop N+1 doing pa_simple_write()
In the above scheme, "qpa_thread_out loop N+1 critical section 1" will
get the same rpos as the one used by "qpa_thread_out loop N critical
section 1". So it will be reading dead samples from the old rpos.
The rpos can only be updated back to qpa_thread_out when there is a
qpa_run_out() run between two qpa_thread_out loops.
normal sequence:
qpa_thread_out:
hw->rpos (X0) => local rpos => pa->rpos (X1)
qpa_run_out:
pa->rpos (X1) => hw->rpos (X1)
qpa_thread_out:
hw->rpos (X1) => local rpos => pa->rpos (X2)
buggy sequence:
qpa_thread_out:
hw->rpos (X0) => local rpos => pa->rpos (X1)
qpa_thread_out:
hw->rpos (X0) => local rpos => pa->rpos (X1')
Obviously qpa_run_out() shall be called at least once between any two
qpa_thread_out loops (after pa->rpos is set), in order for the new
qpa_thread_out loop to see the updated rpos.
Setting pa->live to 0 does the trick. The next loop will have to wait
for one qpa_run_out() invocation in order to get a non-zero pa->live
and proceed.
Signed-off-by: malc <av1474@comtv.ru>
Signed-off-by: Wu Fengguang <fengguang.wu@intel.com>
We're seeing various issues with the SDL audio backend and want to
switch to the pulseaudio backend. See e.g.
https://bugzilla.redhat.com/495964https://bugzilla.redhat.com/519540https://bugzilla.redhat.com/496627
The pulseaudio backend seems to work well, so we should allow it to be
selected as the default.
Signed-off-by: Mark McLoughlin <markmc@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: malc <av1474@comtv.ru>
pcm_ops.run_out now takes number of live samples (which will be always
greater than zero) as a second argument, every driver was calling
audio_pcm_hw_get_live_out anyway with exception of fmod which used
audio_pcm_hw_get_live_out2 for no good reason.
Signed-off-by: malc <av1474@comtv.ru>
