definitely.
if you overun the buffers, that will make a crash.
BSD problem
Re: BSD problem
this is a host probl.
send 1000 events to scope and record them _
none gets lost_
in fact i was not able to overrun the scopemidihook_
--
your host is not able to process in time_
so it loose sync to scope;
if you send 1000 controller events to scope scope sends 1000 values to the hostbased gui;
all the buttons and sliders got repainted by the host if visible_
scope does not wait for the host to be ready;
you would get dropouts like all the native stuff_
good vibes
send 1000 events to scope and record them _
none gets lost_
in fact i was not able to overrun the scopemidihook_
--
your host is not able to process in time_
so it loose sync to scope;
if you send 1000 controller events to scope scope sends 1000 values to the hostbased gui;
all the buttons and sliders got repainted by the host if visible_
scope does not wait for the host to be ready;
you would get dropouts like all the native stuff_
good vibes
Re: BSD problem
yes, that's the complete story from one who knows.
slow the stream and it should be ok.
Re: BSD problem
First, to confirm this I will let the system go a few days without any midi to see if the problem occurs without and midi traffic.
But if this is the problem, how do I know how much data I can send at a time. The if I pause, how long do I need to pause before continuing?
But if this is the problem, how do I know how much data I can send at a time. The if I pause, how long do I need to pause before continuing?
mark winger
Re: BSD problem
tgstgs,
Your reply explains why I was loosing data when I didn't have some pauses in there. But as far as I know I am not loosing anything now.
But does the sending of too many too fast explain why scope locks up and eventully BSD's. It does not do this often, and only when system up a while. As an example, it has now been running for 20 hours or so. I can send snapshots over and over right now and am not seeing the problem. I was thinking if the buffers over run and memory is corrupted, then the system could crash later. Just trying to guess what my be the cause.
Your reply explains why I was loosing data when I didn't have some pauses in there. But as far as I know I am not loosing anything now.
But does the sending of too many too fast explain why scope locks up and eventully BSD's. It does not do this often, and only when system up a while. As an example, it has now been running for 20 hours or so. I can send snapshots over and over right now and am not seeing the problem. I was thinking if the buffers over run and memory is corrupted, then the system could crash later. Just trying to guess what my be the cause.
mark winger
Re: BSD problem
first chck your code;
then check it a 2nd time;
--
overrunning a hostbuffer means writing in not allowed area makes a reboot withoout any asking or bsd no wait_
--
the probl. is more a host thtread not being ready in time_
--------
if an object on host isnt in use for a time the os puts it out to some temp storage_
now if you reaktivate it needs some time to be put in memory again;
also the painting needs a while and puts the cpuload under preasure;
im sure you are able to recreate the probl. y setting the host under preasure;
just copy some GB from usb to systemdrive while whatching a dvd in some player and click on buttons moving windows . . .
you may write a smal exe doing senseless 100sends of sin cos multiplys just to create a load;
or switch on some virus SW to additionaly scan data;
--
im sure with the same project it will also happen when no midi is sent just with the host underpresure;
---
privat solution:
switch back to scope wait till the cpuload is down again and then send your data_
if probl. stays change your setup devices for device host process for hostprocess to see wheres the troublemaker;
hope this helps vibes
then check it a 2nd time;
--
overrunning a hostbuffer means writing in not allowed area makes a reboot withoout any asking or bsd no wait_
--
the probl. is more a host thtread not being ready in time_
--------
if an object on host isnt in use for a time the os puts it out to some temp storage_
now if you reaktivate it needs some time to be put in memory again;
also the painting needs a while and puts the cpuload under preasure;
im sure you are able to recreate the probl. y setting the host under preasure;
just copy some GB from usb to systemdrive while whatching a dvd in some player and click on buttons moving windows . . .
you may write a smal exe doing senseless 100sends of sin cos multiplys just to create a load;
or switch on some virus SW to additionaly scan data;
--
im sure with the same project it will also happen when no midi is sent just with the host underpresure;
---
privat solution:
switch back to scope wait till the cpuload is down again and then send your data_
if probl. stays change your setup devices for device host process for hostprocess to see wheres the troublemaker;
hope this helps vibes
Re: BSD problem
We might be getting somewhere here. I am running no other applications when this happens so the system is not under load when I do this.
the one thing that may be getting me is that I have a show/hide button on my devices that is midiized so I can control which device are visible. They are part of the midi send many devices are told to hide (though most are not showing) and the others are told to show so that after the send the current view is also showing.
I have lots of devices (32 channel strips, 10-aux mixes, etc). I have noticed that if I send a snapshot via midi immediately after starting scope, scope will take a couple of seconds (appears to hang) while updating the screen after the patch is sent. Maybe if I remove the show/hide from the send, and do the screen view update after with pauses it would help.
Thanks.
the one thing that may be getting me is that I have a show/hide button on my devices that is midiized so I can control which device are visible. They are part of the midi send many devices are told to hide (though most are not showing) and the others are told to show so that after the send the current view is also showing.
I have lots of devices (32 channel strips, 10-aux mixes, etc). I have noticed that if I send a snapshot via midi immediately after starting scope, scope will take a couple of seconds (appears to hang) while updating the screen after the patch is sent. Maybe if I remove the show/hide from the send, and do the screen view update after with pauses it would help.
Thanks.
mark winger
Re: BSD problem
showing a device put the system under load_
send all the controllervalues in 1 go should be no probl. even if them are 1000sends and the show/hide with sleeps;
--
test it manually:
show a device and hide it -- no reaction of the cpuload?
move a device on screen to see how the repaint puts the system under preasure_
--
this is no probl. when scope is starting course it first inits_
init would just take longer_
but when its runnning it could be;
depending on what is running between scope and host_
so this may work with some devices not with others_
--
i just thougt it is no option to wait 15hours to verify a test_
so you may help a bit by manually put the system under preasure_
stresstest_vibes from vienna
send all the controllervalues in 1 go should be no probl. even if them are 1000sends and the show/hide with sleeps;
--
test it manually:
show a device and hide it -- no reaction of the cpuload?
move a device on screen to see how the repaint puts the system under preasure_
--
this is no probl. when scope is starting course it first inits_
init would just take longer_
but when its runnning it could be;
depending on what is running between scope and host_
so this may work with some devices not with others_
--
i just thougt it is no option to wait 15hours to verify a test_
so you may help a bit by manually put the system under preasure_
stresstest_vibes from vienna
Re: BSD problem
New set of results. First I changed the code to not send any hide/or show controls. So now the only screen repaints will be due to fader or button values.
I booted the system and scope autostarts with my project loaded. I did not even start my midi controller program so no midi was sent at all. I went out of town for the weekend and the system was still running fine. I confirmed scope was responsive and that that cpu usage was basically idle.
The system has now been idle for 48 hours with scope running. I load my midi control program all is well, still no midi sent to scope. Now I send a snapshot to scope. Scope immediately hangs with performance monitor showing 1 core at 100%. (4 core and the scope process shows 25%, so the 100% of the core is all scope.)
I terminate scope right away to avoid BSD. Restart scope and my midi controller. I can send as many snapshots as I wish and cannot make it fail.
I will try some "pressure testing" tonight, but based on what I just described I don't see how "pressure" has anything to do with the problem. I'm still suspicious of something wrong with the scope pci midi drivers.
I booted the system and scope autostarts with my project loaded. I did not even start my midi controller program so no midi was sent at all. I went out of town for the weekend and the system was still running fine. I confirmed scope was responsive and that that cpu usage was basically idle.
The system has now been idle for 48 hours with scope running. I load my midi control program all is well, still no midi sent to scope. Now I send a snapshot to scope. Scope immediately hangs with performance monitor showing 1 core at 100%. (4 core and the scope process shows 25%, so the 100% of the core is all scope.)
I terminate scope right away to avoid BSD. Restart scope and my midi controller. I can send as many snapshots as I wish and cannot make it fail.
I will try some "pressure testing" tonight, but based on what I just described I don't see how "pressure" has anything to do with the problem. I'm still suspicious of something wrong with the scope pci midi drivers.
mark winger
Re: BSD problem
I did not have time to "pressure test" but did get one more piece. I booted the system from scratch with socpe and controller loaded. I changed the controller to 2 ms delay between every controller sent. That slows down the load from less that 1 second with no delays to about 4 seconds. After the system was up for the day (12 hours or so) I checked the system. Seemed OK. Watching the task manager usage was 0-1%. I initiated a load and it worked. Waited for cpu time to settle and did another. Scope hung and consumed 100% of one of the cores again.
It seems I can hammer at it as much as I want but if I leave it idle for a long time, I can then cause the hang.
Tgstgs, you said I could probably cause the problem without any midi activity. I don't understand this. Were you saying just making the system busy will cause this? Even if scope is just idle? Please explain what you meant by that.
It seems I can hammer at it as much as I want but if I leave it idle for a long time, I can then cause the hang.
Tgstgs, you said I could probably cause the problem without any midi activity. I don't understand this. Were you saying just making the system busy will cause this? Even if scope is just idle? Please explain what you meant by that.
mark winger
Re: BSD problem
I did a stress test. I wrote a program in c++ that is just a cpu hog. It is simply a for loop 0 to 10,000,000,000 with a print every 10,000,000 times through the loop. I runs for a few minutes consuming 100% of one core.
I started one up and did a bunch of functions with scope and my controller, loading snapshots, moving faders, etc. No problem.
For each core a started another and did the scope stuff.
I had 4 instances of my program running, the process monitor graphs showed all 4 cores were flat lined at 100% and total cpu usage was 100%.
Even with 100% cpu load, the system worked flawlessly. The only thing different was screen paint of the scope devices took slightly longer but barely noticeable.
I put as much load on as I could and there were no problems at all. I even took out all the delays in my code so the controllers were sent as fast as the os would take them, but things worked perfectly.
At this point I cannot associate the problem with anything I am doing to scope. So I think I will have to analyze the core dump created when I get the BSOD.
I started one up and did a bunch of functions with scope and my controller, loading snapshots, moving faders, etc. No problem.
For each core a started another and did the scope stuff.
I had 4 instances of my program running, the process monitor graphs showed all 4 cores were flat lined at 100% and total cpu usage was 100%.
Even with 100% cpu load, the system worked flawlessly. The only thing different was screen paint of the scope devices took slightly longer but barely noticeable.
I put as much load on as I could and there were no problems at all. I even took out all the delays in my code so the controllers were sent as fast as the os would take them, but things worked perfectly.
At this point I cannot associate the problem with anything I am doing to scope. So I think I will have to analyze the core dump created when I get the BSOD.
mark winger
Re: BSD problem
_what if tested without any devices in the project just sequencer source to dest connected;
_have you tested with some other midi/in/out not scope_ maybe it is your code;
_have you deactivated all the sleeping functionallity and powersaving stuff of the host os_
_can you post a txt file what values you are sending to scope_
_and more important what do you recive;
even on a reboot the file got written till it reboots;
so you see how far you get;
check all the new and delete or close handle in your c code_
check if your hook is still alive before sending data_
hope this helps a bit_
good luck vibes
_have you tested with some other midi/in/out not scope_ maybe it is your code;
_have you deactivated all the sleeping functionallity and powersaving stuff of the host os_
_can you post a txt file what values you are sending to scope_
_and more important what do you recive;
even on a reboot the file got written till it reboots;
so you see how far you get;
check all the new and delete or close handle in your c code_
check if your hook is still alive before sending data_
hope this helps a bit_
good luck vibes
Re: BSD problem
_what if tested without any devices in the project just sequencer source to dest connected;
Have not tried that.
_have you tested with some other midi/in/out not scope_ maybe it is your code;
This will not work. Scope is the process that goes into real time loop. Process monitor shows it stuck burning cpu, not my code.
_have you deactivated all the sleeping functionallity and powersaving stuff of the host os_
Yes
_can you post a txt file what values you are sending to scope_
_and more important what do you recive;
even on a reboot the file got written till it reboots;
???
so you see how far you get;
It never crashes [BSOD] until long after I stop sending data. I know I send all the data but I cannot tell when scope hangs and stops receiving data.
check all the new and delete or close handle in your c code_
If I run under Visual Studio it indicates all handles closed if I terminate.
check if your hook is still alive before sending data_
what do you mean by hook? File descriptor? If it were closed/dead, scope would not received the data, my program would fail/hang/crash, not scope.
I am using midiOutShortMsg function and always check return status. If the send failed, I would present a dialog with the status. So I don't see how the connection could be dead unless the windows api is broken. Again, scope gets something or it would not hang.
This morning, after leaving the system up last night (12 hours after the stress testing revealed nothing), I checked the status. The midi controllers were responding. I moved a couple faders and everything tracked. Then I sent a snapshot (the same snapshot I used in the stress test) and it caused scope to hang again. Clearly my hook is alive or I would not have been able to change some controllers before sending the snapshot.
Have not tried that.
_have you tested with some other midi/in/out not scope_ maybe it is your code;
This will not work. Scope is the process that goes into real time loop. Process monitor shows it stuck burning cpu, not my code.
_have you deactivated all the sleeping functionallity and powersaving stuff of the host os_
Yes
_can you post a txt file what values you are sending to scope_
_and more important what do you recive;
even on a reboot the file got written till it reboots;
???
so you see how far you get;
It never crashes [BSOD] until long after I stop sending data. I know I send all the data but I cannot tell when scope hangs and stops receiving data.
check all the new and delete or close handle in your c code_
If I run under Visual Studio it indicates all handles closed if I terminate.
check if your hook is still alive before sending data_
what do you mean by hook? File descriptor? If it were closed/dead, scope would not received the data, my program would fail/hang/crash, not scope.
I am using midiOutShortMsg function and always check return status. If the send failed, I would present a dialog with the status. So I don't see how the connection could be dead unless the windows api is broken. Again, scope gets something or it would not hang.
This morning, after leaving the system up last night (12 hours after the stress testing revealed nothing), I checked the status. The midi controllers were responding. I moved a couple faders and everything tracked. Then I sent a snapshot (the same snapshot I used in the stress test) and it caused scope to hang again. Clearly my hook is alive or I would not have been able to change some controllers before sending the snapshot.
mark winger
Re: BSD problem
hook:
void __stdcall MIDIHACK (HMIDIIN handle, UINT msg, DWORD dwInstance, DWORD dwParam1, DWORD dwParam2)
{
//fill buffer
}
__if scope hangs and stops working it would not send any data to host burnig cpu right;
AND you will get an imediatly reboot btw.
--
again you have and describe a hostprobl.
as it is in direct relation to code you wrote and send to dsps you must accept questions about what makes you that sure your code is ok
//I know I send all the data but . . .
NO you posted messages in a que hoping the os delivers it hopefully as soon as possible
so it would be interesting what exaclty you are sending and what you recive in good vs bad case_
but anyway;
happy hunting in the dark vibes
void __stdcall MIDIHACK (HMIDIIN handle, UINT msg, DWORD dwInstance, DWORD dwParam1, DWORD dwParam2)
{
//fill buffer
}
__if scope hangs and stops working it would not send any data to host burnig cpu right;
AND you will get an imediatly reboot btw.
--
again you have and describe a hostprobl.
as it is in direct relation to code you wrote and send to dsps you must accept questions about what makes you that sure your code is ok
//I know I send all the data but . . .
NO you posted messages in a que hoping the os delivers it hopefully as soon as possible
so it would be interesting what exaclty you are sending and what you recive in good vs bad case_
but anyway;
happy hunting in the dark vibes
Re: BSD problem
I think I may have found the problem. The problem is on the scope side but it is a bad device. I noticed that after I send a snapshot to scope, there would be about a 5 second delay before fader moves would be recognized by scope. For example, start a snapshot send that takes a second or so. As soon as I see the scope device udpate, move a fader on the controller. The move would take about 5, seconds.
I then went in to my code and started slicing up the transfer and found if I skipped sending data to one device, scope would no longer stop responding for 5 second.
I then went to show that device and found I could not show it. Somehow the device has become corrupt since I created it a couple years ago.
My system was dual boot win7 and xp until I rebuilt it last week. My sdk was installed on the xp partition which I destroyed. I currently have scope in 2 systems running win 7 and no xp, and one xp system. The card in the xp system does not have an sdk license. I will need to shuffle the cards around so I have a scope card with the sdk license in the xp system.
Hopefully in the next couple days I can get the device fixed or rebuilt and see if the problem is resolved.
I then went in to my code and started slicing up the transfer and found if I skipped sending data to one device, scope would no longer stop responding for 5 second.
I then went to show that device and found I could not show it. Somehow the device has become corrupt since I created it a couple years ago.
My system was dual boot win7 and xp until I rebuilt it last week. My sdk was installed on the xp partition which I destroyed. I currently have scope in 2 systems running win 7 and no xp, and one xp system. The card in the xp system does not have an sdk license. I will need to shuffle the cards around so I have a scope card with the sdk license in the xp system.
Hopefully in the next couple days I can get the device fixed or rebuilt and see if the problem is resolved.
mark winger
Re: BSD problem
I built a new device to replace the one acting up. I won't know for a while if the problem is resolved though. However, in the process of installing the new device I discovered something odd.
I went in to replace the bad device with the new device, and I got a BSOD immediately. After rebooting the system I tried again and it worked. But all the routing was lose so I manually routed it. With the new project, the time delay of updating the device was not fast. It is simply a 32 channel signal switch. I can turn on or off any of 32 signals. Before it would take 5 seconds to update it with 32 controllers, now it took maybe 1/2 second. It seemed to be working fine until I realized I had not included on the routing.
This is used as mute switch. 32 channel strips route to this. The 32 outs route to 8 mix busses. At first I only routed to the main buss. When I realized this, I went in an added the route to the other 7 buss (all 32 channels). After that it now take 5 seconds to update all the switches again.
I can only assume scope is trying to do a lot more that stop the signal from passing through the switch. Is it trying to disable the devices it is connected to? Is it trying to unload devices to save resources? If so, is this device that controls this or the one it is connected to?
If the answer is yes, the discussion probably move developer forum to determine/discuss the solution. tgstgs, you seem to be very familiar with the SDK. Do you think this could be something with my devices?
I went in to replace the bad device with the new device, and I got a BSOD immediately. After rebooting the system I tried again and it worked. But all the routing was lose so I manually routed it. With the new project, the time delay of updating the device was not fast. It is simply a 32 channel signal switch. I can turn on or off any of 32 signals. Before it would take 5 seconds to update it with 32 controllers, now it took maybe 1/2 second. It seemed to be working fine until I realized I had not included on the routing.
This is used as mute switch. 32 channel strips route to this. The 32 outs route to 8 mix busses. At first I only routed to the main buss. When I realized this, I went in an added the route to the other 7 buss (all 32 channels). After that it now take 5 seconds to update all the switches again.
I can only assume scope is trying to do a lot more that stop the signal from passing through the switch. Is it trying to disable the devices it is connected to? Is it trying to unload devices to save resources? If so, is this device that controls this or the one it is connected to?
If the answer is yes, the discussion probably move developer forum to determine/discuss the solution. tgstgs, you seem to be very familiar with the SDK. Do you think this could be something with my devices?
mark winger
Re: BSD problem
Well, the problem is still not resolved.
The device that was bad, so I created a completely new one. It is simply a 32 switches used for mute between the channel strips and the aux and main mix. I found that if I install the device in my project, and connect the 32 inputs to the channels, and the 32 outputs to just the main mix it seems stable. No detectable problems.
However, if I route the outputs to all 8 aux mixes I have in the project, it will become unstable(have not tried different amount like 2 or 4). After a while (12 hours give or take) when I send 32 controllers to change all the switches off or on I will get the scope hang problem. The other behavior change is slow response. Immediately after connecting the mixes, scope becomes non-responsive for 5 seconds every time I sent the 32 controllers all at once. As a matter of fact you can even see things are slow by pressing a few mute buttons on my surface which send controllers to mute or unmute the channels.
I don't understand why simply turning a signal switch on or off should take so much longer simply because it's output is routed to 8 destinations instead of 1. Any ideas?
I have 25 dsp's installed and the project is at about 50% usage. Could I be having troubles with the large number of interconnects causing scope problems? (Probably have about 500 audio interconnects and maybe 50 midi interconnects in the project)
The device that was bad, so I created a completely new one. It is simply a 32 switches used for mute between the channel strips and the aux and main mix. I found that if I install the device in my project, and connect the 32 inputs to the channels, and the 32 outputs to just the main mix it seems stable. No detectable problems.
However, if I route the outputs to all 8 aux mixes I have in the project, it will become unstable(have not tried different amount like 2 or 4). After a while (12 hours give or take) when I send 32 controllers to change all the switches off or on I will get the scope hang problem. The other behavior change is slow response. Immediately after connecting the mixes, scope becomes non-responsive for 5 seconds every time I sent the 32 controllers all at once. As a matter of fact you can even see things are slow by pressing a few mute buttons on my surface which send controllers to mute or unmute the channels.
I don't understand why simply turning a signal switch on or off should take so much longer simply because it's output is routed to 8 destinations instead of 1. Any ideas?
I have 25 dsp's installed and the project is at about 50% usage. Could I be having troubles with the large number of interconnects causing scope problems? (Probably have about 500 audio interconnects and maybe 50 midi interconnects in the project)
mark winger
Re: BSD problem
Mark I only read a part of this, but to just to mention the 12 hour accident...
(to avoid you're looking deeper than necessary)
imho this is a regular (mis)behavior of Scope
if a project is on for a long time, there will always be stuff to break it once you add a device
(I have no idea which devices in particular or what part exactly causes the hangup)
it does not happen always, some devices seem fairly 'safe' while other's don't
(no energy saving on here)
if you restart the very same project, the device is added without problems
leaving the project on will make it 'sensitive' after a certain amount of time
I don't mind the 'feature' and simply reload the project in advance if something important gets added
cheers, Tom
(to avoid you're looking deeper than necessary)
imho this is a regular (mis)behavior of Scope
if a project is on for a long time, there will always be stuff to break it once you add a device
(I have no idea which devices in particular or what part exactly causes the hangup)
it does not happen always, some devices seem fairly 'safe' while other's don't
(no energy saving on here)
if you restart the very same project, the device is added without problems
leaving the project on will make it 'sensitive' after a certain amount of time
I don't mind the 'feature' and simply reload the project in advance if something important gets added
cheers, Tom
Re: BSD problem
Hi Astroman,
My experience confirms what you said. However, my problem will occur without loading any new devices at all. It appears random. I can consistently cause by simply sending a series of midi controllers to switch things on and off, after the project has been loaded for a fairly long time.
Here is a real example of how this has hit me. I was using this system as a FOH mix at a county fair. It was a continually changing stage, different acts every hour with only a couple minutes between acts. I have had this hang condition occur late in the evening 2 times. When it happens, the scope audio continues to work fine but I cannot change the mix at all. The scope process is completely hung. I must shut down scope and restart.
Other than changing faders and switches via midi controllers, the project is not changed during the entire time. I have thought about reloading scope a couple times during the day but when I reload scope I need to shut down the power amps (the boot up static will scare everyone to death, 110db for several seconds). So I have to take 3-5 minutes each time I do it. Besides, that I don't know for sure how often I need to do this to be sure the problem does no occur. The problem needs to be resolved somehow, not just avoided.
The devices I use are mostly ones I have created with the sdk, so I don't know for sure if it a scope problem or a device problem.
My experience confirms what you said. However, my problem will occur without loading any new devices at all. It appears random. I can consistently cause by simply sending a series of midi controllers to switch things on and off, after the project has been loaded for a fairly long time.
Here is a real example of how this has hit me. I was using this system as a FOH mix at a county fair. It was a continually changing stage, different acts every hour with only a couple minutes between acts. I have had this hang condition occur late in the evening 2 times. When it happens, the scope audio continues to work fine but I cannot change the mix at all. The scope process is completely hung. I must shut down scope and restart.
Other than changing faders and switches via midi controllers, the project is not changed during the entire time. I have thought about reloading scope a couple times during the day but when I reload scope I need to shut down the power amps (the boot up static will scare everyone to death, 110db for several seconds). So I have to take 3-5 minutes each time I do it. Besides, that I don't know for sure how often I need to do this to be sure the problem does no occur. The problem needs to be resolved somehow, not just avoided.
The devices I use are mostly ones I have created with the sdk, so I don't know for sure if it a scope problem or a device problem.
mark winger