Re: emit a signal from inside a callback routine

8th December 2009 22:53

Originally Posted by JohannesMunk

All right, I give up :->

So your solution is to just emit the signal through the singleton?

Qt Code:

class AudioDevice : public 
{ Q_OBJECT
  friend FMOD_RESULT F_CALLBACK endCallback(FMOD_CHANNEL *channel, FMOD_CHANNEL_CALLBACKTYPE type, 
                                       unsigned int commanddata1, unsigned int commanddata2);
 
   public:
     static AudioDevice* singleton()
     {
      if (!instance)
        instance = new AudioDevice();
      return instance;
     }
   signals:
     void soundStopped();
 
   protected:
     AudioDevice() {}
 
   private:
     static AudioDevice *instance;
};
 
AudioDevice* AudioDevice::instance = 0;
 
FMOD_RESULT F_CALLBACK endCallback(FMOD_CHANNEL *channel, FMOD_CHANNEL_CALLBACKTYPE type, 
                                       unsigned int commanddata1, unsigned int commanddata2)
{
  ..
  emit AudioDevice::singleton()->soundStopped();
  ..
}

class AudioDevice : public QObject
{ Q_OBJECT
  friend FMOD_RESULT F_CALLBACK endCallback(FMOD_CHANNEL *channel, FMOD_CHANNEL_CALLBACKTYPE type, 
                                       unsigned int commanddata1, unsigned int commanddata2);

   public:
     static AudioDevice* singleton()
     {
      if (!instance)
        instance = new AudioDevice();
      return instance;
     }
   signals:
     void soundStopped();

   protected:
     AudioDevice() {}

   private:
     static AudioDevice *instance;
};

AudioDevice* AudioDevice::instance = 0;

FMOD_RESULT F_CALLBACK endCallback(FMOD_CHANNEL *channel, FMOD_CHANNEL_CALLBACKTYPE type, 
                                       unsigned int commanddata1, unsigned int commanddata2)
{
  ..
  emit AudioDevice::singleton()->soundStopped();
  ..
}

To copy to clipboard, switch view to plain text mode

HIH

Johannes

Hi I didn't well understand the difference between your last code and the code you suggested to me before.
Can you explain to me?
Best Regards

8th December 2009 23:05

Sure!

The only difference is how we get a pointer to our audiodevice from inside the callback.

The first approach used the callbacks commanddata to get a reference to the audiodevice. That would allow for several audiodevices to exist simultaneously in your application.

Then we found out, that you can't set the commanddata for that purpose.

Then you said, that you have only one (singleton) audiodevice. That means that we can easily access this single (global) audiodevice.. to emit the signal from everywhere we want. In the way I have shown to you (friends + singleton access)

And once the signal gets emitted correctly the common signal slot mechanism - which I didn't show how to setup - will assure that your currentsound will "get the message"!

Let me know if I was talking sense now :->

Johannes

9th December 2009 01:46

Originally Posted by JohannesMunk

Sure!

The only difference is how we get a pointer to our audiodevice from inside the callback.

The first approach used the callbacks commanddata to get a reference to the audiodevice. That would allow for several audiodevices to exist simultaneously in your application.

Then we found out, that you can't set the commanddata for that purpose.

Then you said, that you have only one (singleton) audiodevice. That means that we can easily access this single (global) audiodevice.. to emit the signal from everywhere we want. In the way I have shown to you (friends + singleton access)

And once the signal gets emitted correctly the common signal slot mechanism - which I didn't show how to setup - will assure that your currentsound will "get the message"!

Let me know if I was talking sense now :->

Johannes

Yes sure. Thank you very much your explanation was clear.
A question. I would connect with the signal/slot mechanism 2 objects ( audiodevice + another one ). The problem is that eather one is part of the other.
AudioDevice has not an instance of the OtherObject and the OtherObject has not an instance of the AudioDevice.
The 2 objects are indipendent.

I hpe you can help me.

Best Regards,
Franco

9th December 2009 02:00

That's perfectly fine for signals and slots:

Qt Code:

Switch view

AudioDevice* ad = new AudioDevice();
...
SoundData* sd = new SoundData();
...
::connect(ad,SIGNAL(soundStopped()),sd,SLOT(someSLOT()));

AudioDevice* ad = new AudioDevice();
...
SoundData* sd = new SoundData();
...
QObject::connect(ad,SIGNAL(soundStopped()),sd,SLOT(someSLOT()));

To copy to clipboard, switch view to plain text mode

or using the singleton approach to get the AudioDevice:

Qt Code:

Switch view

SoundData* sd = new SoundData();
...
 ::connect(AudioDevice::singleton(),SIGNAL(soundStopped()),sd,SLOT(someSLOT()));

SoundData* sd = new SoundData();
...
 QObject::connect(AudioDevice::singleton(),SIGNAL(soundStopped()),sd,SLOT(someSLOT()));

To copy to clipboard, switch view to plain text mode

For signals and slots to work both classes have to inherit someway along the line from QObject and include the Q_OBJECT macro..

They don't have to know anything from each other. Thats the beauty of signals!

HIH

Johannes

9th December 2009 16:31

Originally Posted by JohannesMunk

