On Sun, 12 Mar 2023, Volker Rümelin wrote:
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?
The reproducer I know needs AmigaOS license for sam460ex. If you don't
have that maybe it can be also reproduced with Linux guest but I don't
know a good distro that supported sam460ex (current ones probably
don't as PPC32 is quite dead so maybe some older ones). The
manufacturer's site:
https://www.acube-systems.biz/index.php?page=hardware&pid=5
links to a site in downloads section with some Linux kernels but these
seem to be outdated and don't know which could work. AROS should have
a similar driver and I thought that could help but it does not make
sound likely due to endianness issues as I've wrote before. So this is
probably doesn't help much as the only easy way I know needs a closed
source OS.