On Wed, 29 Mar 2023, Volker Rümelin wrote:
Am 29.03.23 um 21:20 schrieb BALATON Zoltan:
On Tue, 28 Mar 2023, Volker Rümelin wrote:
it seems your Mac uses a 48kHz sample rate, although QEMU requested a
44.1kHz sample rate. Could you add -audiodev
coreaudio,id=audio0,out.frequency=48000 to your command line and test if
the playback speed and pitch is now correct?
I guess you could also set the sampling rate in the guest to match the host
but if that results it to do resampling then it may use more CPU that way.
With default settings QEMU resamples the selected guest rate to
out.frequency.
The default for out.frequency is 44100.
I think ALSA and Pulseaudio may also default to 48kHz. I remember
configuring ALSA to 44.1 kHz on my machine to avoid resampling in the more
common case of playing music. So is this a general problem or something
with the coreadio backend? Should this somehow detect the host sampling
rate and do something about it?
Querying the host sample rate and using the host sample rate instead of
out.frequency seems easy. It gets difficult when someone changes the host
sample rate when QEMU is running. Current QEMU code can't change the sample
rate for an established audio stream.
So what happens now if somebody changes that while QEMU is running? If it
already does not work then using host rate would also not make it worse,
if it resamples now why wouldn't it do the same when using host rate
instead of constant 44.1kHz? I think this could only improve things even
if it does not completely fix every case, also considering that changing
host rate should be a rare event.
I think the Google Android emulator
fork of QEMU uses the Core Audio API to resample the audio stream in this
case.
So there are even patches that could be upstreamed by somebody? Could this
be a bite sized task or sponsored project?
Regards,
BALATON Zoltan