Re: Audio playback speed issue on sam460ex and pegasos2

["Volker Rümelin" <vr_qemu@t-online.de>]

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