Menu
▾
▴
#583 Black screen on ROM load with sound enabled (framebuffer)
Hello,
My system is as follows:
Raspberry Pi Model B Rev 1 (256MB)
Raspbian Wheezy
Running from framebuffer outside of X (x is never even launched).
SDL is latest version, customized to use dispmanx backend
(Note: I've also tried with the non-customized version of SDL, and get the same results).
FCEUX is the latest version from SVN, compiled with no GTK support, no lua support, no OpenGL support, no SDL AVI support, etc.... Basically it is compiled with only the bare minimum supported.
When I launch fceux with a ROM, I get a static blank screen, no sound, no video, but not unresponsive (I can exit back to shell by pressing f1).
If I disable sound by passing -sound 0, it launches just fine, and plays the game just fine (sans sound, obviously).
I don't have pulseaudio installed, I use bare alsa.
I installed the alsa-oss emulation utility, and tried running it with
SDL_AUDIODRIVER=oss aoss fceux romfile
and
SDL_AUDIODRIVER=dsp aoss fceux romfile
I also modprobed snd-pcm-oss and just launched with
SDL_AUDIODRIVER=dsp fceux romfile
And I still get the same result: black screen, no audio, but exits just fine on f1.
It seems I can only get it to load a rom with sound completely disabled altogether. If it successfully loads an audio driver, it will hang on a black screen every time, without fail.
I forgot to note that I also disabled the new PPU at compile time.
Thank you for bringing this to our attention. I have not yet testing running fceux within a framebuffer outside of X11. Have you tried "SDL_AUDIODRIVER=alsa fceux romfile"?
Sorry for the delay on this, but yes, I did try that.
As I said, it seems that regardless of the driver used, it freezes on a black screen if it successfully opens an audio device. If run with sound 0, or if it does not succeed in opening an audio device, it plays flawlessly.
What I mean by successfully opening an audio device is as follows:
At one point, I tried to open it with the oss driver, but I forgot to modprobe the OSS emulation module first. It started up fine, and I got excited, but then I noticed there was still no sound... when I exited out, I saw on the command line that it failed to open the sound device. I then modprobed the OSS emulation module, tried it again, and I got the same frozen black screen.
It seems to be independent of which driver is used; if it successfully opens an audio device, it hangs with a black screen.
I will do some more testing with different sound qualities/frequencies, and see if it has any baring on the situation, and then report back here.
One thing that is very possible is that it's an issue with the raspberry pi itself... They are known to have buggy sound implementation. Although I will say that it runs DGEN (genesis emulator for SDL) just fine with ALSA drivers, Osmose (SMS emulator for SDL) with ALSA drivers just fine, SNES9X 1.53 with ALSA drivers just fine (although with poor performance), and SNES9X 1.39 with OSS drivers just fine (with good performance). This is the first issue I've personally had on this platform with sound, but as I said, I know that other people have had difficulty with sound on the RPi (although mostly with pulseaudio... which I have removed).
I may also try to recompile it with the new PPU and see if that makes any difference... I disabled it at compile time because I read that it was more demanding than the old implementation, and as the RPi is a rather weak machine, I figured I would skip it altogether, but I guess it can't hurt to give it a try! (Although I guess it shouldn't have any baring on sound...)
Thank you ahead of time for your help.
Last edit: Mike M 2013-03-01
Here's an update:
Triet it with soundq 0: No sound, but plays fine (is soundq 0 equivalent to sound 0?)
Tried it with soundq 1: Black screen
Tried it with soundq 2: Black screen
Frequency at 44100: black screen
Frequency at 48000: black screen
Frequency at 22050: black screen
oss/dsp/dma: Black screen
alsa: Black screen
etc...
Basically any attempt at using sound makes it freeze at the black screen. I saw some similar complaints on ubuntu's bug tracker, and their solution was to use esd/pulseaudio... Unfortunately, I completely removed pulseaudio because it doesn't play nicely with a lot of my other software, so I can't test that solution at the moment (although I will probably give it a whirl at some point) :-(
Also, just for testing purposes, I went back and tried 0.98.13-pre, and I'm getting the same exact issue with that old version. Whatever the problem is, it seems to be persistent going all the way back that far.
Update:
I've figured it out... -soundq 0 does the trick. I thought it didn't, but I wasn't testing thoroughly enough. As long as I set soundq 0, sound works fine using the alsa driver.
I have a new issue, though, but I don't want to derail this too much. I'll post it here, and if you don't feel like answering it here, feel free to close this as solved:
I used the --input1 gamepad --inputcfg gamepad1 switches to configure my joystick. The issue is, running it from the framebuffer wouldn't work (since there is no window titlebar). What I did was launch into an X session, start fceux from there, and configure the joystick from there. All went well, so I exited and checked the fceux.cfg file, and sure enough, the settings stuck!
So now, I restarted the computer, and launched from the framebuffer, but now the joystick doesn't work, and neither does the keyboard... The keyboard at least was working fine before, but now neither work...
Is the joystick code somehow reliant on X? I took a quick gander at the code, and it looked like it all relied on standard sdl-joystick code... I have never had issues using SDL-joystick programs before, with no need for X. Is there something I'm missing here?
Thanks ahead of time.
Mike
It's pretty strange that -soundq 0 solved your issue. I tried running fceux (and any SDL applications) in framebuffer mode on my boxen but I wasn't able to get SDL running in framebuffer mode for anything.
In regards to your '--inputcfg' issues, if SDL handles keyboard input without an active X11 window than I see no reason not to add a command-line '--inputcfg' mechanism. This could be added to the TODO list.
The joystick code should be completely independent from X11 AFAIK. Fceux uses SDL completely for joystick input, and SDL (AFAIK) uses the linux joystick driver which is not dependent on X11 (again, AFAIK).
I would love to be able to reproduce this issue so I can be more assistance here, but I'm currently not able to run any SDL applications in framebuffer mode on my boxen. What is this "dispmanx" that you were referring to in your OP?
In regards to SDL applications from framebuffer, it depends on how SDL was installed. If you installed an SDL package under a Debian based system, directly from apt-get, aptitude, or Synaptic Package Manager, then it is binded to X11.
However, if you compile libsdl-dev from source, you can enable a variety of different video modes at configure time, i.e.:
./configure --enable-video-fbcon --enable-video-directfb --enable-video-x11
etc...
The version of SDL I am using is customized to use a "dispmanx" backend, which is advantageous for the raspberry pi as it is a very weak platform. Dispmanx stretches the "window" to fit full screen, without rendering at full screen, and without using demanding scalers like hqx or scale2x etc... The video is rendered at a low resolution, and then dispmanx stretches the overlay to fit full screen. It's excellent.
In regards to the --inputcfg issue, yes, SDL handles keyboard and joystick events just fine from outside of an X session, provided it was compiled as I described above.
Anyway, if you'd like to get SDL working from a framebuffer, and you don't want to tinker with a "third-party" SDL installation, I would recommend enabling directfb or fbcon, depending on what frame buffer driver is available to your system.
Dispmanx is available on raspberry pi's, but I'm not sure of any other systems which include it, so you might not even be able to test it easily. I would stick with directfb or fbcon, depending on which is available for your system.
As far as the soundq issue goes, I'm not sure what the technical difference between --soundq 0 and --soundq 1 is, but as I said before, the raspberry pi has a notoriously finicky sound device, and is an extremely low power device. It could very well be that --soundq 1 is just too much for it to handle (too many channels? too high/low of a buffer? too high a frequency? I dunno...).
Edit:
Just looked into it and it appears that "dispmanx" is a firmware library specific to the videocore chipset such as the one present in the raspberry pi. So yeah, you probably aren't going to want to go that route!
Last edit: Mike M 2013-03-07
One more thing worth noting... the guy who coded the SDL customization for Dispmanx, also included customization for KMS (Kernel Mode Setting). If Kernel Mode Setting is available to your system and your video card drivers, then KMS might be the method to go with. Here is his github account if you are interested:
https://github.com/vanfanel/SDL12-kms-dispmanx
If not, fbcon is probably the way you'll want to go.
Also note that the configure script he provided (MAC_ConfigureKMS.sh) disables other video (and sound) modes that you might not want disabled. You might want to edit that script and change some of those "disable"s to "enable"s.
Last edit: Mike M 2013-03-07
Sorry for thsi triple post... but finally, there is a specific order that SDL will try to open video drivers in, and x11 is the first... so if you compile it with x11 and one (or more) framebuffer driver(s), and it still doesn't let you launch, try to launch with:
SDL_VIDEODRIVER=drivername /path/to/fceux rom.nes
Full list of drivers available (assuming you compiled with them enabled) is here:
http://www.libsdl.org/docs/html/sdlenvvars.html
If you used that custom kms driver I spoke of before, it's probably
SDL_VIDEODRIVER=kms
if I had to guess. If you just want to use fbcon, it's SDL_VIDEODRIVER=fbcon