Audio playback speed issue on sam460ex and pegasos2

Audio playback speed issue on sam460ex and pegasos2

[BALATON Zoltan]

Re: Audio playback speed issue on sam460ex and pegasos2

[BALATON Zoltan]

Sorry, sent this without body accidentally, full message will be sent 
after some more testing.

Re: Audio playback speed issue on sam460ex and pegasos2

[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?

Regards,
BALATON Zoltan

Re: Audio playback speed issue on sam460ex and pegasos2

[Volker Rümelin]

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. 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.

With best regards,
Volker

>
> Regards,
> BALATON Zoltan

Re: Audio playback speed issue on sam460ex and pegasos2

[BALATON Zoltan]

[-- Attachment #1: Type: text/plain, Size: 4397 bytes --]

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

Re: Audio playback speed issue on sam460ex and pegasos2

[Volker Rümelin]

Am 12.03.23 um 15:09 schrieb Rene Engel:
> Tested with -audiodev coreaudio,id=audio0,out.buffer-count=1 to 12
>
> 1 is too slow the rest up to 12 has no effect
>
> The sampling frequency of the via-ac97 driver is 48000 Hz under AmigaOs4.1
>
> Any other ideas?
>
>

In audio/audio_template.h in the AUD_open_ functions there is one

     ldebug ("open %s, freq %d, nchannels %d, fmt %d\n",
             name, as->freq, as->nchannels, as->fmt);

line. Please replace this line with

     fprintf(stderr, "open %s, freq %d, nchannels %d, fmt %d\n",
             name, as->freq, as->nchannels, as->fmt);

compile and start AmigaOS. Use the default out.buffer-count. I would 
like to know the via-ac97 drivers idea of the sampling frequency.

It would help if I could reproduce this issue on my computer.

With best regards,
Volker

Re: Audio playback speed issue on sam460ex and pegasos2

[Volker Rümelin]

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

Re: Audio playback speed issue on sam460ex and pegasos2

[BALATON Zoltan]

[-- Attachment #1: Type: text/plain, Size: 5949 bytes --]

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.

>>> 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.

Where are these in the docs? I could not find it even by searching under 
qemu/docs.

Regards,
BALATON Zoltan

Re: Audio playback speed issue on sam460ex and pegasos2

[Volker Rümelin]

Am 12.03.23 um 16:34 schrieb BALATON Zoltan:
> 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.

Debugging will be slow without a reproducer on my computer. I'll have a 
look at the link you provided.

>
>>>> 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.
>
> Where are these in the docs? I could not find it even by searching 
> under qemu/docs.

https://www.qemu.org/docs/master/system/invocation.html

Please search for coreaudio or alsa.

>
> Regards,
> BALATON Zoltan

Re: Audio playback speed issue on sam460ex and pegasos2

[BALATON Zoltan]

[-- Attachment #1: Type: text/plain, Size: 8670 bytes --]

On Sun, 12 Mar 2023, Volker Rümelin wrote:
> Am 12.03.23 um 16:34 schrieb BALATON Zoltan:
>> 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.
>
> Debugging will be slow without a reproducer on my computer. I'll have a look 
> at the link you provided.

Problem with most of those may be that they need an ATI Radeon graphics 
card but we don't emulate it enough in QEMU yet to work with those so it 
may be difficult to get those running. Maybe booting the kernel from 
command line with -kernel and -append to get output on serial could work 
as the boot selector used on sam460ex also misses a way to edit options 
of menu items.

The only other image that seems to boot with the default SM502 graphics 
I've found is this one: 
https://mirrors.ircam.fr/pub/crux-ppc/2.7/crux-ppc-2.7a.iso

but this has no sound support in its kernel so you may need to compile it 
to add an ES1370 driver if one was available back then. The sources and 
configs are on the iso but this does not seem to be an easy way either.

There may be other PPC Linux images that work but I don't know about them 
as I was mostly focusing on Amiga like OSes and make sure they run on 
sam460ex so did not test sound with Linux. I was trying to find an easier 
way but I could only come up with the above.

It's probably not a big issue now that pegasos2 also has sound, maybe more 
people want to use that instead as it's faster.

>>>>> 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.
>> 
>> Where are these in the docs? I could not find it even by searching under 
>> qemu/docs.
>
> https://www.qemu.org/docs/master/system/invocation.html
>
> Please search for coreaudio or alsa.

OK, that's basically the -help output, I've found it in qemu-options.hx in 
the source. But these don't quite tell me what those options are. E.g. 
for alsa:

in|out.period-length=usecs
     Sets the period length in microseconds.

in|out.try-poll=on|off
     Attempt to use poll mode with the device. Default is on.

But what is period length or poll mode and when do I have to tweak those 
and what are meaningful values? You've told me before that the crackling I 
get with alsa is because of try-poll and better turn that off. Why is the 
default on then? Can we set it to off by default? (I could try to make a 
patch but I don't know if that would make sense at all.) So maybe what's 
missing is some generic description on how all this works and what the 
parameters control in the big picture. I'm not saying you have to write 
that but if you are the only one who knows now then maybe nobody else can 
write that doc. If there are somebody else who knows these it would help 
to get some introduction somewhere we can refer to.

Regards,
BALATON Zoltan

Re: Audio playback speed issue on sam460ex and pegasos2

[Volker Rümelin]

Am 12.03.23 um 21:28 schrieb BALATON Zoltan:
> On Sun, 12 Mar 2023, Volker Rümelin wrote:
>> Am 12.03.23 um 16:34 schrieb BALATON Zoltan:
>>> 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.
>>
>> Debugging will be slow without a reproducer on my computer. I'll have 
>> a look at the link you provided.
>
> Problem with most of those may be that they need an ATI Radeon 
> graphics card but we don't emulate it enough in QEMU yet to work with 
> those so it may be difficult to get those running. Maybe booting the 
> kernel from command line with -kernel and -append to get output on 
> serial could work as the boot selector used on sam460ex also misses a 
> way to edit options of menu items.
>
> The only other image that seems to boot with the default SM502 
> graphics I've found is this one: 
> https://mirrors.ircam.fr/pub/crux-ppc/2.7/crux-ppc-2.7a.iso
>
> but this has no sound support in its kernel so you may need to compile 
> it to add an ES1370 driver if one was available back then. The sources 
> and configs are on the iso but this does not seem to be an easy way 
> either.
>
> There may be other PPC Linux images that work but I don't know about 
> them as I was mostly focusing on Amiga like OSes and make sure they 
> run on sam460ex so did not test sound with Linux. I was trying to find 
> an easier way but I could only come up with the above.
>
> It's probably not a big issue now that pegasos2 also has sound, maybe 
> more people want to use that instead as it's faster.

Hi,

I tested the ES1370 device with a x86_64 Linux guest. Playback is glitch 
free and the playback speed is correct. At the moment I fail to see why 
the ES1370 device with a PPC Linux should work differently than with a 
x86_64 Linux. The device emulation code is exactly identical and the 
Linux driver code for PPC should behave like Linux driver code for x86_64.

I also tested the ES1370 device with an x86 AROS guest. I can't get the 
audio playback to work without glitches. I think I will start here. 
Maybe it's the same problem as the AmigaOS problem.

>
>>>>>> 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.
>>>
>>> Where are these in the docs? I could not find it even by searching 
>>> under qemu/docs.
>>
>> https://www.qemu.org/docs/master/system/invocation.html
>>
>> Please search for coreaudio or alsa.
>
> OK, that's basically the -help output, I've found it in 
> qemu-options.hx in the source. But these don't quite tell me what 
> those options are. E.g. for alsa:
>
> in|out.period-length=usecs
>     Sets the period length in microseconds.
>
> in|out.try-poll=on|off
>     Attempt to use poll mode with the device. Default is on.
>
> But what is period length or poll mode and when do I have to tweak 
> those and what are meaningful values? You've told me before that the 
> crackling I get with alsa is because of try-poll and better turn that 
> off. Why is the default on then? Can we set it to off by default? (I 
> could try to make a patch but I don't know if that would make sense at 
> all.) So maybe what's missing is some generic description on how all 
> this works and what the parameters control in the big picture. I'm not 
> saying you have to write that but if you are the only one who knows 
> now then maybe nobody else can write that doc. If there are somebody 
> else who knows these it would help to get some introduction somewhere 
> we can refer to.

A large default period-length was responsible for the crackling. The 
unknown guest side audio buffer size determines how often QEMU has to 
read from the guest audio buffer. In your case period-length + 
timer-period was larger than the guest buffer size.

try-poll=on tells the ALSA backend to try to use an event loop instead 
of the audio timer. This works most of the time. But the poll event 
handler in the ALSA backend has a bug. For example, if the guest can't 
provide enough audio frames in time, the ALSA buffer is only partly full 
and the event handler will be called again and again on every iteration 
of the main loop. This increases the processor load and the guest has 
less processor time to provide new audio frames in time. I have two 
examples where a guest can't recover from this situation and the guest 
seems to hang.

ALSA poll mode was added in 2009 and no one complained so far. I don't 
think it's necessary to change the default. Also instead of changing the 
default, it would be better to fix the bug. Btw., the author of the 
sndio backend got it right.

Better audio documentation would certainly be helpful for other 
developers. But I am not the only one who knows the audio code. The 
audio code is not difficult to understand either.

However, I am not so sure if a more detailed description of the audio 
options will really help QEMU users. It would be more helpful to have 
less audio options that need to be tuned to each other. In my opinion 
the options timer-period and latency would be sufficient in all cases to 
tune the audio system to the guest.

With best regards,
Volker

>
> Regards,
> BALATON Zoltan

Re: Audio playback speed issue on sam460ex and pegasos2

[BALATON Zoltan]

[-- Attachment #1: Type: text/plain, Size: 5285 bytes --]

On Sun, 19 Mar 2023, Volker Rümelin wrote:
>>>> Where are these in the docs? I could not find it even by searching under 
>>>> qemu/docs.
>>> 
>>> https://www.qemu.org/docs/master/system/invocation.html
>>> 
>>> Please search for coreaudio or alsa.
>> 
>> OK, that's basically the -help output, I've found it in qemu-options.hx in 
>> the source. But these don't quite tell me what those options are. E.g. for 
>> alsa:
>> 
>> in|out.period-length=usecs
>>     Sets the period length in microseconds.
>> 
>> in|out.try-poll=on|off
>>     Attempt to use poll mode with the device. Default is on.
>> 
>> But what is period length or poll mode and when do I have to tweak those 
>> and what are meaningful values? You've told me before that the crackling I 
>> get with alsa is because of try-poll and better turn that off. Why is the 
>> default on then? Can we set it to off by default? (I could try to make a 
>> patch but I don't know if that would make sense at all.) So maybe what's 
>> missing is some generic description on how all this works and what the 
>> parameters control in the big picture. I'm not saying you have to write 
>> that but if you are the only one who knows now then maybe nobody else can 
>> write that doc. If there are somebody else who knows these it would help to 
>> get some introduction somewhere we can refer to.
>
> A large default period-length was responsible for the crackling. The unknown 
> guest side audio buffer size determines how often QEMU has to read from the 
> guest audio buffer. In your case period-length + timer-period was larger than 
> the guest buffer size.

Without knowing how all this works in QEMU so a generic description on 
what callbacks are used for what and when are they called (what is the 
audio timer and is period length related to that or something else, etc.) 
I still don't understand all this. Such general intro doc is missing or I 
don't know where to look for it.

> try-poll=on tells the ALSA backend to try to use an event loop instead of the 
> audio timer. This works most of the time. But the poll event handler in the 
> ALSA backend has a bug. For example, if the guest can't provide enough audio 
> frames in time, the ALSA buffer is only partly full and the event handler 
> will be called again and again on every iteration of the main loop. This 
> increases the processor load and the guest has less processor time to provide 
> new audio frames in time. I have two examples where a guest can't recover 
> from this situation and the guest seems to hang.

Is this bug tracked somewhere or is it something that you know about from 
heresay? Maybe somebody would attempt to fix it if it were understood but 
for me at least it's not clear from the above what the actual bug is and 
what could be a fix I could try to implement.

> ALSA poll mode was added in 2009 and no one complained so far. I don't think

Most distros have pulseaudio so maybe people haven't noticed because of 
that. I've only noticed it because I got rid of pulsaudio as it seems to 
solve a problem I don't have so I only use plain alsa for simple things or 
for more complex things there's jack so no reason to use pulseaudio.

> it's necessary to change the default. Also instead of changing the default, 
> it would be better to fix the bug. Btw., the author of the sndio backend got 
> it right.

Sure it would be better to fix that bug but is there anybody besides you 
who knows about it and understands it so it can be fixed?

> Better audio documentation would certainly be helpful for other developers. 
> But I am not the only one who knows the audio code. The audio code is not 
> difficult to understand either.

Any code is not difficult if you spend enough time with it. But if you've 
spent that time already you could help save time for others by summarising 
the knowledge to help others get started without having to spend much time 
getting to know the audio part of QEMU when they would rather spend time 
with other parts instead. But it's not a demand just trying to say that 
somebody who knows this part and improving the docs might help others to 
understand audio part better and maybe even contribute to it but now even 
using it can be difficult without understanding how it all works.

> However, I am not so sure if a more detailed description of the audio options 
> will really help QEMU users. It would be more helpful to have less audio 
> options that need to be tuned to each other. In my opinion the options 
> timer-period and latency would be sufficient in all cases to tune the audio 
> system to the guest.

Of course best would be if it would just work but if it doesn't it still 
helps to understand what's going on and what are the options to tune that 
might fix it. If the problem is an unknown guest side buffer is there a 
way to find this out from the emulated hardware (sound card models) so 
those could tell it to the audio part or somehow measuring the amount of 
data the guest is sending so the period can be adjusted automatically? 
(I'm completely guessing here without knowing how this really works so 
can't tell if any of these could work but maybe discussing the problem 
could inspire somebody to try to make a patch eventually.)

Regards,
BALATON Zoltan

Re: Audio playback speed issue on sam460ex and pegasos2

[BALATON Zoltan]

[-- Attachment #1: Type: text/plain, Size: 2759 bytes --]

On Sun, 12 Mar 2023, Volker Rümelin wrote:
> Am 12.03.23 um 15:09 schrieb Rene Engel:
>> Tested with -audiodev coreaudio,id=audio0,out.buffer-count=1 to 12
>> 
>> 1 is too slow the rest up to 12 has no effect
>> 
>> The sampling frequency of the via-ac97 driver is 48000 Hz under AmigaOs4.1
>> 
>> Any other ideas?
>> 
>> 
>
> In audio/audio_template.h in the AUD_open_ functions there is one
>
>     ldebug ("open %s, freq %d, nchannels %d, fmt %d\n",
>             name, as->freq, as->nchannels, as->fmt);
>
> line. Please replace this line with
>
>     fprintf(stderr, "open %s, freq %d, nchannels %d, fmt %d\n",
>             name, as->freq, as->nchannels, as->fmt);
>
> compile and start AmigaOS. Use the default out.buffer-count. I would like to 
> know the via-ac97 drivers idea of the sampling frequency.

Not sure this helps but I get these with DEBUG enabled in qemu/audio on 
Linux host with alsa set to 44100 Hz dmix rate with default settings 
without any -audiodev options with AmigaOS guest.
With pegasos2:

audio: open via-ac97.out, freq 44100, nchannels 1, fmt 1##############] 100 %
audio: open via-ac97.out, freq 44100, nchannels 2, fmt 3
alsa: enabling voice
alsa: disabling voice
alsa: alsa_fini

or pegasos2 with ES1370:

audio: open via-ac97.out, freq 44100, nchannels 2, fmt 3
alsa: enabling voice
alsa: disabling voice
alsa: alsa_fini

this does not play as slow as with sam460ex below but maybe a bit slow 
which seems to improve with try-poll=off so this may be because of the 
alsa backend issue. It's a bit faster with sdl backend, not sure if that's 
the right speed or too fast but at least the backend seems to influence 
playback speed.

With sam460ex and ES1370:

audio: open es1370.dac2, freq 44100, nchannels 1, fmt 0
audio: open es1370.adc, freq 44100, nchannels 1, fmt 0
audio: open es1370.dac2, freq 48662, nchannels 1, fmt 0
audio: open es1370.adc, freq 48662, nchannels 1, fmt 0
audio: open es1370.dac2, freq 48662, nchannels 2, fmt 3
alsa: enabling voice
alsa: disabling voice
alsa: alsa_fini

this plays definitely slow and the freq also seems to be off. I may have 
different AmigaOS versions on pegasos2 and sam460ex but I they seem to use 
the same driver as there were no updates to that part. I'm not sure what 
the driver in AmigaOS looks like but it may be similar to the AROS AHI 
SB128 one. I don't know if higher level parts in AHI may try to measure 
something like you mentioned but at least the card driver does not seem to 
do that.

There seems to be two independent problems, one is the bug in alsa backend 
that you mentioned and something else only affecting sam460ex which causes 
the wrong freq to be selected but I have no idea why or what to check 
further to find out.

Regards,
BALATON Zoltan

Re: Audio playback speed issue on sam460ex and pegasos2

[Volker Rümelin]

Am 19.03.23 um 18:49 schrieb BALATON Zoltan:
> On Sun, 12 Mar 2023, Volker Rümelin wrote:
>> Am 12.03.23 um 15:09 schrieb Rene Engel:
>>> Tested with -audiodev coreaudio,id=audio0,out.buffer-count=1 to 12
>>>
>>> 1 is too slow the rest up to 12 has no effect
>>>
>>> The sampling frequency of the via-ac97 driver is 48000 Hz under 
>>> AmigaOs4.1
>>>
>>> Any other ideas?
>>>
>>>
>>
>> In audio/audio_template.h in the AUD_open_ functions there is one
>>
>>     ldebug ("open %s, freq %d, nchannels %d, fmt %d\n",
>>             name, as->freq, as->nchannels, as->fmt);
>>
>> line. Please replace this line with
>>
>>     fprintf(stderr, "open %s, freq %d, nchannels %d, fmt %d\n",
>>             name, as->freq, as->nchannels, as->fmt);
>>
>> compile and start AmigaOS. Use the default out.buffer-count. I would 
>> like to know the via-ac97 drivers idea of the sampling frequency.
>
> Not sure this helps but I get these with DEBUG enabled in qemu/audio 
> on Linux host with alsa set to 44100 Hz dmix rate with default 
> settings without any -audiodev options with AmigaOS guest.
> With pegasos2:
>
> audio: open via-ac97.out, freq 44100, nchannels 1, fmt 
> 1##############] 100 %
> audio: open via-ac97.out, freq 44100, nchannels 2, fmt 3
> alsa: enabling voice
> alsa: disabling voice
> alsa: alsa_fini
>
> or pegasos2 with ES1370:
>
> audio: open via-ac97.out, freq 44100, nchannels 2, fmt 3
> alsa: enabling voice
> alsa: disabling voice
> alsa: alsa_fini
>
> this does not play as slow as with sam460ex below but maybe a bit slow 
> which seems to improve with try-poll=off so this may be because of the 
> alsa backend issue. It's a bit faster with sdl backend, not sure if 
> that's the right speed or too fast but at least the backend seems to 
> influence playback speed.
>

Hi,

I still don't understand how the playback speed can slow down without 
changing the pitch. Is it possible that the guest can't provide the 
audio frames fast enough and there are buffer underruns in the ALSA 
backend? But I think you would hear buffer underruns.

> With sam460ex and ES1370:
>
> audio: open es1370.dac2, freq 44100, nchannels 1, fmt 0
> audio: open es1370.adc, freq 44100, nchannels 1, fmt 0
> audio: open es1370.dac2, freq 48662, nchannels 1, fmt 0
> audio: open es1370.adc, freq 48662, nchannels 1, fmt 0
> audio: open es1370.dac2, freq 48662, nchannels 2, fmt 3
> alsa: enabling voice
> alsa: disabling voice
> alsa: alsa_fini
>
> this plays definitely slow and the freq also seems to be off. I may 
> have different AmigaOS versions on pegasos2 and sam460ex but I they 
> seem to use the same driver as there were no updates to that part. I'm 
> not sure what the driver in AmigaOS looks like but it may be similar 
> to the AROS AHI SB128 one. I don't know if higher level parts in AHI 
> may try to measure something like you mentioned but at least the card 
> driver does not seem to do that.

I had a look at the AROS SB128 driver and the AHI Preferences code. 
There is no code to measure the audio clock frequency. The frequency 
selection of 48662Hz seems to be a AROS/AmigaOS bug. This log is from a 
AROS x86 guest. I hear some faint static noise but the playback speed is 
correct.

open pcspk, freq 32000, nchannels 1, fmt 0
open es1370.dac2, freq 44100, nchannels 1, fmt 0
open es1370.adc, freq 44100, nchannels 1, fmt 0
open es1370.dac2, freq 48662, nchannels 1, fmt 0
open es1370.adc, freq 48662, nchannels 1, fmt 0
open es1370.dac2, freq 48662, nchannels 2, fmt 3
open es1370.dac2, freq 44100, nchannels 2, fmt 3
open es1370.adc, freq 44100, nchannels 1, fmt 0

>
> There seems to be two independent problems, one is the bug in alsa 
> backend that you mentioned and something else only affecting sam460ex 
> which causes the wrong freq to be selected but I have no idea why or 
> what to check further to find out. 

I'm not so sure if your analysis is correct. The ALSA error I mentioned 
can significantly increase the processor load, sometimes to the point of 
stopping the guest. But it can't directly change the playback speed.

I will write a patch with a few tracepoints for the audio system. With 
your help it should be possible to find the cause of the problem. It 
might take me a few days to write and test the patch.

With best regards,
Volker

>
>
> Regards,
> BALATON Zoltan

Re: Audio playback speed issue on sam460ex and pegasos2

[BALATON Zoltan]

[-- Attachment #1: Type: text/plain, Size: 6074 bytes --]

On Sun, 19 Mar 2023, Volker Rümelin wrote:
> Am 19.03.23 um 18:49 schrieb BALATON Zoltan:
>> On Sun, 12 Mar 2023, Volker Rümelin wrote:
>>> Am 12.03.23 um 15:09 schrieb Rene Engel:
>>>> Tested with -audiodev coreaudio,id=audio0,out.buffer-count=1 to 12
>>>> 
>>>> 1 is too slow the rest up to 12 has no effect
>>>> 
>>>> The sampling frequency of the via-ac97 driver is 48000 Hz under 
>>>> AmigaOs4.1
>>>> 
>>>> Any other ideas?
>>>> 
>>>> 
>>> 
>>> In audio/audio_template.h in the AUD_open_ functions there is one
>>> 
>>>     ldebug ("open %s, freq %d, nchannels %d, fmt %d\n",
>>>             name, as->freq, as->nchannels, as->fmt);
>>> 
>>> line. Please replace this line with
>>> 
>>>     fprintf(stderr, "open %s, freq %d, nchannels %d, fmt %d\n",
>>>             name, as->freq, as->nchannels, as->fmt);
>>> 
>>> compile and start AmigaOS. Use the default out.buffer-count. I would like 
>>> to know the via-ac97 drivers idea of the sampling frequency.
>> 
>> Not sure this helps but I get these with DEBUG enabled in qemu/audio on 
>> Linux host with alsa set to 44100 Hz dmix rate with default settings 
>> without any -audiodev options with AmigaOS guest.
>> With pegasos2:
>> 
>> audio: open via-ac97.out, freq 44100, nchannels 1, fmt 1##############] 100 
>> %
>> audio: open via-ac97.out, freq 44100, nchannels 2, fmt 3
>> alsa: enabling voice
>> alsa: disabling voice
>> alsa: alsa_fini
>> 
>> or pegasos2 with ES1370:
>> 
>> audio: open via-ac97.out, freq 44100, nchannels 2, fmt 3
>> alsa: enabling voice
>> alsa: disabling voice
>> alsa: alsa_fini
>> 
>> this does not play as slow as with sam460ex below but maybe a bit slow 
>> which seems to improve with try-poll=off so this may be because of the alsa 
>> backend issue. It's a bit faster with sdl backend, not sure if that's the 
>> right speed or too fast but at least the backend seems to influence 
>> playback speed.
>> 
>
> Hi,
>
> I still don't understand how the playback speed can slow down without 
> changing the pitch.

The pitch also changes when it's playing slow but sometimes the speed 
difference is not too big so pitch shift maybe not obvious.

> Is it possible that the guest can't provide the audio 
> frames fast enough and there are buffer underruns in the ALSA backend? But I 
> think you would hear buffer underruns.

I think we'll need your logging patch to verify this. Or are there some 
traces that I can enable to check this?

>> With sam460ex and ES1370:
>> 
>> audio: open es1370.dac2, freq 44100, nchannels 1, fmt 0
>> audio: open es1370.adc, freq 44100, nchannels 1, fmt 0
>> audio: open es1370.dac2, freq 48662, nchannels 1, fmt 0
>> audio: open es1370.adc, freq 48662, nchannels 1, fmt 0
>> audio: open es1370.dac2, freq 48662, nchannels 2, fmt 3
>> alsa: enabling voice
>> alsa: disabling voice
>> alsa: alsa_fini
>> 
>> this plays definitely slow and the freq also seems to be off. I may have 
>> different AmigaOS versions on pegasos2 and sam460ex but I they seem to use 
>> the same driver as there were no updates to that part. I'm not sure what 
>> the driver in AmigaOS looks like but it may be similar to the AROS AHI 
>> SB128 one. I don't know if higher level parts in AHI may try to measure 
>> something like you mentioned but at least the card driver does not seem to 
>> do that.
>
> I had a look at the AROS SB128 driver and the AHI Preferences code. There is 
> no code to measure the audio clock frequency. The frequency selection of 
> 48662Hz seems to be a AROS/AmigaOS bug. This log is from a AROS x86 guest. I 
> hear some faint static noise but the playback speed is correct.
>
> open pcspk, freq 32000, nchannels 1, fmt 0
> open es1370.dac2, freq 44100, nchannels 1, fmt 0
> open es1370.adc, freq 44100, nchannels 1, fmt 0
> open es1370.dac2, freq 48662, nchannels 1, fmt 0
> open es1370.adc, freq 48662, nchannels 1, fmt 0
> open es1370.dac2, freq 48662, nchannels 2, fmt 3
> open es1370.dac2, freq 44100, nchannels 2, fmt 3
> open es1370.adc, freq 44100, nchannels 1, fmt 0

Here you end up with the correct freq but for me it stays at 48662 on 
sam460ex so could that explain a speed difference? Also selecting 
different sound options in AHI Prefs the test sound sounds quite different 
which probably should not if only the resolution or freq is changed but 
I'm not sure what the options really set.

>> There seems to be two independent problems, one is the bug in alsa backend 
>> that you mentioned and something else only affecting sam460ex which causes 
>> the wrong freq to be selected but I have no idea why or what to check 
>> further to find out. 
>
> I'm not so sure if your analysis is correct. The ALSA error I mentioned can 
> significantly increase the processor load, sometimes to the point of stopping 
> the guest. But it can't directly change the playback speed.

What I meant is we likely have multiple issues (and the slow speed on 
sam460ex may even be a guest bug if that's because using 48662 instead of 
44100 Hz) but just changing the audiodev and it's options I hear different 
results on pegasos2 which does not play that slow as sam460ex so this may 
be some alsa backend issue.

I've looked at the alsa and sndio backends to see if I can find what the 
issue with poll may be but since I don't know how it works I can't fix it. 
What I've noticed is that the sndio backend seems to remove the poll 
calbacks while handling the previous poll results and reenable them 
afterwards. Would the alsa backend need some flag that is set after 
handling poll results so while this is set the poll callback would return 
instead of calling the handler again or it really needs to be removed and 
reinstalled every time? (Or maybe it's not even the issue you were hinting 
at.)

> I will write a patch with a few tracepoints for the audio system. With your 
> help it should be possible to find the cause of the problem. It might take me 
> a few days to write and test the patch.

Thanks for looking at it, let me know if I can test anything that could 
help.

Regards,
BALATON Zoltan

Re: Audio playback speed issue on sam460ex and pegasos2

[Volker Rümelin]

Am 19.03.23 um 21:18 schrieb BALATON Zoltan:
> On Sun, 19 Mar 2023, Volker Rümelin wrote:
>> Am 19.03.23 um 18:49 schrieb BALATON Zoltan:
>>> On Sun, 12 Mar 2023, Volker Rümelin wrote:
>>>> Am 12.03.23 um 15:09 schrieb Rene Engel:
>>>>> Tested with -audiodev coreaudio,id=audio0,out.buffer-count=1 to 12
>>>>>
>>>>> 1 is too slow the rest up to 12 has no effect
>>>>>
>>>>> The sampling frequency of the via-ac97 driver is 48000 Hz under 
>>>>> AmigaOs4.1
>>>>>
>>>>> Any other ideas?
>>>>>
>>>>>
>>>>
>>>> In audio/audio_template.h in the AUD_open_ functions there is one
>>>>
>>>>     ldebug ("open %s, freq %d, nchannels %d, fmt %d\n",
>>>>             name, as->freq, as->nchannels, as->fmt);
>>>>
>>>> line. Please replace this line with
>>>>
>>>>     fprintf(stderr, "open %s, freq %d, nchannels %d, fmt %d\n",
>>>>             name, as->freq, as->nchannels, as->fmt);
>>>>
>>>> compile and start AmigaOS. Use the default out.buffer-count. I 
>>>> would like to know the via-ac97 drivers idea of the sampling 
>>>> frequency.
>>>
>>> Not sure this helps but I get these with DEBUG enabled in qemu/audio 
>>> on Linux host with alsa set to 44100 Hz dmix rate with default 
>>> settings without any -audiodev options with AmigaOS guest.
>>> With pegasos2:
>>>
>>> audio: open via-ac97.out, freq 44100, nchannels 1, fmt 
>>> 1##############] 100 %
>>> audio: open via-ac97.out, freq 44100, nchannels 2, fmt 3
>>> alsa: enabling voice
>>> alsa: disabling voice
>>> alsa: alsa_fini
>>>
>>> or pegasos2 with ES1370:
>>>
>>> audio: open via-ac97.out, freq 44100, nchannels 2, fmt 3
>>> alsa: enabling voice
>>> alsa: disabling voice
>>> alsa: alsa_fini
>>>
>>> this does not play as slow as with sam460ex below but maybe a bit 
>>> slow which seems to improve with try-poll=off so this may be because 
>>> of the alsa backend issue. It's a bit faster with sdl backend, not 
>>> sure if that's the right speed or too fast but at least the backend 
>>> seems to influence playback speed.
>>>
>>
>> Hi,
>>
>> I still don't understand how the playback speed can slow down without 
>> changing the pitch.
>
> The pitch also changes when it's playing slow but sometimes the speed 
> difference is not too big so pitch shift maybe not obvious.
>
>> Is it possible that the guest can't provide the audio frames fast 
>> enough and there are buffer underruns in the ALSA backend? But I 
>> think you would hear buffer underruns.
>
> I think we'll need your logging patch to verify this. Or are there 
> some traces that I can enable to check this?
>
>>> With sam460ex and ES1370:
>>>
>>> audio: open es1370.dac2, freq 44100, nchannels 1, fmt 0
>>> audio: open es1370.adc, freq 44100, nchannels 1, fmt 0
>>> audio: open es1370.dac2, freq 48662, nchannels 1, fmt 0
>>> audio: open es1370.adc, freq 48662, nchannels 1, fmt 0
>>> audio: open es1370.dac2, freq 48662, nchannels 2, fmt 3
>>> alsa: enabling voice
>>> alsa: disabling voice
>>> alsa: alsa_fini
>>>
>>> this plays definitely slow and the freq also seems to be off. I may 
>>> have different AmigaOS versions on pegasos2 and sam460ex but I they 
>>> seem to use the same driver as there were no updates to that part. 
>>> I'm not sure what the driver in AmigaOS looks like but it may be 
>>> similar to the AROS AHI SB128 one. I don't know if higher level 
>>> parts in AHI may try to measure something like you mentioned but at 
>>> least the card driver does not seem to do that.
>>
>> I had a look at the AROS SB128 driver and the AHI Preferences code. 
>> There is no code to measure the audio clock frequency. The frequency 
>> selection of 48662Hz seems to be a AROS/AmigaOS bug. This log is from 
>> a AROS x86 guest. I hear some faint static noise but the playback 
>> speed is correct.
>>
>> open pcspk, freq 32000, nchannels 1, fmt 0
>> open es1370.dac2, freq 44100, nchannels 1, fmt 0
>> open es1370.adc, freq 44100, nchannels 1, fmt 0
>> open es1370.dac2, freq 48662, nchannels 1, fmt 0
>> open es1370.adc, freq 48662, nchannels 1, fmt 0
>> open es1370.dac2, freq 48662, nchannels 2, fmt 3
>> open es1370.dac2, freq 44100, nchannels 2, fmt 3
>> open es1370.adc, freq 44100, nchannels 1, fmt 0
>
> Here you end up with the correct freq but for me it stays at 48662 on 
> sam460ex so could that explain a speed difference? Also selecting 
> different sound options in AHI Prefs the test sound sounds quite 
> different which probably should not if only the resolution or freq is 
> changed but I'm not sure what the options really set.
>
>>> There seems to be two independent problems, one is the bug in alsa 
>>> backend that you mentioned and something else only affecting 
>>> sam460ex which causes the wrong freq to be selected but I have no 
>>> idea why or what to check further to find out. 
>>
>> I'm not so sure if your analysis is correct. The ALSA error I 
>> mentioned can significantly increase the processor load, sometimes to 
>> the point of stopping the guest. But it can't directly change the 
>> playback speed.
>
> What I meant is we likely have multiple issues (and the slow speed on 
> sam460ex may even be a guest bug if that's because using 48662 instead 
> of 44100 Hz) but just changing the audiodev and it's options I hear 
> different results on pegasos2 which does not play that slow as 
> sam460ex so this may be some alsa backend issue.
>
> I've looked at the alsa and sndio backends to see if I can find what 
> the issue with poll may be but since I don't know how it works I can't 
> fix it. What I've noticed is that the sndio backend seems to remove 
> the poll calbacks while handling the previous poll results and 
> reenable them afterwards. Would the alsa backend need some flag that 
> is set after handling poll results so while this is set the poll 
> callback would return instead of calling the handler again or it 
> really needs to be removed and reinstalled every time? (Or maybe it's 
> not even the issue you were hinting at.)

Hi,

the alsa backend installs the fd handlers unconditionally. For the 
playback stream sndio installs the handler only if the audio frontend 
has provided new audio frames and for the recording stream sndio 
installs the handler only if the audio frontend has read audio frames. 
It uses a timer to restart the streams without installed handler.

With best regards,
Volker

>
>> I will write a patch with a few tracepoints for the audio system. 
>> With your help it should be possible to find the cause of the 
>> problem. It might take me a few days to write and test the patch.
>
> Thanks for looking at it, let me know if I can test anything that 
> could help.
>
> Regards,
> BALATON Zoltan

Re: Audio playback speed issue on sam460ex and pegasos2

[Volker Rümelin]

Am 19.03.23 um 21:03 schrieb Volker Rümelin:
> Am 19.03.23 um 18:49 schrieb BALATON Zoltan:
>>
>> Not sure this helps but I get these with DEBUG enabled in qemu/audio 
>> on Linux host with alsa set to 44100 Hz dmix rate with default 
>> settings without any -audiodev options with AmigaOS guest.
>> With pegasos2:
>>
>> audio: open via-ac97.out, freq 44100, nchannels 1, fmt 
>> 1##############] 100 %
>> audio: open via-ac97.out, freq 44100, nchannels 2, fmt 3
>> alsa: enabling voice
>> alsa: disabling voice
>> alsa: alsa_fini
>>
>> or pegasos2 with ES1370:
>>
>> audio: open via-ac97.out, freq 44100, nchannels 2, fmt 3
>> alsa: enabling voice
>> alsa: disabling voice
>> alsa: alsa_fini
>>
>> this does not play as slow as with sam460ex below but maybe a bit 
>> slow which seems to improve with try-poll=off so this may be because 
>> of the alsa backend issue. It's a bit faster with sdl backend, not 
>> sure if that's the right speed or too fast but at least the backend 
>> seems to influence playback speed.
>>
>
> Hi,
>
> I still don't understand how the playback speed can slow down without 
> changing the pitch. Is it possible that the guest can't provide the 
> audio frames fast enough and there are buffer underruns in the ALSA 
> backend? But I think you would hear buffer underruns.
>
>> With sam460ex and ES1370:
>>
>> audio: open es1370.dac2, freq 44100, nchannels 1, fmt 0
>> audio: open es1370.adc, freq 44100, nchannels 1, fmt 0
>> audio: open es1370.dac2, freq 48662, nchannels 1, fmt 0
>> audio: open es1370.adc, freq 48662, nchannels 1, fmt 0
>> audio: open es1370.dac2, freq 48662, nchannels 2, fmt 3
>> alsa: enabling voice
>> alsa: disabling voice
>> alsa: alsa_fini
>>
>> this plays definitely slow and the freq also seems to be off. I may 
>> have different AmigaOS versions on pegasos2 and sam460ex but I they 
>> seem to use the same driver as there were no updates to that part. 
>> I'm not sure what the driver in AmigaOS looks like but it may be 
>> similar to the AROS AHI SB128 one. I don't know if higher level parts 
>> in AHI may try to measure something like you mentioned but at least 
>> the card driver does not seem to do that.
>
> I had a look at the AROS SB128 driver and the AHI Preferences code. 
> There is no code to measure the audio clock frequency. The frequency 
> selection of 48662Hz seems to be a AROS/AmigaOS bug. This log is from 
> a AROS x86 guest. I hear some faint static noise but the playback 
> speed is correct.
>
> open pcspk, freq 32000, nchannels 1, fmt 0
> open es1370.dac2, freq 44100, nchannels 1, fmt 0
> open es1370.adc, freq 44100, nchannels 1, fmt 0
> open es1370.dac2, freq 48662, nchannels 1, fmt 0
> open es1370.adc, freq 48662, nchannels 1, fmt 0
> open es1370.dac2, freq 48662, nchannels 2, fmt 3
> open es1370.dac2, freq 44100, nchannels 2, fmt 3
> open es1370.adc, freq 44100, nchannels 1, fmt 0
>
>>
>> There seems to be two independent problems, one is the bug in alsa 
>> backend that you mentioned and something else only affecting sam460ex 
>> which causes the wrong freq to be selected but I have no idea why or 
>> what to check further to find out. 
>
> I'm not so sure if your analysis is correct. The ALSA error I 
> mentioned can significantly increase the processor load, sometimes to 
> the point of stopping the guest. But it can't directly change the 
> playback speed.
>
> I will write a patch with a few tracepoints for the audio system. With 
> your help it should be possible to find the cause of the problem. It 
> might take me a few days to write and test the patch.
>
> With best regards,
> Volker

Hi Zoltan,

I have written a few patches to add audio tracepoints. I pushed my 
audio-tracepoints branch to https://gitlab.com/volker.ruemelin/qemu.git.

For useful audio trace files QEMU has to be compiled with 
--enable-trace-backends=simple to enable the "simple" trace backend. The 
command line options  -trace "audio_open*_out" -trace 
"audio_*_frames_out" -trace file=/tmp/qemu-trace enable audio playback 
tracing. To view the trace start ./scripts/simpletrace.py 
trace/trace-events-all /tmp/qemu-trace | less in the QEMU build directory.

Here is an example of audio playback of a mp3 file with mplayer in a x86 
AROS guest. I used -device ES1370,audiodev=audio0 -audiodev 
alsa,id=audio0,out.try-poll=off,out.dev=hw:PCH,,0,in.try-poll=off,in.dev=hw:PCH,,0

audio_open_out 0.000 pid=8798 card=b'es1370' name=b'es1370.dac2' 
freq=0xac44 fmt=b'u8' ch=0x1
audio_open_info_out 249624.597 pid=8798 end=b'sw' card=b'es1370' 
name=b'es1370.dac2' freq=0xac44 ch=0x1 bits=0x8 is_signed=0x0 is_fl
oat=0x0
audio_open_info_out 0.853 pid=8798 end=b'hw' card=b'es1370' 
name=b'es1370.dac2' freq=0xac44 ch=0x2 bits=0x10 is_signed=0x1 is_float=
0x0
audio_open_out 52404.954 pid=8798 card=b'es1370' name=b'es1370.dac2' 
freq=0xac44 fmt=b's16' ch=0x2
audio_open_info_out 10.985 pid=8798 end=b'sw' card=b'es1370' 
name=b'es1370.dac2' freq=0xac44 ch=0x2 bits=0x10 is_signed=0x1 is_float
=0x0
audio_open_info_out 0.606 pid=8798 end=b'hw' card=b'es1370' 
name=b'es1370.dac2' freq=0xac44 ch=0x2 bits=0x10 is_signed=0x1 is_float=
0x0
audio_fe_frames_out 10145.216 pid=8798 fe_free=0x1000 fe_written=0x1
audio_hw_frames_out 21.720 pid=8798 hw_free=0x1000 hw_written=0x1
audio_fe_frames_out 10090.675 pid=8798 fe_free=0x1000 fe_written=0x372
audio_hw_frames_out 11.752 pid=8798 hw_free=0x1000 hw_written=0x372
audio_fe_frames_out 10051.461 pid=8798 fe_free=0xdae fe_written=0x371
audio_hw_frames_out 5.026 pid=8798 hw_free=0xdae hw_written=0x371
audio_fe_frames_out 10041.808 pid=8798 fe_free=0xc1e fe_written=0x1
audio_hw_frames_out 5.089 pid=8798 hw_free=0xc1e hw_written=0x1
audio_fe_frames_out 10065.035 pid=8798 fe_free=0xe2d fe_written=0x372
audio_hw_frames_out 5.797 pid=8798 hw_free=0xe2d hw_written=0x372
audio_fe_frames_out 10051.544 pid=8798 fe_free=0xbca fe_written=0x371

Could you create a trace with sam460ex and ES1370? Please use mplayer or 
another media player for the traces. The audio buffer from the AHI 
Preferences is very small. It may be impossible to make the test sound 
play correctly.

It's not necessary to send the whole trace file. I would like to see the 
audio_open_* lines and 40-50 audio_*_frames_out lines one or two seconds 
after playback started. The trace file time stamps are in microseconds.

With best regards,
Volker

Re: Audio playback speed issue on sam460ex and pegasos2

[Volker Rümelin]

Am 28.03.23 um 16:37 schrieb Rene Engel:
> Sorry I was on the wrong branch.
> I forget that every time, however that is trace test performed with ac97 under Pegasos 2 Emulation with AmigaOs4.1, startsound played and an mp3 with TuneNet.
>
> audio_open_out 0.000 pid=8358 card=b'via-ac97' name=b'via-ac97.out' freq=0xac44 fmt=b's8' ch=0x1
> audio_open_info_out 52921.000 pid=8358 end=b'sw' card=b'via-ac97' name=b'via-ac97.out' freq=0xac44 ch=0x1 bits=0x8 is_signed=0x1 is_float=0x0
> audio_open_info_out 0.000 pid=8358 end=b'hw' card=b'via-ac97' name=b'via-ac97.out' freq=0xac44 ch=0x2 bits=0x20 is_signed=0x1 is_float=0x1
> audio_open_out 1019.000 pid=8358 card=b'via-ac97' name=b'via-ac97.out' freq=0xac44 fmt=b's16' ch=0x2
> audio_open_info_out 2.000 pid=8358 end=b'sw' card=b'via-ac97' name=b'via-ac97.out' freq=0xac44 ch=0x2 bits=0x10 is_signed=0x1 is_float=0x0
> audio_open_info_out 0.000 pid=8358 end=b'hw' card=b'via-ac97' name=b'via-ac97.out' freq=0xac44 ch=0x2 bits=0x20 is_signed=0x1 is_float=0x1
> audio_fe_frames_out 130352.000 pid=8358 fe_free=0x800 fe_written=0x372
> audio_hw_frames_out 2.000 pid=8358 hw_free=0x800 hw_written=0x372
> audio_fe_frames_out 10265.000 pid=8358 fe_free=0x68e fe_written=0x372
> audio_hw_frames_out 1.000 pid=8358 hw_free=0x68e hw_written=0x372
> audio_fe_frames_out 11159.000 pid=8358 fe_free=0x51c fe_written=0x372
> audio_hw_frames_out 1.000 pid=8358 hw_free=0x51c hw_written=0x372
> audio_fe_frames_out 10211.000 pid=8358 fe_free=0x3aa fe_written=0x372
> audio_hw_frames_out 0.000 pid=8358 hw_free=0x3aa hw_written=0x372
> audio_fe_frames_out 10522.000 pid=8358 fe_free=0x238 fe_written=0x238
> audio_hw_frames_out 1.000 pid=8358 hw_free=0x238 hw_written=0x238
> audio_fe_frames_out 10122.000 pid=8358 fe_free=0x200 fe_written=0x13a
> audio_hw_frames_out 0.000 pid=8358 hw_free=0x200 hw_written=0x13a
> audio_fe_frames_out 10541.000 pid=8358 fe_free=0x2c6 fe_written=0x2c6
> audio_hw_frames_out 0.000 pid=8358 hw_free=0x2c6 hw_written=0x2c6
> audio_fe_frames_out 10366.000 pid=8358 fe_free=0x200 fe_written=0xac
> audio_hw_frames_out 0.000 pid=8358 hw_free=0x200 hw_written=0xac
> audio_fe_frames_out 10582.000 pid=8358 fe_free=0x354 fe_written=0x354
> audio_hw_frames_out 1.000 pid=8358 hw_free=0x354 hw_written=0x354
> audio_fe_frames_out 10111.000 pid=8358 fe_free=0x200 fe_written=0x1e
> audio_hw_frames_out 0.000 pid=8358 hw_free=0x200 hw_written=0x1e
> audio_fe_frames_out 10367.000 pid=8358 fe_free=0x3e2 fe_written=0x372
> audio_hw_frames_out 1.000 pid=8358 hw_free=0x3e2 hw_written=0x372
> audio_fe_frames_out 10129.000 pid=8358 fe_free=0x270 fe_written=0x270
> audio_hw_frames_out 1.000 pid=8358 hw_free=0x270 hw_written=0x270
> audio_fe_frames_out 10204.000 pid=8358 fe_free=0x200 fe_written=0x102
> audio_hw_frames_out 0.000 pid=8358 hw_free=0x200 hw_written=0x102
> audio_fe_frames_out 10656.000 pid=8358 fe_free=0x2fe fe_written=0x2fe
> audio_hw_frames_out 1.000 pid=8358 hw_free=0x2fe hw_written=0x2fe
> audio_fe_frames_out 10363.000 pid=8358 fe_free=0x200 fe_written=0x74
> audio_hw_frames_out 1.000 pid=8358 hw_free=0x200 hw_written=0x74
> audio_fe_frames_out 10436.000 pid=8358 fe_free=0x38c fe_written=0x372
> audio_hw_frames_out 0.000 pid=8358 hw_free=0x38c hw_written=0x372

Hi Rene,

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?

The default for out.frequency is 44100.

With best regards,
Volker

> --- Ursprüngliche Nachricht ---
> Von: Volker Rümelin <vr_qemu@t-online.de>
> Datum: 27.03.2023 21:12:42
> An: Rene Engel <ReneEngel80@emailn.de>
> Betreff: Re: Audio playback speed issue on sam460ex and pegasos2
>
>> Am 27.03.23 um 16:21 schrieb Rene Engel:
>>> I compiled the build from their git branch and enabled the audio trace,
>> but with this option the AmigaOs4.1 workbench does not start anymore and
>> stops with a load sign. Tested with ac97 it almost looks like the ac97 part
>> that used to stop AmigaOs4.1 is not included in your build.
>>> This is the command line I used:
>>>
>>> reneengel@Mac-Studio build % cd /Users/reneengel/qemuVolkerAudioPatch/build
>>> reneengel@Mac-Studio build % qemu-system-ppc -L pc-bios -M pegasos2
>> -bios /Volumes/BackUP/PegasosQemuDatein/pegasos2.rom -vga none -device sm501
>> -drive if=none,id=cd -m 1024 -device ide-cd,drive=cd,bus=ide.1 -drive if=none,id=hd,file=/Volumes/EXTREME\
>> SSD/hd1.img,format=raw -device ide-hd,drive=hd,bus=ide.0 -device rtl8139,netdev=network00
>> -netdev user,id=network00 -rtc base=localtime -display cocoa -serial stdio
>> -smp cores=1 -trace "audio_open*_out" -trace "audio_*_frames_out"
>> -trace file=/tmp/qemu-trace
>>
>> Is the current directory included in the macOS search path? On my Linux
>> system qemu-system-ppc starts the installed QEMU executable. I have to
>> use ./qemu-system-ppc to start the program from the build directory.
>>
>>

Re: Audio playback speed issue on sam460ex and pegasos2

[BALATON Zoltan]

[-- Attachment #1: Type: text/plain, Size: 828 bytes --]

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.

> 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?

Regards,
BALATON Zoltan

Re: Audio playback speed issue on sam460ex and pegasos2

[Volker Rümelin]

Am 29.03.23 um 14:03 schrieb Rene Engel:
> After short tests with the command line -audiodev coreaudio,id=audio0,out.frequency=48000 the sound output runs in the correct speed.
>
> Tested with one and the same mp3 file under AmigaOs4.1 and MacOs with es1370 and ac97 on Pegasos 2 emulation

This indicates that there is a bug in the Core Audio backend. I wonder 
how you manage to set a system sample rate of 48kHz when QEMU explicitly 
requires 44.1kHz. See 
https://lists.nongnu.org/archive/html/qemu-discuss/2023-03/msg00076.html 
or GitLab issue #1191 https://gitlab.com/qemu-project/qemu/-/issues/1191.

I can't really help to fix this Core Audio backend issue. I don't have a 
Mac. Until this bug is fixed, you will have to live with the workaround.

With best regards,
Volker

> --- Ursprüngliche Nachricht ---
> Von: Volker Rümelin <vr_qemu@t-online.de>
> Datum: 28.03.2023 20:26:14
> An: Rene Engel <ReneEngel80@emailn.de>
> Betreff: Re: Audio playback speed issue on sam460ex and pegasos2
>
>> Am 28.03.23 um 16:37 schrieb Rene Engel:
>>> Sorry I was on the wrong branch.
>>> I forget that every time, however that is trace test performed with
>> ac97 under Pegasos 2 Emulation with AmigaOs4.1, startsound played and an
>> mp3 with TuneNet.
>>> audio_open_out 0.000 pid=8358 card=b'via-ac97' name=b'via-ac97.out'
>> freq=0xac44 fmt=b's8' ch=0x1
>>> audio_open_info_out 52921.000 pid=8358 end=b'sw' card=b'via-ac97' name=b'via-ac97.out'
>> freq=0xac44 ch=0x1 bits=0x8 is_signed=0x1 is_float=0x0
>>> audio_open_info_out 0.000 pid=8358 end=b'hw' card=b'via-ac97' name=b'via-ac97.out'
>> freq=0xac44 ch=0x2 bits=0x20 is_signed=0x1 is_float=0x1
>>> audio_open_out 1019.000 pid=8358 card=b'via-ac97' name=b'via-ac97.out'
>> freq=0xac44 fmt=b's16' ch=0x2
>>> audio_open_info_out 2.000 pid=8358 end=b'sw' card=b'via-ac97' name=b'via-ac97.out'
>> freq=0xac44 ch=0x2 bits=0x10 is_signed=0x1 is_float=0x0
>>> audio_open_info_out 0.000 pid=8358 end=b'hw' card=b'via-ac97' name=b'via-ac97.out'
>> freq=0xac44 ch=0x2 bits=0x20 is_signed=0x1 is_float=0x1
>>> audio_fe_frames_out 130352.000 pid=8358 fe_free=0x800 fe_written=0x372
>>> audio_hw_frames_out 2.000 pid=8358 hw_free=0x800 hw_written=0x372
>>> audio_fe_frames_out 10265.000 pid=8358 fe_free=0x68e fe_written=0x372
>>> audio_hw_frames_out 1.000 pid=8358 hw_free=0x68e hw_written=0x372
>>> audio_fe_frames_out 11159.000 pid=8358 fe_free=0x51c fe_written=0x372
>>> audio_hw_frames_out 1.000 pid=8358 hw_free=0x51c hw_written=0x372
>>> audio_fe_frames_out 10211.000 pid=8358 fe_free=0x3aa fe_written=0x372
>>> audio_hw_frames_out 0.000 pid=8358 hw_free=0x3aa hw_written=0x372
>>> audio_fe_frames_out 10522.000 pid=8358 fe_free=0x238 fe_written=0x238
>>> audio_hw_frames_out 1.000 pid=8358 hw_free=0x238 hw_written=0x238
>>> audio_fe_frames_out 10122.000 pid=8358 fe_free=0x200 fe_written=0x13a
>>> audio_hw_frames_out 0.000 pid=8358 hw_free=0x200 hw_written=0x13a
>>> audio_fe_frames_out 10541.000 pid=8358 fe_free=0x2c6 fe_written=0x2c6
>>> audio_hw_frames_out 0.000 pid=8358 hw_free=0x2c6 hw_written=0x2c6
>>> audio_fe_frames_out 10366.000 pid=8358 fe_free=0x200 fe_written=0xac
>>> audio_hw_frames_out 0.000 pid=8358 hw_free=0x200 hw_written=0xac
>>> audio_fe_frames_out 10582.000 pid=8358 fe_free=0x354 fe_written=0x354
>>> audio_hw_frames_out 1.000 pid=8358 hw_free=0x354 hw_written=0x354
>>> audio_fe_frames_out 10111.000 pid=8358 fe_free=0x200 fe_written=0x1e
>>> audio_hw_frames_out 0.000 pid=8358 hw_free=0x200 hw_written=0x1e
>>> audio_fe_frames_out 10367.000 pid=8358 fe_free=0x3e2 fe_written=0x372
>>> audio_hw_frames_out 1.000 pid=8358 hw_free=0x3e2 hw_written=0x372
>>> audio_fe_frames_out 10129.000 pid=8358 fe_free=0x270 fe_written=0x270
>>> audio_hw_frames_out 1.000 pid=8358 hw_free=0x270 hw_written=0x270
>>> audio_fe_frames_out 10204.000 pid=8358 fe_free=0x200 fe_written=0x102
>>> audio_hw_frames_out 0.000 pid=8358 hw_free=0x200 hw_written=0x102
>>> audio_fe_frames_out 10656.000 pid=8358 fe_free=0x2fe fe_written=0x2fe
>>> audio_hw_frames_out 1.000 pid=8358 hw_free=0x2fe hw_written=0x2fe
>>> audio_fe_frames_out 10363.000 pid=8358 fe_free=0x200 fe_written=0x74
>>> audio_hw_frames_out 1.000 pid=8358 hw_free=0x200 hw_written=0x74
>>> audio_fe_frames_out 10436.000 pid=8358 fe_free=0x38c fe_written=0x372
>>> audio_hw_frames_out 0.000 pid=8358 hw_free=0x38c hw_written=0x372
>> Hi Rene,
>>
>> 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?
>>
>> The default for out.frequency is 44100.
>>
>> With best regards,
>> Volker
>>
>>> --- Ursprüngliche Nachricht ---
>>> Von: Volker Rümelin <vr_qemu@t-online.de>
>>> Datum: 27.03.2023 21:12:42
>>> An: Rene Engel <ReneEngel80@emailn.de>
>>> Betreff: Re: Audio playback speed issue on sam460ex and pegasos2
>>>
>>>> Am 27.03.23 um 16:21 schrieb Rene Engel:
>>>>> I compiled the build from their git branch and enabled the audio
>> trace,
>>>> but with this option the AmigaOs4.1 workbench does not start anymore
>> and
>>>> stops with a load sign. Tested with ac97 it almost looks like the
>> ac97 part
>>>> that used to stop AmigaOs4.1 is not included in your build.
>>>>> This is the command line I used:
>>>>>
>>>>> reneengel@Mac-Studio build % cd /Users/reneengel/qemuVolkerAudioPatch/build
>>>>> reneengel@Mac-Studio build % qemu-system-ppc -L pc-bios -M pegasos2
>>>> -bios /Volumes/BackUP/PegasosQemuDatein/pegasos2.rom -vga none -device
>> sm501
>>>> -drive if=none,id=cd -m 1024 -device ide-cd,drive=cd,bus=ide.1 -drive
>> if=none,id=hd,file=/Volumes/EXTREME\
>>>> SSD/hd1.img,format=raw -device ide-hd,drive=hd,bus=ide.0 -device
>> rtl8139,netdev=network00
>>>> -netdev user,id=network00 -rtc base=localtime -display cocoa -serial
>> stdio
>>>> -smp cores=1 -trace "audio_open*_out" -trace "audio_*_frames_out"
>>>> -trace file=/tmp/qemu-trace
>>>>
>>>> Is the current directory included in the macOS search path? On my
>> Linux
>>>> system qemu-system-ppc starts the installed QEMU executable. I have
>> to
>>>> use ./qemu-system-ppc to start the program from the build directory.
>>>>
>>
>

Re: Audio playback speed issue on sam460ex and pegasos2

[Volker Rümelin]

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. I think the Google 
Android emulator fork of QEMU uses the Core Audio API to resample the 
audio stream in this case.

>
> Regards,
> BALATON Zoltan

Re: Audio playback speed issue on sam460ex and pegasos2

[BALATON Zoltan]

[-- Attachment #1: Type: text/plain, Size: 1972 bytes --]

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