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.
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.
Regards,
BALATON Zoltan