![]() ![]() Maybe a triple buffered vsync? Hard sync is great since it lowers input lag to a level below proper mednafen, but I’d be happy if I could get at the same level without killing performance. I’m curious if there are any less intensive sync methods that could be implemented that would still reduce lag. Just dispatching GL calls doesn’t take much. Non-hard sync doesn’t block, so emulation can take close to 16ms. With hard sync, you have a frame timing like:Įmulate Game -> Dispatch GL calls -> Swap -> Wait till GPU has finished, so both emulation and rendering has to happen sequentially within 16ms (very demanding especially if you’re using shaders). It's in milliseconds and is normally 64 by default, but might need to be bumped higher for the Raspberry Pi.Ye, hard sync is demanding. If the issue is the audio buffer being too small, you can increase it by setting the "audio_latency" value in retroarch.cfg (by default at ~/.retroarch.cfg). Now the underrun is likely unavoidable if CPU is >100%.īut it's also possible it is using too small an audio buffer or somehow making the underrun more likely. I suspect that alsathread is continually getting EPIPE (due to underrun) and calling snd_pcm_recover. I'll need to look through the changes and see which one fixes it. Interestingly I've got some local mods to the firmware, and that doesn't hang. Yes, I've seen the hang with current firmware. The sound isn't perfect - there is some static but at least it works. 09b25ada12 and sound works so the latest firmware is definitely the culprit. There are problems with the sound as stated in the wiki: Kalehrl wrote:I believe retroarch uses alsathread for sound: I also put a usleep in to reduce cpu usage below 70% but there was no difference to the sound. ![]() Update noticed that with the new kernel ALSA period size is 2048, whereas on previous working kernels the period size is 736 which is what I would expect (frame size 44100khz/60fps), it matches the "samples per frame" based on latency of 1/60 of a second passed to snd_pcm_set_params. sound.cpp Run "./mame -log " to produce an error.log showing underruns, buffer/frame sizes. My source for the ALSA sound code is also here. ll_pi.zip) and I'll supply you with ROMS to test with. If you want, install MAME4ALL from the Pi Store (or manually here. My sound code is based on RetroArch but uses quite different ALSA initialisation and buffer settings. My MAME4ALL had pretty much perfect audio (analogue & HDMI) with -wheezy-raspbian or earlier. I don't use it with Movies as I want to maintain the dynamic range but for TV it's nice not to have the adverts blaring much louder than the programme.Īnother option would be a limiter (dropping the gain rather than a hard cutoff) to prevent certain things like iPlayer from being much louder than everything else.ĭom, I've just updated to the latest firmware version and the sound is very broken with ALSA - bad static, very quiet. Maybe something similar could be done on the RPi? ![]() Whilst it's running, I can watch it dynamically adjust the amplification. I don't know how it works but it seems to do a good job with LiveTV. I use ffdshow on my PC with Mediaportal and have it set to Normalise with Max Amplification 200%. Well the Downmix option is working today, so it's not too bad and I can hear the movies OK now You obviously can't normalise every packet of audio, or it would be impossible to represent deliberately quiet sounds, and the discontinuities between packets would be jarring. It's easy to increase the gain during a quiet bit, and then have the audio blaring (and likely clipping/distorting) when the quiet bit finishes. You really need to analyse the whole file to do that. Doveman wrote:I wonder if there's any way to make XBMC/RPi normalise everything else then, so that I don't have to crank up the volume on my TV/Amp for it and then risk getting deafened when using iPlayer or another piece of equipment? ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |