Noticeable audio delay with buffer size

[vanfanel]

I have noticed that audio is very delayed on games. I have investigated the buffer size and you seem to be using:

as.samples = SOUND_CONSUMER_BUFFER_LENGTH;

passed to:

SDL_OpenAudio(&as, NULL)

SOUND_CONSUMER_BUFFER_LENGTH seems to be calculated previously. I have tried changing it to 1024 or 512 but I get distorted audio then. I am ussing the default 44100 Hz frequency, so audio buffers should be depleted as fast as possible. Any other way to improve this audio latency?

[midwan]

@vanfanel Please specify which games you tested this with, and which version of the emulator you tested it on?

[vanfanel]

@midwan : I always use latest git version, dev branch. It's noticeable on every game, as it does not depend on the games but on the sound buffer management of the emulator, but you can see it easily in Lemmings: click between abilities, and you will see the "clonk!" sound is way more delayed than it is on real hw.

Also, it's not my audio setup/equipment: RetroArch and other SDL2 games don't show this on the same Rpi3 and the same setup.

[midwan]

@vanfanel Thanks, so I assume you're using the SDL2 version? Are you running a 60Hz or 50Hz display? It may be related.

[CypherXG]

With the SDL1 Version i have no problems with the audio. With Picasso mode with 60 Hz all Mods running good when i change the Timing from the player to CIA or Vsync. I use Hippoplayer and the Egaleplayer. In 50Hz Mode (normal gaming screen i have also no problems with audiosync. I'm playing a lot of games and look many demos without any issues. I also play Mods with Protracker and octamed tracker. No issues.

[rsn8887]

@CypherXG: Playing mods is not a good way to check for audio lag. To find lag, look at the delay between action and sound. Audio can sound perfect, but still be laggy.

I am also getting an enormous audio lag (500 ms or more) on the GitHub "master" branch version of Amiberry that is installed by RetroPie. The lag is very noticeable in all games and things like Tinylauncher menu sound. If I move the selection in Tinylauncher, the sound plays almost 1 second later.

[CypherXG]

I'll tried now with buffer from 512kB to 4096kB . No issues. After 8192kB sound is laggy and async. P.S. Tinylauncher is crap. Try better start your game adf files direct with uae4arm or create AmigaOS HDF File and use WHDLoad

[vanfanel]

@midwan : I only use SDL2. There's no SDL1.x on my system,

Also, the audio latency problem is present in both PAL and NTSC chipset emulations.

@CypherXG : Where are you changing the buffer size? In SDL_OpenAudio() you can only pass an struct with the number of samples as a member.

[CypherXG]

I cancel the modify of the Buffer because when i modify that the CDRom Audio runs to fast.

[vanfanel]

@CypherXG: but where do you change It?

[CypherXG]

In Sound.h

define SNDBUFFER_LEN 2048

But when you modify this you become sound problems and Audio CD plays to fast But i don't understand why you have so many Problems. My Pi System is also Retropie. I'm using the SDL1 Version. Except for a few trifles, the emulator runs wonderfully.

[vanfanel]

@CypherXG : As you can see I am not the only one seeing these problems: reporting them is necessary so the emulator gets ready for SDL2, as SDL1 is a dead path. You don't see the same problems because you are using the old SDL1 code. Thanks for the info on the SNDBUFFER_LEN define info!

[CypherXG]

SDL1 is not dead. It runs really better than SDL2. Did yu see the Frames when u are using Picasso Mode? 30 Frames or lower. The Performance lost with SDL2 is to much for the Pi3. I tested a lot of SDL2 Versions and no one of them has the Performance like SDL1 I can say that "my" Version runs really good now. No Audio lags or somthing else. I can run Amitkit without any Problems. The only thing i miss in this Emulator is the AHI Device. When AHI is added you will get more performance.

[midwan]

@CypherXG I believe @vanfanel meant that SDL1 is a dead path because it's no longer developed/supported, and everything is moving towards SDL2 instead (well, everything that's considered "alive" at least).

