I am running a simple c/c++ code on a Raspberry Pi 2 with Raspbian kernel version 4.1.6-v7+ in order to view the thermal images from my new FLIR Lepton camera. I also want to see the actual temperature of the object I am pointing it at, but as the temperature is expressed as relative to the internal temperature of the camera, I need to call a function
lepton_temperature()
which requires
i2c-dev
module to be activated. When I activate it and run the function the program slows down from around 9fps to around two frames per minute. I didn't really modify anything in the provided code, so I don't understand why that is happening. Here's the function:
int lepton_temperature() {
if(!_connected) {
lepton_connect();
}
result = ((LEP_GetSysFpaTemperatureKelvin(&_port, &fpa_temp_kelvin)));
return ( fpa_temp_kelvin);
}
Without i2c-dev turned on the program works normally, but of course then I am getting a zero instead the temperature value. Anyone maybe has an idea on what is going on and how to solve it/make it faster?
It might sound obvious, but your question suggests to me that you overlooked it: use a separate thread for the lepton_temperature call.
Turns out Alex was right, as i2c commands are done by ioctl which is synchronous, using the command after each loaded frame was making the program too slow. I didn't consider it as every pixel value of every frame is calculated according to that temperature, so I was sure that can't possibly be the case. Turns out I was wrong.
Thanks to everyone anyway, sorry for posting a question without checking a pretty obvious solution first!
Related
I'm just trying to make an empty game loop that doesn't lag!
My loop does basically nothing, yet sometimes it lags enough to drop frames (I'm trying to run at 60fps)
I traced the problem to SDL_GL_SwapWindow. I made sure vsync is turned off.
Most of the time SDL_GL_SwapWindow(window); takes <1ms. But sometimes it can take long enough to drop frames. Is this normal? I can't believe my raw C++ empty game loop is sometimes dropping frames!
My code doesn't do anything interesting, I've tried tweaking it quite a bit, but I've seen no improvement. You can see it all here http://pastebin.com/GpLAH8SZ
P.S. I'm on a decent gaming desktop!
I think it is the OS, which may not schedule you 100% of time.
You can change the msdn : process class. But there is going to be intervals where windows does not have resources to keep running your code, and keep running.
I came across FMOD recently, and i have been trying to record a sound from my c++ program using FMOD.
I saw a nice little example given in the FMOD documentation. Its easy to understand, but only records audio for 5 seconds.
How can i use FMOD to record audio which is more than 5 seconds, could be of any custom size passed to the program?
Troubleshooting done so far-
I think i need to do some changes to the FMOD::sound object, but I am not quite sure what.
In the example given by the FMOD,
exinfo.length = exinfo.defaultfrequency * 25 * exinfo.numchannels * 5;
this is one of the parameters passed to Sound object, i tried changing it, but no effect.
Changed the value passed to Sleep function, i reduced the value, and eventually commented that line, that had no effect on the output of the program.
I'd really appreciate any hints given on this. :)
I am creating a user interface using (Qt) and I am attaching it to my C/C++ motion application using shared memory as my form of Inter Process Communication.
I currently have a class which I created in my motion application that has many members. Most of these members are used to update data on the UI and some of them get updated about 20 to 50 times a second, so it is pretty fast (the reason being because it is tracking motion). My problem is that the data is not getting updated on the UI frequently. It gets updated every few seconds. I was able to get it work using other variables made in structures from my application by using "volatile" however it does not seem to be working for members of my class. I know that the problem is not on the UI (Qt) side, because I saw that the actual member data was not being updated in my application, even though I have commands every cycle to update the data.
I was pretty sure the problem is that some optimization is occurring since I do not have my members declared as volatile as in my structures, but when I made them volatile it still did not work. I found that when I through a comment to print out in the function that updates my motion data within my motion application, the UI updates much more frequently as if the command to print out the comment deters the compiler form optimizing out some stuff.
Has anyone experienced this problem or have a possible solution?
Your help is greatly appreciated. Thanks ahead of time!
EDIT:
The interface does not freeze completely. I just updates every few seconds instead of continuously as I intended for it to do. Using various tests I know that the problem is not on the GUI or shared memory side. The problem lies strictly on the motion application side. The function that I am calling is below: int
`motionUpdate(MOTION_STAT * stat)
{
positionUpdate(&stat->traj);
}
`
where
positionUpdate(){stat->Position = motStatus.pos_fb;}
Position is a class member that contains x, y, and z. The function does not seem to update the position values unless I put a printed out comment before positionUpdate(). I don't track the change in shared memory to update the UI, but instead just update the UI every cycle.
Especially Given you are using Qt, I would strongly advise not using "native" shared memory, but to use signals instead. Concurrency using message-passing (signals/slots is one such way) is much, much easier to reason about and debug than trying to share memory.
I would expect your problem with updating is that the UI isn't being called enough of the time, so there is a backlog of updating to do.
Try putting in some code that throws away updates if they happen less than 0.3 seconds apart and see if that helps. You may wish to tune that number but start at the larger end.
Secondly, make sure there aren't any "notspots" in your app, in which the GUI thread is not being given the chance to run. If there are, consider putting code into another thread or, alternatively, calling processEvents() within that part of the code.
If the above really isn't what's happening, I would suggest adding more info about the architecture of your program.
I am starting using FMOD API and I have got problem with sound playing. I've used tutorial from this site: http://glasnost.itcarlow.ie/~powerk/audio/AddFMODtoaproject.html and only think I have got is sound cracking.
This is the code which I am using in my OpenGL init function:
FMOD::System_Create(&system);// create an instance of the game engine
system->init(32, FMOD_INIT_NORMAL, 0);
system->createSound("sound.wav", FMOD_HARDWARE, 0, &sound1);
sound1->setMode(FMOD_LOOP_OFF);
system->playSound(FMOD_CHANNEL_FREE, sound1, false, 0);
Does anyone have any idea what is wrong? Or mayby there is another way for that.
Firstly make sure you check the return code of all functions, ensure it is FMOD_OK.
Second, you need to call System::update regularly, once per frame for FMOD house keeping.
Regarding your issue though, what platform are you on?
Crackling generally means the hardware cannot keep up, to fix it you can increase the amount of buffering FMOD does. This is controlled via System::setDSPBufferSize, try increasing the numBuffers count. You can determine the current values with System::getDSPBufferSize, also make sure you call System::setDSPBufferSize before System::init for the new values to take effect.
I don't know If you are calling FMOD::System::Update() .. you need to call this at least once per frame
The overall program is too complex to display here. Basically, just pay attention to the green highlights in my recent git commit. I am very new to DirectInput, so I expect I've made several errors. I have very carefully studied the MSDN documentation, so I promise I'm not just throwing this out there and stamping FIX IT FOR ME on it. :)
Basically, I think I have narrowed down my problem to the area of code around Engine::getEvent (line 238+). I do not understand how these functions work, and I've messed with certain pieces to achieve different results. My goal here is to simply read in keyboard events directly and output those raw numbers to the screen (I will deal with the numbers' meaning later). The problem here relates to KEYBOARD_BUFFER_SIZE. If I make it small, the program seems to run fine, but it outputs no events. If I make it big, it runs a bit better, but it starts to slow down and then freeze (the OpenGL window just has a rotating color cube). How do I properly capture keyboard events?
I checked the return values on all the setup steps higher in the code. They all return DI_OK just fine.
Your code seems to be okay (according to this tutorial, which I have used in the past). The use of several stack-based arrays is questionable, but shouldn't be too much of an issue (unless you start having lots of concurrent getEvent calls running).
However, your best bet would be to stop using DirectInput and start using Windows Raw Input. It's best to make this switch early (ie, now) rather than realise later on that you really need to use something other than DI to get the results you want.