leadedge
Hi everybody,
there have been some problems with the OpenGL implementation of the VDJSpoutReceiver plugin, so the whole thing has been re-written using DirectX instead.
No boring details but the update receiver dll is available here :
https://github.com/leadedge/Spout2/blob/master/VIRTUALDJ/Binaries/VDJSpoutReceiver.dll
RH click "Raw" and Save As.
This version has been put through hell by Don Houde in preparation for his upcoming NYE event and it is rock steady as far as we can tell.
But there is a catch though.
You can't use the plugin as an audio-only visualisation if you are also using visualisations at the same time on both decks 1 and 2. If you do, the moment you disable one of the visualisations on either of the other decks, the plugin will die.
I have spent much time and effort trying to solve this but I regret that it is not a simple matter and I don't have enough information to resolve it, and anyway I have run out of time to spend on it. So as long as you avoid this situation, all will be well.
My recommendation is to avoid using the plugin with audio-only mode unless you absolutely have to.
Cheers to all,
Lynn Jarvis
there have been some problems with the OpenGL implementation of the VDJSpoutReceiver plugin, so the whole thing has been re-written using DirectX instead.
No boring details but the update receiver dll is available here :
https://github.com/leadedge/Spout2/blob/master/VIRTUALDJ/Binaries/VDJSpoutReceiver.dll
RH click "Raw" and Save As.
This version has been put through hell by Don Houde in preparation for his upcoming NYE event and it is rock steady as far as we can tell.
But there is a catch though.
You can't use the plugin as an audio-only visualisation if you are also using visualisations at the same time on both decks 1 and 2. If you do, the moment you disable one of the visualisations on either of the other decks, the plugin will die.
I have spent much time and effort trying to solve this but I regret that it is not a simple matter and I don't have enough information to resolve it, and anyway I have run out of time to spend on it. So as long as you avoid this situation, all will be well.
My recommendation is to avoid using the plugin with audio-only mode unless you absolutely have to.
Cheers to all,
Lynn Jarvis
Posted Sun 06 Dec 15 @ 1:20 pm
DHoude
Very solid and well done, thank you for the hard work!
As far as AOV, I really wish that there was a way for this AOV situation to be addressed. I understand it is not that simple and have seen all the threads about this. I may not comment, but I am well read on the topic. Powers that be at Atomix, please have a look. This is the second video plugin of this type to have AOV problems. I am no programmer and can't even begin to describe what causes this or how to approach it, but please help us. We can only be better than the other guys when we all work together.
I can't even begin to describe the hammering on this over the course of days that I had to do because of the strange instabilities seen with AOV. With all respect, these video plugins and flexibility are why I am still here. They really add major value to your product and are very important to our video performance.
As far as AOV, I really wish that there was a way for this AOV situation to be addressed. I understand it is not that simple and have seen all the threads about this. I may not comment, but I am well read on the topic. Powers that be at Atomix, please have a look. This is the second video plugin of this type to have AOV problems. I am no programmer and can't even begin to describe what causes this or how to approach it, but please help us. We can only be better than the other guys when we all work together.
I can't even begin to describe the hammering on this over the course of days that I had to do because of the strange instabilities seen with AOV. With all respect, these video plugins and flexibility are why I am still here. They really add major value to your product and are very important to our video performance.
Posted Sun 06 Dec 15 @ 7:41 pm
SBDJ
leadedge wrote :
You can't use the plugin as an audio-only visualisation if you are also using visualisations at the same time on both decks 1 and 2. If you do, the moment you disable one of the visualisations on either of the other decks, the plugin will die.
This doesn't make any sense to me.
If Spout is the AOV, and you have a visualisation effect on Deck 1 and another on Deck 2 then the AOV isn't required, so will be inactive. If you then deactivate one of those, the AOV will be initialised and in use.
I've just tested this and it works exactly as expected:
* Set Spout as AOV, activate video, Spout is active on master output.
* Activate visualisation on deck 1, Spout shifts to deck 2
* Activate visualisation on deck 2, Spout deactivates as it is no longer required
* Deactive visualisation on deck 1 (or 2) and Spout is reactivated on that deck
Posted Sun 06 Dec 15 @ 9:16 pm
leadedge
OK I will give it another go. I have been switching between drives and operating systems so that could isolate it.
The error is D3DERR_OUTOFVIDEOMEMORY when it tries to create a texture from a share handle. I set up D3D9Ex and a texture shadowing the VDJ one and copy a shared one to the shadow one and then to VDJ. Not all that efficient but I can't think of any other way. I release all the various things in the destructor so it should come back the same.
The error is D3DERR_OUTOFVIDEOMEMORY when it tries to create a texture from a share handle. I set up D3D9Ex and a texture shadowing the VDJ one and copy a shared one to the shadow one and then to VDJ. Not all that efficient but I can't think of any other way. I release all the various things in the destructor so it should come back the same.
Posted Sun 06 Dec 15 @ 11:28 pm
SBDJ
Since you're creating from a share handle I assume that means the error is coming from your Ex device rather than our device?
Posted Mon 07 Dec 15 @ 3:40 am
leadedge
Yes that's right. I am checking for null devices throughout. I don't think that's it.
I think it is a leak in the surface creation/release but only in some circumstances, not sure what yet. It has not shown any leak from Don's testing for many hours and I can't detect any memory usage increase.
But I have a repeatable setup now to track this down. There is a difference between 64bit and 32bit operating system and I have it failing on 32bit but working on 64bit, so I want to get it to fail on 64bit and work on 32bit to find where this is coming from.
I think it is a leak in the surface creation/release but only in some circumstances, not sure what yet. It has not shown any leak from Don's testing for many hours and I can't detect any memory usage increase.
But I have a repeatable setup now to track this down. There is a difference between 64bit and 32bit operating system and I have it failing on 32bit but working on 64bit, so I want to get it to fail on 64bit and work on 32bit to find where this is coming from.
Posted Mon 07 Dec 15 @ 3:54 am
SBDJ
Let me know if there's anything you need from our end.
Posted Mon 07 Dec 15 @ 3:55 am
leadedge
OK, let's see if I have this worked out.
Audio-only visualisation alone is not the actual problem with VDJSpoutReceiver, it only appears that way.
The problem was that release of a texture surface was not happening because in the depths of the draw function, one surface was assigned to another and when that was released the original was left in limbo and could not be subsequently released.
BUT - it appears that release of surfaces can be completely ignored with a 64bit system. Any surfaces created in the draw function are apparently released when the function is finished, so this leak only showed up on a 32 bit system. That's why Scott found that it works as expected and Don Houde never found any problems.
The problem only shows up if the plugin is unloaded and re-loaded. With cursory testing this does not happen. If the VDJSpoutReceiver plugin is selected, activated and deactivated, the plugin is not unloaded but remains in memory. It is only unloaded if another visualisation is selected after it has been de-activated. Or, if there are several visualisations selected and active, when one of them is deactivated.
The trick with audio-only is that the plugin is started and not stopped until two other visualisations are selected on both left and right decks. Then the VDJSpoutReceiver plugin is stopped and unloaded and, when one of them is de-activated, VDJSpoutReceiver is started again and boom - but only on a 32bit system.
Anyway, assuming that this has resolved the problem, I have uploaded corrected copy to GitHub.
https://github.com/leadedge/Spout2/tree/master/VIRTUALDJ
The only other difficulty I had was selecting another sender in audio-only mode. Normally you can activate the effect GUI and click the "Sender" button, but there is no such access in audio-only mode.
But I find that it might be possible with the Master effect list. At first there is no entry, but if the list is opened you can see VDJSpoutReceiver down the bottom and it is green for being selected. So I assume that a single audio-only visualisation is by default the master effect.
Now if you hover the cursor over VDJSpoutReceiver and hit the little cog wheel, it is then selected as the master effect and the GUI appears at right for the master. Which is just fine because a different sender can be selected. If that is the way it should work then all should be good to go.
Audio-only visualisation alone is not the actual problem with VDJSpoutReceiver, it only appears that way.
The problem was that release of a texture surface was not happening because in the depths of the draw function, one surface was assigned to another and when that was released the original was left in limbo and could not be subsequently released.
BUT - it appears that release of surfaces can be completely ignored with a 64bit system. Any surfaces created in the draw function are apparently released when the function is finished, so this leak only showed up on a 32 bit system. That's why Scott found that it works as expected and Don Houde never found any problems.
The problem only shows up if the plugin is unloaded and re-loaded. With cursory testing this does not happen. If the VDJSpoutReceiver plugin is selected, activated and deactivated, the plugin is not unloaded but remains in memory. It is only unloaded if another visualisation is selected after it has been de-activated. Or, if there are several visualisations selected and active, when one of them is deactivated.
The trick with audio-only is that the plugin is started and not stopped until two other visualisations are selected on both left and right decks. Then the VDJSpoutReceiver plugin is stopped and unloaded and, when one of them is de-activated, VDJSpoutReceiver is started again and boom - but only on a 32bit system.
Anyway, assuming that this has resolved the problem, I have uploaded corrected copy to GitHub.
https://github.com/leadedge/Spout2/tree/master/VIRTUALDJ
The only other difficulty I had was selecting another sender in audio-only mode. Normally you can activate the effect GUI and click the "Sender" button, but there is no such access in audio-only mode.
But I find that it might be possible with the Master effect list. At first there is no entry, but if the list is opened you can see VDJSpoutReceiver down the bottom and it is green for being selected. So I assume that a single audio-only visualisation is by default the master effect.
Now if you hover the cursor over VDJSpoutReceiver and hit the little cog wheel, it is then selected as the master effect and the GUI appears at right for the master. Which is just fine because a different sender can be selected. If that is the way it should work then all should be good to go.
Posted Mon 07 Dec 15 @ 1:01 pm
SBDJ
leadedge wrote :
The only other difficulty I had was selecting another sender in audio-only mode. Normally you can activate the effect GUI and click the "Sender" button, but there is no such access in audio-only mode.
As you've discovered, you can access it from the active slot, or by using a custom command: effect_show_gui 'audioonlyvisualisation'
Posted Mon 07 Dec 15 @ 1:51 pm
leadedge
Thanks Scott. As long as it can be done I am happy. If you can give this copy a run I would appreciate your eye over it.
Posted Mon 07 Dec 15 @ 2:00 pm
Don Moir
SBDJ wrote :
As you've discovered, you can access it from the active slot, or by using a custom command: effect_show_gui 'audioonlyvisualisation'
Note: effect_show_gui 'audioonlyvisualisation' only works if AOV is active and same as accessing from 'active' slot. This is because the AOV has no identity and currently only known when it is active and VDJ does not know what will be the AOV instance before hand because it is mixed in with decks and master. Things like effect_show_gui 'audioonlyvisualisation' would not even be 'needed' given a proper AOV implementation. Needed? What is the point of adding more insanity? Since the confusion is already built in, I guess might as well just add more confusion to it. End user has no concept of how any of this is supposed to work and that is natural given the AOV implementation is pathetic.
Posted Mon 07 Dec 15 @ 2:36 pm
SBDJ
Don, please do not hijack another thread. I will not ask twice.
Posted Mon 07 Dec 15 @ 5:49 pm
DHoude
I will give 1.07 Receiver a try. Interesting read. Although I would be curious to know what can be done to clean things up after a plugin runs as AOV. This is where my inexperience in coding limits my ability to fully understand the situation. Because of this I am useless at describing an approach, which I think is where some of Don M's passion come from.
All I can say is there definitely seems to be some kind of instability, despite how subtle it may be. In the early cases (before Spout re write) the plugin could crash VDJ without any indication of why (crash report).
If there is an interface that can make VDJ more robust for AOV or clean things up to help prevent this, I would say that would be time well spent. I have Zero idea of how to get there, but I really hope AOV can be improved. As it sits I don't trust AOV, especially with Automix. if I isolate the two, I could avoid the crashes that I got before Spout Receiver was re written.
All I can say is there definitely seems to be some kind of instability, despite how subtle it may be. In the early cases (before Spout re write) the plugin could crash VDJ without any indication of why (crash report).
If there is an interface that can make VDJ more robust for AOV or clean things up to help prevent this, I would say that would be time well spent. I have Zero idea of how to get there, but I really hope AOV can be improved. As it sits I don't trust AOV, especially with Automix. if I isolate the two, I could avoid the crashes that I got before Spout Receiver was re written.
Posted Mon 07 Dec 15 @ 7:45 pm
DHoude
Given the chance to have some kind of extra diag for VDJ or logging, I may be able to show what AOV s doing in my system.. I would like would welcome that opportunity.
Posted Mon 07 Dec 15 @ 8:06 pm
Don Moir
SBDJ wrote :
Don, please do not hijack another thread. I will not ask twice.
Please state the full story then so I don't have too.
Posted Mon 07 Dec 15 @ 8:36 pm
leadedge
Don H.
This cleaning up is important for the VDJSpoutReceiver plugin or all sorts of video and system memory can get left over. But it does get done.
A plugin cleans up any resources when it is "destroyed". This happens when it is "closed" by VirtualDJ and then it gets unloaded and destroyed. If you activate and then de-activate a selected plugin, it is is not unloaded but is just started and stopped. The plugin remains loaded until it is no longer required and that happens if it is not active and another plugin is selected and loaded. Sound confusing, but the only thing to worry about is that everything is released when it is closed and this was not happening before, but it was only evident on a 32bit system. I have no idea why at this stage.
With audio-only mode, there is no user action to start and stop it, so the unloading only happens when there is no place left for it and it is replaced by something else. If you never fill up the spaces on both left and right decks it never gets unloaded.
The previous instability of the Spout plugins came from attempting to use OpenGL within a program that is based on DirectX. It isn't a natural fit. I think what was happening is somehow related to threads and that what is established in one thread might not be available in another, so things can get screwed up. That is my theory anyway. The sender is more stable than the receiver was. It is much more simple in concept, just grabbing the VDJ texture and using it. Nothing is sent back to VDJ.
I think you are OK to go now with the VDJSpoutReceiver plugin, and even the one you have will still be OK as long as you avoid the situation described at the start.
If there are any problems with other Spout sources it is likely to be related to texture format. If there are any troubles, try changing to DirectX 9 mode with the "SpoutDirectX" program. The Winamp milkdrop plugin is one case at the moment where this could be needed. Here you should also change to DirectX 9 mode in the Milkdrop visualization configuration. This is a bit messy and will be fixed in the next Spout release.
This cleaning up is important for the VDJSpoutReceiver plugin or all sorts of video and system memory can get left over. But it does get done.
A plugin cleans up any resources when it is "destroyed". This happens when it is "closed" by VirtualDJ and then it gets unloaded and destroyed. If you activate and then de-activate a selected plugin, it is is not unloaded but is just started and stopped. The plugin remains loaded until it is no longer required and that happens if it is not active and another plugin is selected and loaded. Sound confusing, but the only thing to worry about is that everything is released when it is closed and this was not happening before, but it was only evident on a 32bit system. I have no idea why at this stage.
With audio-only mode, there is no user action to start and stop it, so the unloading only happens when there is no place left for it and it is replaced by something else. If you never fill up the spaces on both left and right decks it never gets unloaded.
The previous instability of the Spout plugins came from attempting to use OpenGL within a program that is based on DirectX. It isn't a natural fit. I think what was happening is somehow related to threads and that what is established in one thread might not be available in another, so things can get screwed up. That is my theory anyway. The sender is more stable than the receiver was. It is much more simple in concept, just grabbing the VDJ texture and using it. Nothing is sent back to VDJ.
I think you are OK to go now with the VDJSpoutReceiver plugin, and even the one you have will still be OK as long as you avoid the situation described at the start.
If there are any problems with other Spout sources it is likely to be related to texture format. If there are any troubles, try changing to DirectX 9 mode with the "SpoutDirectX" program. The Winamp milkdrop plugin is one case at the moment where this could be needed. Here you should also change to DirectX 9 mode in the Milkdrop visualization configuration. This is a bit messy and will be fixed in the next Spout release.
Posted Mon 07 Dec 15 @ 11:35 pm
DHoude
leadedge wrote :
With audio-only mode, there is no user action to start and stop it, so the unloading only happens when there is no place left for it and it is replaced by something else. If you never fill up the spaces on both left and right decks it never gets unloaded.
Ultimately this is what I was referring to as "Cleaning up". I definitely understand how stable we are now. Lol, if anybody knows... I have definitely beat it up and you have done an awesome job. I will definitely install and test the new Spout Receiver.
I use music videos for the most part (80% of the time) and maybe when I load one in each deck it will do a clean up. But I really should not be worrying about loading Video in all decks to unload AOV and clean up. What happens when I have 4 decks? Do I need to load all 4 to get a clean up? With all the other things I have to do, I need VDJ to handle clean up before it becomes an issue. This was not happening with my dinner Jazz because they were all Audio. My QA test was:
Auto mix - Audio Only - deck 2- Video not initiated yet (1, 2 and master blank), play a few songs
Then Play a Video in Deck 1 (1 min+) - Video now starts on Deck 1 and master - Turn off Auto mix on Deck 2
Then Play a Video in Deck 2
Then Play a Video in Deck 1 (1 min+)
Load an Audio Only track Deck 2 and start Auto mixing Audio Only songs - First start of AOV
It crashed pretty consistently this way before the re write of Spout Receiver. But it still feels like VDJ is unstable in this same manor. But here is another case that applies to my original issue, this was exactly what happened before a VDJ crash, before the Spout R re write: http://www.virtualdj.com/forums/205883/VirtualDJ_8_1_Technical_Support/Automix_just_stops___.html
During my wedding crashes, they were all Audio Only and Automix. I was working well enough when I was mixing the Audio tracks manually. As well as the dance set, I probably had 80% videos playing. So I may have been cleaning up all over the place. lol
To an end user (non programmer) AOV plus Automix seems to have issues. Maybe it is just Automix now, I am not really sure. I guess this is where we need to draw the distinction of Hijacked thread... I know it is not Spout for sure at this point a I am 100% on that. But it always seemed to be more than just SpoutReceiver from the beginning. I still believe that there is more than just Spout that was part of the original issue. I would love the opportunity to prove my distrust is wrong, but I am not sure how to prove that with independent testing.
Posted Tue 08 Dec 15 @ 2:02 am
leadedge
Oh - OK I see what you mean about the cleaning up part.
I haven't tried using the Automix function for a while. I am not familiar enough with this program to know how that would affect a plugin but will look into it if there is some connection.
I haven't tried using the Automix function for a while. I am not familiar enough with this program to know how that would affect a plugin but will look into it if there is some connection.
Posted Tue 08 Dec 15 @ 3:08 am
DHoude
I appreciate it, I know your time is low now. I also feel Spout is good, so no real need to go looking for a problem unless you want to.
In the other thread, it is starting to sound external too. This is where my, "maybe the interface could be more robust with external plugins" comment comes in. Ideally, VDJ really should not be able to be taken down ever. Maybe that is a "holy grail" wish, but stability is critical.
In the other thread, it is starting to sound external too. This is where my, "maybe the interface could be more robust with external plugins" comment comes in. Ideally, VDJ really should not be able to be taken down ever. Maybe that is a "holy grail" wish, but stability is critical.
Posted Tue 08 Dec 15 @ 3:31 am
SBDJ
DHoude wrote :
I use music videos for the most part (80% of the time) and maybe when I load one in each deck it will do a clean up. But I really should not be worrying about loading Video in all decks to unload AOV and clean up. What happens when I have 4 decks? Do I need to load all 4 to get a clean up? With all the other things I have to do, I need VDJ to handle clean up before it becomes an issue. This was not happening with my dinner Jazz because they were all Audio.
You're misunderstanding. If the AOV is still active somewhere - ie, the left and/or right video decks have an audio file on them, then the AOV is still active and in use, so you don't want to clean up. VDJ will request a plugin cleans up when it's no longer in use - and there are different stages of not being in use (and thus different cleanup calls). This would be the case with 1 deck or 99 decks, since the AOV works on the left/right video decks (and the master obviously). There is only ever one active instance of an AOV.
You don't need to force a cleanup to occur, it will happen automatically when it's time :)
DHoude wrote :
My QA test was:
Auto mix - Audio Only - deck 2- Video not initiated yet (1, 2 and master blank), play a few songs
Then Play a Video in Deck 1 (1 min+) - Video now starts on Deck 1 and master - Turn off Auto mix on Deck 2
Then Play a Video in Deck 2
Then Play a Video in Deck 1 (1 min+)
Load an Audio Only track Deck 2 and start Auto mixing Audio Only songs - First start of AOV
Auto mix - Audio Only - deck 2- Video not initiated yet (1, 2 and master blank), play a few songs
Then Play a Video in Deck 1 (1 min+) - Video now starts on Deck 1 and master - Turn off Auto mix on Deck 2
Then Play a Video in Deck 2
Then Play a Video in Deck 1 (1 min+)
Load an Audio Only track Deck 2 and start Auto mixing Audio Only songs - First start of AOV
I've just done a test here - as soon as you activate video, the AOV is activated on the automix deck in step 2. Worth retrying that test in a current build.
DHoude wrote :
To an end user (non programmer) AOV plus Automix seems to have issues.
If you can replicate that issue, please do. Detailed steps and video would help hugely.
Posted Tue 08 Dec 15 @ 9:17 am
