I'm trying to get events from a sensor in windows with the "SetEventSink" function of ISensor, (c++). but I get no events! (i have the sensor and i can get data from it with the "GetData" function of ISensor).
I followed the instructions here http://msdn.microsoft.com/en-us/library/windows/desktop/dd319014(v=vs.85).aspx
Any idea?
Thanks!
I know this is an old question but... when you call CoInitialize to initialize COM, you have to call the CoInitializeEx version instead and pass in the multi-threaded flag. This will allow you to receive asynchronous events from the sensors.
CoInitializeEx(COINIT_MULTITHREADED);
Related
I'm planning to write a small program that connects to the Jack Audio Kit on Linux. Whenever there's a new audio available to my program, Jack will call the registered callback. According to the documentation, the callback function should enable "real-time execution".
However, I'd like my program to do some analysis over the data flowing through and displaying this in a window. This is inherently not real-time.
To circumvent this issue, in an exploratory Python script, I used a queue to transfer data into another thread. But although the callback is called, the thread doesn't receive anything. I suspect this is due to the callback being called in another process. The debugger also doesn't stop inside the callback.
I saw, there are several applications for Jack that do other non-real-time things like UI and thelike (e.g., volume meter in Cadence). How is it possible to implement this callback without losing the real-time execution property?
I worked on the synchronous libusb in my Qt project with good results and now I need the asynchronous features of this library. I understood reading here, here and here that, after I've registered my callback function using the libusb_fill_control_transfer and submitted a transfer with libusb_submit_transfer , I need to "keep live" the libusb_handle_events_completed inside a while loop to get the transfer related events since the libusb doesn't have its own thread. for example you can read a code like this
libusb_fill_control_transfer(transfer, dev, buffer, cb, &completed, 1000);
libusb_submit_transfer(transfer);
while (!completed) {
libusb_handle_events_completed(ctx, &completed);
}
Now if I want read a packet that I don't know when it occurs, I think that goes against the asynchronous nature submit a read and wait in the while with libusb_handle_events_completed until the event is triggered.
Then, do I need to create a separate thread within the libusb_handle_events_completed in an infinite while loop?
Can anyone, with experience in the asynchronous features of libusb library, give some suggestions on the right approach to handle the transfer events?
I'm new to sound programming and ALSA. I'd like to create a little application, that for example prints out to the console when a frame of data is written to ALSA with snd_pcm_writei(...). Is that possible and if so, how?
Currently I'm thinking of registering a callback to ALSA so when an application calls snd_pcm_writei(...) the callback is executed. But I'm not sure that is how it works.
You can either use
blocking mode (the default), in which snd_pcm_write*() returns only when all the data has been written into the ring buffer (or when an error has occured), or
non-blocking mode (enabled with SND_PCM_NONBLOCK when opening, or snd_pcm_nonblock()), in which you can use poll()/epoll() etc. to get a notification.
Using an ALSA async handler works only with certain devices, and has all the drawbacks of signal handlers; it is deprecated.
I am trying to make use of Borlands TClientSocket component in non-blocking mode inside a multithreaded C++ Windows application. I am creating multiple threads (classes derived from TThread), each of which creates its own TClientSocket object. I then assign member functions of the thread class to act as event handlers for the OnConnect, OnDisconnect and OnSocketError events of the socket. The problem I am having here is that whenever I call the TClientSocket::Open() function from within the TThread::Execute() function, the OnConnect event never fires. However, When I call the Open() function from the VCL thread prior to the TThread::Execute() function getting called, all of the events fire and I can use the thread-socket combination as I would like. Now I have not read anything in documentation that says that TClientSocket should not be used in non-blocking mode when used inside a thread, but it appears to me that there is perhaps something wrong conceptually in the way I am trying to use this class. Borland documentation is quite poor on the subject and these components have now been deprecated so reliable information is hard to come by. Despite being deprecated I have to use them as there is no alternative in the Builder 6 package I have. Can anyone please advise me if there is a right/wrong way to use TThread and a non-blocking TClientSocket in combination. I have never had problems using it as part of the VCL thread and never had problems using TServerSocket before and I really cannot understand why some events are not firing.
TClientSocket in non-blocking mode uses a hidden window internally to receive socket events. If you use a non-blocking TClientSocket in a TThread then you must implement a message loop inside of your TThread::Execute() method in order to dispatch those messages to the socket's window. Also, being window-based, that also means that the socket messages are sent to the thread that actually creates the socket window, so you have to make sure you are opening the TClientSocket from inside of your TThread::Execute() method.
BTW, BCB6 shipped with Indy 8, which is an alternative. You can also install an up-to-date version of Indy, or even another third-party library like ICS or Synapse.
I'm trying to write a Bluetooth server as a MFC app and while I got it working as a console app with blocking sockets, I can't get it working using CAsyncSocket.
The error it returns is 10035 - WSAEWOULDBLOCK as soon as I call Accept()
I could copy the code, but it's way too long, so I'll just outline the general idea:
- create, bind regular socket and start listening just like in the Microsoft SDK example app
- attach this socket to CAsyncSocket
- call Accept() (this is where the error occurs)
Any ideas how to get Bluetooth working with CAsyncSocket?
CAsyncSocket's OnAccept member function is called when you can Accept. Subclass CAsyncSocket and handle the OnAccept notification.
Thanks, I've corrected that, but OnAccept, OnConnect(), etc. were never executed, not even when called directly. It turned out that I had to delete all the temporary files the compiler and linker use to find out that I was using global shorthand function log() which clashed with log() defined in math.h and which caused some weird behavior.
See this thread for more datails http://www.codeguru.com/forum/showthread.php?t=339413
UPDATE: now you can download the finished app and the whole source code on Brm Bluetooth Remote Control homepage!