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>
By moving the definition of GCC_ATTR and GCC_FMT_ATTR
from audio_int.h to qemu-common.h these macros are
now generally available for further patches which add
the gcc format attribute.
Newer gcc versions support format gnu_printf which is
better suited for use in QEMU than format printf
(QEMU always uses standard format strings (even with mingw32)).
V2: Use correct operator '==' (instead of '=')
Cc: Blue Swirl <blauwirbel@gmail.com>
Signed-off-by: Stefan Weil <weil@mail.berlios.de>
Signed-off-by: Blue Swirl <blauwirbel@gmail.com>
When available, we'd like to be able to access the DeviceState
when registering a savevm. For buses with a get_dev_path()
function, this will allow us to create more unique savevm
id strings.
Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
Remove unused 'shift' variable spotted by clang.
Also clean up aud_to_sdlfmt which used to get the value
of shift.
Signed-off-by: Serge Ziryukin <ftrvxmtrx@gmail.com>
Signed-off-by: malc <av1474@comtv.ru>
Commits 376253ec..731b0364 introduced global variable cur_mon, which
points to the "default monitor" (if any), except during execution of
monitor_read() or monitor_control_read() it points to the monitor from
which we're reading instead (the "current monitor"). Monitor command
handlers run within monitor_read() or monitor_control_read().
Default monitor and current monitor are really separate things, and
squashing them together is confusing and error-prone.
For instance, usb_host_scan() can run both in "info usbhost" and
periodically via usb_host_auto_check(). It prints to cur_mon, which
is what we want in the former case: the monitor executing "info
usbhost". But since that's the default monitor in the latter case, it
periodically spams the default monitor there.
A few places use cur_mon to log stuff to the default monitor. If we
ever log something while cur_mon points to current monitor instead of
default monitor, the log temporarily "jumps" to another monitor.
Whether that can or cannot happen isn't always obvious.
Maybe logging to the default monitor (which may not even exist) is a
bad idea, and we should log to stderr or a logfile instead. But
that's outside the scope of this commit.
Change cur_mon to point to the current monitor. Create new
default_mon to point to the default monitor. Update users of cur_mon
accordingly.
This fixes the periodical spamming of the default monitor by
usb_host_scan(). It also stops "log jumping", should that problem
exist.
This reverts commit 4839abe78f.
The commit was badly broken, Gentoo has sdl as the default driver,
consequently 5 gentoo users have hit the breakage and were kind enough
to report, so thank you:
Claes Gyllenswrd
vekin
Chris
But above all thanks to Toralf Foerster who actually provied enough
information to pinpoint the breakage to sdlaudio.
http://bugs.gentoo.org/show_bug.cgi?id=294269
Turns out on those versions of FreeBSD (>= 7.x) that know OSS_GETVERSION
the ioctl doesn't actually work yet (except in the Linuxolator), so if
building on FreeBSD assume the sound drivers are new enough if the ioctl
returns the errno it does currently on FreeBSD.
(Rev 2 after private discussion with malc.)
Signed-off-by: Juergen Lock <nox@jelal.kn-bremen.de>
Signed-off-by: malc <av1474@comtv.ru>
Previous patch introduced subtle regression, in cases when
OSS_GETVERSION fails the code wasn't falling back to
SNDCTL_DSP_SETFRAGMENT.
Signed-off-by: malc <av1474@comtv.ru>
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>
Additional argument (whether to try poll mode) is only passed with
VOICE_ENABLE command.
Thanks to Markus Armbruster for noticing the potential breakage.
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>
