garbear speaks
The XBMC emulator core i wrote is called RetroPlayer, an event-based multithreaded core inspired by xbmc's DVDPlayer. It's a proof of concept, but the general framework is modular enough to build it piece-by-piece into a working full-featured emulator.
I've been waiting for something like libretro for a few years, a common emulator api is an idea too good not to happen. I hope that exposing the API to xbmc's millions of users brings the api enough attention and developers to make RetroArch and its backends more badass than they already are.
(2012-12-08, 10:11)squarepusher Wrote: RGB565 support for textures might not be available in XBMC - it is generally assumed by now that the libretro frontend supports either XRGB8888 (for 32bit color mode) or RGB565 (for 16bit color mode). A libretro port can choose either RGB565, XRGB8888 or RGB1555 as its preferred color format (the latter is deprecated though and will mostly always lead to color conversion, so it's discouraged to use this as anything other than a last resort). Catering to all of them is usually not done - if the preferred format 'fails' (ie. RGB565 or XRGB8888), then it would resort to RGB1555 - and you'd have to convert colors in your libretro frontend.
XBMC expects textures in PIX_FMT_YUV420P form. A conversion is necessary anyways, so I pass the texture data to swscale unmodified and flag the data as either PIX_FMT_ARGB or PIX_FMT_RGB555LE. RGB565 was added after september (when my classes started up again), but I assume supporting it is as simple as finding the right swscale flag.
Quote:As for audio delay - it smacks of A/V sync issues. Our input/audio/video drivers are optimized for games/emus - your drivers are probably optimized with movies in mind. We ran into similar issues when we tried to port FFmpeg/mplayer to libretro - we found that our frontend drivers were not really suitable for movies and were too game-specific - the reverse might be the case here. I guess what you could try in the interim is to fiddle around with audio/video latency - if that doesn't work you might have to look into making XBMC's video/audio drivers more suitable for realtime usecases.
Other things that could contribute to audio delay/latency on the audio front could be the audio resampler, float to int/integer to float conversion, and the like. Maister is pretty good at audio and has written Altivec/SSE/NEON-optimized resamplers and audio conversion routines.
XBMC has a new AudioEngine written for bit-perfect reproduction, not low latency. It can be modified (in theory) for low-latency mode without touching much RetroPlayer code.
I see a low-latency mode as just another self-contained step to be engineered before we have a working emulator.