To that end, the current "dev" branch now has both frameworks integrated (SDL1/SDL2) and you can build the target you want by specifying the appropriate "PLATFORM" as a Makefile parameter.

In SDL1, we have to calculate VSync manually and account for changes between 50/60Hz emulated modes. In SDL2, VSync is handled automatically by the framework and we don't have that 50/60Hz fix implemented. We'd have to disable VSync and manually calculate it there as well, if we want to implement it in the same way. Perhaps this is related to the lag mentioned, if it only shows in SDL2.

Also, the current SDL2 approach is not fully optimized. We're using a Texture that gets updated on each frame, which is fairly slow as a process. We should look into either using a Streaming texture or Render directly to it, to improve the speed - but a few tests I made on that front didn't really work for me, so I left it for later (since we have to fix other more urgent bugs first). It's in the ToDo list for now.

Needless to say, pull requests are welcome if anyone wishes to assist!

[CypherXG]

I know that it takes time to optimize SDL2. same as SDL1. Time will tell. :-)

[midwan]

@vanfanel I've made some speed improvements in SDL2 with the latest commits, could you please test if the audio lag has any difference from before?

In my ears, it sounds almost identical between SDL1 and SDL2 versions... but it's not a very tangible thing to test by clicking and estimating how long it takes to hear it, it may be a few milliseconds more/less.

[CypherXG]

That is that what i said. I use the RetroPie System and i have no Audio Lags etc. I think there is something wrong with the System.

[vanfanel]

@midwan : I have just built the new version and CPU usage seems to be lower indeed, but audio lag seemed to be related to the buffer size, so I simply did SNDBUFFER_LEN=1024 on sound.h, and it's gone :)

[CypherXG]

But when u do this CDDA Audio is too fast. Audio runs in double speed. So, when nobody other had this Problem then there is something wrong with your system.

[vanfanel]

@CypherXG : There's nothing wrong with my system, if that would be the case I wouldn't be able to fix it with a smaller buffer size... Seems simple to me: bigger buffer = bigger latency. It's just natural. All that happens is that I can tell the difference (because I know some Amiga games "by tact") and other people can not.

[rsn8887]

Agreed. Many people somehow just don’t notice the lag. Although it is quite easy to check. Just load up Turrican 2 and jump and listen when you come back down. The sound effect of your feet touching the ground should happen exactly at the same time when you see your character’s feet first touch the ground again. Not a few frames later. This problem is also very noticable on the Android port of UAE4Arm.

I haven’t checked it in a while and never tried the sound.h fix. I suppose you recompiled your own version of the emulator to test that fix?

[vanfanel]

@rsn8887 : Yes, I built my own version. Changing the buffer size is a good "fix". I am very sensible to audio lag and I can't see any delay on Turrican 2 with a buffer size of 1024. Try it and tell me what you see, please. I believe the default buffer size is for Android, where small buffers are not possible since it's a very poor OS regarding video and audio latency.

[midwan]

@vanfanel thanks for the suggestion, I'll try this with a few demos, games etc. and see if it creates any other problems. If it works better than before, we can integrate it.

[midwan]

@CypherXG Which scenario did you test with CDDA audio to check please? When you did that, did you only change SNDBUFFER_LENor did you also change CDAUDIO_BUFFER_LEN with it? I think they should be the same size...

[CypherXG]

I tried both scenario. When u change the SNDBUFFER_LEN you get lower latency. When you change CDAUDIO_BUFFER_LEN the CDDA Audio will begin to crackle, but it run to fast like double speed. I tried to change SNDBUFFER_LEN and find the problem to correct this, but i found nothing to fix this.

[midwan]

@CypherXG Did you test this with a specific game? Or multiple? Could you please give me some examples of titles/software you used?

[CypherXG]

Tested with CD32 Games which are using CDDA Audio and with Workbench 3.9 CDDA Player. You can use also the CD32 Kickrom CDDA Audio menu too. It's all the same

[midwan]

@CypherXG With this push, I found that most games are improved. Even CD32 CDDA tracks seem ok, sometimes you may have to enable Fast Copper to avoid slowdowns however (e.g. in Alien Breed 3D menu music).