| b9896dc5 | 20-Sep-2020 |
Volker Rümelin <vr_qemu@t-online.de> |
audio: align audio_generic_read with audio_pcm_hw_run_in
The function audio_generic_read should work exactly like
audio_pcm_hw_run_in. It's a very similar function working
on a different buffer.
Si
audio: align audio_generic_read with audio_pcm_hw_run_in
The function audio_generic_read should work exactly like
audio_pcm_hw_run_in. It's a very similar function working
on a different buffer.
Signed-off-by: Volker Rümelin <vr_qemu@t-online.de>
Message-id: 20200920171729.15861-4-vr_qemu@t-online.de
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
show more ...
|
| aec6d0dc | 20-Sep-2020 |
Volker Rümelin <vr_qemu@t-online.de> |
audio/spiceaudio: always rate limit playback stream
The playback rate with the spiceaudio backend is currently too
fast if there's no spice client connected or the spice client
can't play audio. Rat
audio/spiceaudio: always rate limit playback stream
The playback rate with the spiceaudio backend is currently too
fast if there's no spice client connected or the spice client
can't play audio. Rate limit the audio playback stream in all
cases. To calculate the rate correctly the limiter has to know
the maximum buffer size.
Fixes: 8c198ff065 ("spiceaudio: port to the new audio backend api")
Signed-off-by: Volker Rümelin <vr_qemu@t-online.de>
Message-id: 20200920171729.15861-3-vr_qemu@t-online.de
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
show more ...
|
| 4c3356f9 | 20-Sep-2020 |
Volker Rümelin <vr_qemu@t-online.de> |
audio/audio: fix video playback slowdown with spiceaudio
This patch allows the audio backends get_buffer_out() functions
to drop audio data and mitigates a bug reported on the qemu-devel
mailing lis
audio/audio: fix video playback slowdown with spiceaudio
This patch allows the audio backends get_buffer_out() functions
to drop audio data and mitigates a bug reported on the qemu-devel
mailing list.
https://lists.nongnu.org/archive/html/qemu-devel/2020-09/msg03832.html
The new rules for the variables buf and size returned by
get_buffer_out() are:
size == 0: Downstream playback buffer is full. Retry later.
size > 0, buf != NULL: Copy size bytes to buf for playback.
size > 0, buf == NULL: Drop size bytes.
The audio playback rate with spiceaudio for the no audio case is
too fast, but that's what we had before commit fb35c2cec5
"audio/dsound: fix invalid parameters error". The complete fix
comes with the next patch.
Reported-by: Qi Zhou <atmgnd@outlook.com>
Signed-off-by: Volker Rümelin <vr_qemu@t-online.de>
Message-id: 20200920171729.15861-2-vr_qemu@t-online.de
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
show more ...
|
| bc81e6e5 | 12-Jun-2020 |
Geoffrey McRae <geoff@hostfission.com> |
audio/jack: simplify the re-init code path
Instead of checking for the audodev state in each code path, centralize
the check into the initialize function itself to make it safe to call it
at any tim
audio/jack: simplify the re-init code path
Instead of checking for the audodev state in each code path, centralize
the check into the initialize function itself to make it safe to call it
at any time.
Signed-off-by: Geoffrey McRae <geoff@hostfission.com>
Message-id: 20200613040518.38172-7-geoff@hostfission.com
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
show more ...
|
| 81e0efb2 | 12-Jun-2020 |
Geoffrey McRae <geoff@hostfission.com> |
audio/jack: honour the enable state of the audio device
When the guest closes the audio device we must start dropping input
samples from JACK and zeroing the output buffer samples. Failure to do
so
audio/jack: honour the enable state of the audio device
When the guest closes the audio device we must start dropping input
samples from JACK and zeroing the output buffer samples. Failure to do
so causes sound artifacts during operations such as guest OS reboot, and
causes a hang of the input pipeline breaking it until QEMU is restated.
Closing and reconnecting to JACK was tested during these enable/disable
calls which works well for Linux guests, however Windows re-opens the
audio hardware repeatedly even when doing simple tasks like playing a
system sounds. As such it was decided it is better to feed silence to
JACK while the device is disabled.
Signed-off-by: Geoffrey McRae <geoff@hostfission.com>
Message-id: 20200613040518.38172-6-geoff@hostfission.com
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
show more ...
|
| de826408 | 12-Jun-2020 |
Geoffrey McRae <geoff@hostfission.com> |
audio/jack: do not remove ports when finishing
This fixes a hang when there is a communications issue with the JACK
server. Simply closing the connection is enough to completely clean up
and as such
audio/jack: do not remove ports when finishing
This fixes a hang when there is a communications issue with the JACK
server. Simply closing the connection is enough to completely clean up
and as such we do not need to remove the ports first. As JACK uses a
socket based protocol that relies on the `select` call, if there is a
communication breakdown with the server the client library waits
forever for a response to the unregister request.
Signed-off-by: Geoffrey McRae <geoff@hostfission.com>
Message-id: 20200613040518.38172-5-geoff@hostfission.com
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
show more ...
|
| f8f0f218 | 12-Jun-2020 |
Geoffrey McRae <geoff@hostfission.com> |
audio/jack: remove invalid set of input support bool
Initial code for JACK did not support audio input and as such this
boolean was set to let QEMU know, however JACK ended up including input
suppor
audio/jack: remove invalid set of input support bool
Initial code for JACK did not support audio input and as such this
boolean was set to let QEMU know, however JACK ended up including input
support making this invalid. Further investigation shows it was invalid
to set it in the first instance anyway due to a failure on my part
understand properly what this was for when the audodev was initially
developed.
Signed-off-by: Geoffrey McRae <geoff@hostfission.com>
Message-id: 20200613040518.38172-4-geoff@hostfission.com
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
show more ...
|
| 57a878ed | 05-May-2020 |
Philippe Mathieu-Daudé <f4bug@amsat.org> |
audio: Let capture_callback handler use const buffer argument
The buffer is the captured input to pass to backends.
As we should not modify it, mark the argument const.
Signed-off-by: Philippe Math
audio: Let capture_callback handler use const buffer argument
The buffer is the captured input to pass to backends.
As we should not modify it, mark the argument const.
Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Message-Id: <20200505132603.8575-3-f4bug@amsat.org>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
show more ...
|
| e709d2ac | 05-May-2020 |
Philippe Mathieu-Daudé <f4bug@amsat.org> |
audio: Let audio_sample_to_uint64() use const samples argument
The samples are the input to convert to u64. As we should
not modify them, mark the argument const.
Signed-off-by: Philippe Mathieu-Da
audio: Let audio_sample_to_uint64() use const samples argument
The samples are the input to convert to u64. As we should
not modify them, mark the argument const.
Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Message-Id: <20200505132603.8575-2-f4bug@amsat.org>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
show more ...
|
| cbaf25d1 | 21-May-2020 |
Bruce Rogers <brogers@suse.com> |
audio: fix wavcapture segfault
Commit 571a8c522e caused the HMP wavcapture command to segfault when
processing audio data in audio_pcm_sw_write(), where a NULL
sw->hw->pcm_ops is dereferenced. This
audio: fix wavcapture segfault
Commit 571a8c522e caused the HMP wavcapture command to segfault when
processing audio data in audio_pcm_sw_write(), where a NULL
sw->hw->pcm_ops is dereferenced. This fix checks that the pointer is
valid before dereferincing it. A similar fix is also made in the
parallel function audio_pcm_sw_read().
Fixes: 571a8c522e (audio: split ctl_* functions into enable_* and
volume_*)
Signed-off-by: Bruce Rogers <brogers@suse.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Message-id: 20200521172931.121903-1-brogers@suse.com
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
show more ...
|
| 9c61fcc8 | 23-May-2020 |
Volker Rümelin <vr_qemu@t-online.de> |
audio/mixeng: fix clang 10+ warning
The code in CONV_NATURAL_FLOAT() and CLIP_NATURAL_FLOAT()
seems to use the constant 2^31-0.5 to convert float to integer
and back. But the float type lacks the re
audio/mixeng: fix clang 10+ warning
The code in CONV_NATURAL_FLOAT() and CLIP_NATURAL_FLOAT()
seems to use the constant 2^31-0.5 to convert float to integer
and back. But the float type lacks the required precision and
the constant used for the conversion is 2^31. This is equiva-
lent to a [-1.f, 1.f] <-> [INT32_MIN, INT32_MAX + 1] mapping.
This patch explicitly writes down the used constant. The
compiler generated code doesn't change.
The constant 2^31 has an exact float representation and the
clang 10 compiler stops complaining about an implicit int to
float conversion with a changed value.
A few notes:
- The conversion of 1.f to INT32_MAX + 1 doesn't overflow. The
type of the destination variable is int64_t.
- At a later stage one of the clip_* functions in
audio/mixeng_template.h limits INT32_MAX + 1 to the integer
range.
- The clip_natural_float_* functions in audio/mixeng.c convert
INT32_MAX and INT32_MAX + 1 to 1.f.
Buglink: https://bugs.launchpad.net/bugs/1878627
Signed-off-by: Volker Rümelin <vr_qemu@t-online.de>
Message-id: 20200523201712.23908-1-vr_qemu@t-online.de
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
show more ...
|
| 8d1439b6 | 05-Apr-2020 |
Volker Rümelin <vr_qemu@t-online.de> |
dsoundaudio: dsound_get_buffer_in should honor *size
This patch prevents an underflow of variable samples in function
audio_pcm_hw_run_in(). See commit 599eac4e5a "audio:
audio_generic_get_buffer_in
dsoundaudio: dsound_get_buffer_in should honor *size
This patch prevents an underflow of variable samples in function
audio_pcm_hw_run_in(). See commit 599eac4e5a "audio:
audio_generic_get_buffer_in should honor *size". This time the
while loop in audio_pcm_hw_run_in() will terminate nevertheless,
because it seems the recording stream in Windows is always rate
limited.
Signed-off-by: Volker Rümelin <vr_qemu@t-online.de>
Message-id: 20200405075017.9901-3-vr_qemu@t-online.de
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
show more ...
|
| 17470298 | 05-Apr-2020 |
Volker Rümelin <vr_qemu@t-online.de> |
dsoundaudio: fix "Could not lock capture buffer" warning
IDirectSoundCaptureBuffer_Lock() fails on Windows when called
with len = 0. Return early from dsound_get_buffer_in() in this
case.
To reprod
dsoundaudio: fix "Could not lock capture buffer" warning
IDirectSoundCaptureBuffer_Lock() fails on Windows when called
with len = 0. Return early from dsound_get_buffer_in() in this
case.
To reproduce the warning start a linux guest. In the guest
start Audacity and you will see a lot of "Could not lock
capture buffer" warnings.
Signed-off-by: Volker Rümelin <vr_qemu@t-online.de>
Message-id: 20200405075017.9901-2-vr_qemu@t-online.de
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
show more ...
|
| 194bdf50 | 08-Mar-2020 |
Volker Rümelin <vr_qemu@t-online.de> |
audio: fix saturation nonlinearity in clip_* functions
The current positive limit for the saturation nonlinearity is
only correct if the type of the result has 8 bits or less.
Signed-off-by: Volker
audio: fix saturation nonlinearity in clip_* functions
The current positive limit for the saturation nonlinearity is
only correct if the type of the result has 8 bits or less.
Signed-off-by: Volker Rümelin <vr_qemu@t-online.de>
Message-id: 20200308193321.20668-5-vr_qemu@t-online.de
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
show more ...
|