Am 12.03.23 um 14:23 schrieb BALATON Zoltan:
On Sun, 12 Mar 2023, Volker Rümelin wrote:
Am 11.03.23 um 23:54 schrieb BALATON Zoltan:
Hello,
I've noticed before that since commit a806f95904cdb audio plays
slower (like half speed) under AmigaOS on sam460ex with ES1370 but I
did not have any other guests to reproduce it and verify this with
so I did not report that yet. Now that we can also test with
pegasos2 and via-ac97 it does not play slower on that machine
neither with ES1370 not via-ac97 but still can reproduce it with
sam460ex.
But on another host it seems to play faster with pegasos2. Here is a
video taken by Rene demonstrating the problem:
https://youtu.be/Rg5buzDqGuk So there seems to be a problem with
playback speed here but I'm not sure if this is related to AmigaOS
or something else.
At least we have some issue with AmigaOS on sam460ex and ES1370
playing too slow since commit a806f95904cdb on Linux with alsa
backend and may also have an issue with sound being too fast on
pegasos2 with coreaudio. However Rene said that recording it with a
screen recorder did not show the problem, only when playing it
normally, that's why the video is taken with a camera. I can't
understand how that's possible but maybe you have some idea to at
least how to test this further to find out more what's happening
here or if you can see anything that can cause playback speed issues
with these machines.
So far I've reproduced obviously slow speed with AmigaOS on sam460ex
with ES1370 on Linux with alsa. The MorphOS and AmigaOS on pegasos2
with via-ac97 or ES1370 (latter only works with AmigaOS) seems to be
OK to me on my machine but is playing too fast in Rene's video.
Could this be related to some differentce in host's sampling rate or
some other settings somewhere? I have defaults.pcm.dmix.rate 44100
in /etc/asound.conf while Rene is using whatever macOS does with
coreaudio.
Any ideas what to check further?
Hi,
perhaps this issue is similar to the Linux guest driver issue with an
AC97 device. The Linux driver tries to measure the AC97 clock
frequency. It starts playback with a certain amount of audio frames
and measures the time needed for playback. Since QEMU is not a cycle
exact simulation the result is always wrong. Before my latency
reducing patches the result was always way off and the Linux driver
rejected the measurement and used a clock frequency of 48000Hz. Now
the driver sometimes believes the measurement is correct and adjusts
the clock frequency.
I don't think that's the case with the AmigaOS driver. I don't know
for sure what exactly does that driver do but it is probably similiar
to the AROS driver which is here (the via-ac97 is one level up from
that):
https://github.com/aros-development-team/AROS/tree/master/workbench/devs/AHI/Drivers/SB128
and I don's see anything like that in it. AROS doesn't run on pegasos2
yet so I can't test with that. It should work with sam460ex which I've
tried but the SB128 driver used for ES1370 seems to have endianness
problems and only works on pc machine, not on big-endian PPC machines
(a lot of AROS network drivers have the same problem, these seem to be
mostly tested on PC only). On sam460ex it detects the card but doesn't
make sound but works with on the pc machine.
But the question remains how commit a806f95904cdb could change
playback speed as the problem with sam460ex is bisectable to that commit.
To change the playback speed you have to remove or add audio frames from
or to the audio stream. At the moment I don't see how this patch can
change the playback speed. I also don't see how this patch could change
the audio backend sample frequency. Do you think there is a way to
reproduce this issue on my computer?
This can be fixed with the kernel command-line argument
snd_intel8x0.ac97_clock=48000.
If AmigaOS also tries to measure the audio clock frequency, it may
help to increase the playback latency to make the measurement worse.
I would start with -audiodev coreaudio,id=audio0,out.buffer-count=12.
The default buffer count is 4.
Are these options documented somewhere? I don't even know they exist
and which one to tune for different results so if this knowledge is
only something you have now it would be a great contribution to put it
in some docs for reference. Or if this is already described somewhere
maybe it should be made more prominent as I don't even know where to
look for it. Maybe also some generic intro on how the audio
infrastructure in QEMU works would be helpful too so one can
understand what the options tweak.
The QEMU documentation describes most of the options. But there is no
detailed description of the function. I have read the code.
With best regards,
Volker
Regards,
BALATON Zoltan