That's perfectly fine for signals and slots:

Qt Code:

Switch view

AudioDevice* ad = new AudioDevice();
...
SoundData* sd = new SoundData();
...
::connect(ad,SIGNAL(soundStopped()),sd,SLOT(someSLOT()));

AudioDevice* ad = new AudioDevice();
...
SoundData* sd = new SoundData();
...
QObject::connect(ad,SIGNAL(soundStopped()),sd,SLOT(someSLOT()));

To copy to clipboard, switch view to plain text mode

or using the singleton approach to get the AudioDevice:

Qt Code:

Switch view

SoundData* sd = new SoundData();
...
 ::connect(AudioDevice::singleton(),SIGNAL(soundStopped()),sd,SLOT(someSLOT()));

SoundData* sd = new SoundData();
...
 QObject::connect(AudioDevice::singleton(),SIGNAL(soundStopped()),sd,SLOT(someSLOT()));

To copy to clipboard, switch view to plain text mode

For signals and slots to work both classes have to inherit someway along the line from QObject and include the Q_OBJECT macro..

They don't have to know anything from each other. Thats the beauty of signals!

HIH

Johannes

It's fantastic. I love Qt.
In which part of the code I have to write the QObject::connect?
In that case ( a signal emitted by a callback ) I have to specify the Queued connections flag right?

Best

9th December 2009 16:50

Originally Posted by franco.amato

In which part of the code I have to write the QObject::connect?

Any. I suggest where you create the sounddata. If your sounddata is more generic than just data being played back, I suggest to set it up when you prepare it for playback. But then you will have to remove the connection after playback ended, to avoid multiple connections, when you play it back again. I don't know enough about the layout of your program to help you here..

BTW: As the connect function is a static function of the QObject class, you only need to write "QObject::" in front of connect, if you are outside a QObject class.. Inside you can just write "connect(..)". But I showed you QObject::connect .. to underline that you can call this from everywhere.

Originally Posted by franco.amato

In that case ( a signal emitted by a callback ) I have to specify the Queued connections flag right?

That depends on your callback library. Some execute the callback within the thread context of your application (synchronized) and some don't (async). Perhaps you can specify that when you set the callback. When the callback is already synchronized it doesn't make a lot of sense to go through qt's message system again (=>direct connection). Unless the callback needs to return very quickly and you want to do something big in your connected slot. If the callback is called asynchronously (in the threadcontext of the libraray) and you want to access GUI elements or something else that is not thread safe, you have to go for the Queued connection.

Just try both options.. and see what works for you.. Or specify nothing and let qt decide. Qt decides upon matching thread contexts. Which should work just fine here.

Cheers!

Johannes

9th December 2009 19:53

Originally Posted by JohannesMunk

Any. I suggest where you create the sounddata. If your sounddata is more generic than just data being played back, I suggest to set it up when you prepare it for playback. But then you will have to remove the connection after playback ended, to avoid multiple connections, when you play it back again. I don't know enough about the layout of your program to help you here..

BTW: As the connect function is a static function of the QObject class, you only need to write "QObject::" in front of connect, if you are outside a QObject class.. Inside you can just write "connect(..)". But I showed you QObject::connect .. to underline that you can call this from everywhere.

That depends on your callback library. Some execute the callback within the thread context of your application (synchronized) and some don't (async). Perhaps you can specify that when you set the callback. When the callback is already synchronized it doesn't make a lot of sense to go through qt's message system again (=>direct connection). Unless the callback needs to return very quickly and you want to do something big in your connected slot. If the callback is called asynchronously (in the threadcontext of the libraray) and you want to access GUI elements or something else that is not thread safe, you have to go for the Queued connection.

Just try both options.. and see what works for you.. Or specify nothing and let qt decide. Qt decides upon matching thread contexts. Which should work just fine here.

Cheers!

Johannes

The callback is executed when a playing file finish to play.
In this case I have to stop a QTimer that I use to determine the "pcm position" within the
audio data ( this to move a timeline ). So I think is not necesary to remove the connection. Because if a file is not playing the callback is never called. ( how I remove a callback?? ).

I don't exactly know if the callback is sync or async, I have to ask to the fmod community for that.
If is async I have to use the Queued connections flag right?

Thank you

9th December 2009 21:46

You didn't get me.

If you set up the signal slot connection whenever you START playing the sounddata on an Audiodevice there will be multiple signal-slot-connections, if you play the same sound multiple times and you don't remove the connection with QObject::disconnect after play back stopped.

If you set it up only once when you create the sound everything is fine.

Callback: No need to ask. Just try what works. You can't break anything.

Good luck with your project!

Johannes

9th December 2009 23:43

Originally Posted by JohannesMunk

You didn't get me.

If you set up the signal slot connection whenever you START playing the sounddata on an Audiodevice there will be multiple signal-slot-connections, if you play the same sound multiple times and you don't remove the connection with QObject::disconnect after play back stopped.

If you set it up only once when you create the sound everything is fine.

Callback: No need to ask. Just try what works. You can't break anything.

Good luck with your project!

Johannes

Thank you very much Johannes for your precious help.

Best Regards

9th December 2009 23:51

You are welcome!