The VXML application I mentioned in a previous question is now in testing. After allowing the user to record a message (max length 5 minutes) we go into a standard menu (submit, playback, re-record, etc).
One of our testers, bored as anything and tired of leaving a 5-minute message was reading an email we had sent, including the phone number. She said 'Two' just after the menu started, having heard only a split second of the menu.
Needless to say, she was very confused.
The right way to fix this, to me, seems to be to add a definitive stop to the recording, like the beep that begins it.
The record item has a beep property that beeps at the start of the recording, which we use. I can't find reference to any property that would beep when the user reaches max time.
How can I add an uninterruptible beep at the end of a when it has reached the maxtime?
Well, a bit more digging tells me that there's no property for it on the object.
But I did turn up a property on the resulting variable 'maxtime' that tells you if it ended due to a maximum time exceeded event.
By checking that in the section, but before sending them to the menu, I am able to use an block to play an audio file with bargein="false"
It's a bit more code than I'd like, but it seems to work.
Related
[out]
exten=>_X.,1,Answer()
exten=>_X.,n,Background(hello)
exten=>_X.,n,WaitExten(5)
exten=>1,1,Goto(check,s,1)
Audio menu are playing, but when I press 1, sound stop and after few second check command run. How to quickly respond to a user request?
You are doing begginer error which described in almost any asterisk book for beginer.
I recommend you read "Asterisk The Future of Telephony" by O'Relly.
This exact error is simple:
in your dialplan you have extension _X., which mean "any number starting with digit.
you ask asterisk waitfor extension selected in this context.
you are pressing digit, but acordinly to context you may want enter 1111(also fit you context). So asterisk wait upto TIMEOUT(digits) until you enter next digit.
your timeout is 5 second, so it go ext 1 in 5 second.
[Syntax]
BackGround(filename1[&filename2[&...]][,options[,langoverride[,context]]])
You can use other context for matching.
In Vulkan,
A semaphore(A) and a fence(X) can be passed to vkAcquireNextImageKHR. That semaphore(A) is subsequently passed to vkQueueSubmit, to wait until the image is released by the Presentation Engine (PE). A fence(Y) can also be passed to vkQueueSubmit. Client code can check when the submission has completed by checking fence(Y).
When fence(Y) signals, this means the PE can display the image.
My question:
How do I know when the PE has finished using the image after a call to vkQueuePresentKHR? To me, it doesn't seem that it would be by checking fence(X), because that is for client code to know when the image can be written to by vkQueueSubmit, isn't it? After the image is sent to vkQueueSubmit, it seems the usefulness of fence(X) is done. Or, can the same fence(X) be used to query the image availability after the call to vkQueuePresentKHR?
I don't know when the image is available again after a call to vkQueuePresentKHR, without having to call vkAcquireNextImageKHR.
The reason this is causing trouble for me is that in an asynchronous, 60fps, triple buffered app (throwaway learning code), things get out of wack like this:
Send an initial framebuffer to the PE. This framebuffer is now unavailable for 16 milliseconds.
Within the 16ms, acquire a second image/framebuffer, submit commands, but don't present.
Do the same as #2, for a third image. We submit it before 16ms.
16ms have gone by, so we vkQueuePresentKHR the second image.
Now, if I call vkAcquireNextImageKHR, the whole thing can fail if image #1 is not yet done being used, because I have acquired three images at this point.
How to know if image #1 is available again without calling vkAcquireNextImageKHR?
How do I know when the PE has finished using the image after a call to vkQueuePresentKHR?
You usually do not need to know.
Either you need to acquire a new VkImage, or you don't. Whether PE has finished or not does not even enter that decision.
Only reason wanting to know is if you want to measure presentation times. There's a special extension for that: VK_GOOGLE_display_timing.
After the image is sent to vkQueueSubmit, it seems the usefulness of fence(X) is done.
Well, you can reuse the fence. But the Implementation has stopped using it as soon as it was signaled and won't be changing its state anymore to anything, if that's what you are asking (and so you are free to vkDestroy it or do other things with it).
I don't know when the image is available again after a call to vkQueuePresentKHR, without having to call vkAcquireNextImageKHR.
Hopefully I cover it below, but I am not precisely sure what the problem here is. I don't know how to eat a soup without a spoon neither. Simply use a spoon— I mean vkAcquireNextImageKHR.
Now, if I call vkAcquireNextImageKHR, the whole thing can fail if image #1 >is not yet done being used, because I have acquired 3 images at this point.
How to know if image #1 is available again without calling >vkAcquireNextImageKHR?
How is it any different than image #1 and #2?
Yes, you may have already acquired all the images the swapchain has to offer, or the PE is "not ready" to give away an image even if it has two.
In the first case the spec advises against calling vkAcquireNextImageKHR with timeout of UINT64_MAX. It is a simple matter of counting the successful vkAcquireNextImageKHR calls vs the vkQueuePresentKHRs. One way may be to simply do one vkAcquireNextImageKHR and then do one vkQueuePresentKHR.
In the second case you can simply call vkAcquireNextImageKHR and you will eventually get the image.
In order to use a swapchain image, You need to acquire it. After that the actual availability of the image for rendering purposes is signaled by the semaphore (A) or the fence (X). You can either use the semaphore (X) during the submission as a wait semaphore or wait on the CPU for the fence (X) and submit after that. For performance reasons the semaphore is a preferred way.
Now when You present an image, You give it back to the Presentation Engine. From now on You cannot use that image for whatever purposes. There is no way to check when that image is available again for You so You can render into it again. You cannot do that. If You want to render into a swapchain image again, You need to acquire another image. And during this operation You once again provide a semaphore or a fence (probably different than those provided when You previously acquired a swapchain image). There is no other way to check when an image is again available than through calling the vkAcquireNextImageKHR() function.
And when You want to implement triple-buffering, You should just select appropriate presentation mode (mailbox mode is the closest match). You shouldn't wait for a specific time before You present an image. You just should present it when You are done rendering into it. Your synchronization should be entirely based on acquire, present commands and semaphores or fences provided during these operations and during submission. Appropriate present mode should do the rest. Detailed explanation of different present modes is available in Intel's tutorial.
So I have a long-running python notebook.
As long as it's open in my browser's tab, it's autosaving every 2 minutes, and life is good.
Is it possible to keep it auto-saving even if I close the browser tab?
The kernel already keeps running when I close the tab, which is great.
This is kind of like "screen", but in jupyter
EDIT: Even if I leave the tab open in my browser, I noticed that after 24 hours, the "kernel status" in the top right becomes "disconnected", even though the running cell still has output being piped to it from the server websocket connection
No, you can't (for now), and their will be no point in doing it.
The reason is, as soon as you close your tab, some critical information is lost because it is in the memory of the Javascript VM that run the page.
Any update sent by the kernel after you've closed your page are lost.For example try the following.
create a cell with sleep(10);print('Hello')
Execute the cell
Quickly close and reopen the tab.
the "Hello" will never be printed.
The mapping between the "Execution request" and the "Execution reply" have been lost, and can't be recovered.
The Jupyter team is aware of that. The fixes are not that hard, but require a lot of careful refactor and API design. There was a long in person discussion in NYC at the end of August 2017. Right now the focus is to polish JupyterLab, and once this is done it will be one of the area of focus. It will go hand in hand with real-time collaboration.
In more detail, the fix requires to "move" the notebook model from the client (your browser) to a server side (what is serverside is handwaved for now, but here is not the place to expand it), there are technical questions about that, like what to do with widgets, and when collaborating what state is shared by everyone and what state is per-client. Like if you fold some code, should this be stored ? or not ?
If you are interested in that, I would suggest getting involved with JupyterLab, there will be soon a number of low hanging fruits to contribute that should quickly fix 80% of the usecases.
When the player character goes into the Staffroom at the orphanage/boarding school they live at, said player has two turns before they hear the manager's footsteps coming down the hall and they are urged to hide. I've done this through use of number variables. At this point I have another number variable (set up like a true/false thingy by only using 0 and 1) to govern whether or not trying to do anything except 'hiding' or 'hiding wrongly' gives the response 'There's no time for that, just hide!'. The problem is this: Whenever I start the game, ANY ACTION is rejected and met by 'There's no time for that, just hide!'.
Code:
NOTSITS is a number variable.
When play begins:
now NOTSITS is 0.
Every turn when the location is the Staffroom:
increase NOTSITS by 1.
Every turn when the location is the Staffroom:
if NOTSITS is 2:
now HYF is 1;
say "From the hall outside, you hear footsteps... Shit, that sounds like Rodger![paragraph break]HIDE!".
HYF is a number variable.
When play begins:
now HYF is 0.
Every turn :
if HYF is 1:
instead of doing anything other than hiding or hiding wrongly:
say "There's no time for that, just hide!".
Hiding is an action applying to nothing.
Understand "hide" as hiding.
Hiding wrongly is an action applying to one thing.
Understand "hide in [something]" as hiding wrongly.
Instead of hiding:
try entering the empty cupboard;
now HYF is 0.
Instead of hiding wrongly, say "Don't waste time with stupidity, just hide!"
Please don't suggest using Inform 7's own time system to solve this. I tried that and it was a far bigger shizztorm of problems than this has been.
I think the problem is that you're relying too much on every turn rules, but they run after the actions have all been processed, so it's too late for them to do what you want them too. I also defined hiding as a synonym for entering, because that action already exists, and it's what you want to happen. So try this instead:
First turn is a truth state variable. First turn is true.
The staffroom is a room.
In the staffroom is an enterable container called the empty cupboard.
Understand "hide" as entering.
Carry out entering when first turn is true:
now first turn is false;
Understand "hide in [something]" as a mistake ("Don't waste time with stupidity, just hide!").
Instead of doing something other than looking or entering when first turn is true:
say "There's no time for that, just hide!";
(Also in the future it will help if you provide the full source code, or at least all that's relevant. This time you left out the staffroom and cupboard.)
You can specify an action and its time of appearance after entering a room:
After going to Staffroom for the first time:
manager comes in three turns from now.
At the time when manager comes:
YOUR STUFF
I am attempting to use DirectShow to play two AVI files consecutively (one after the other) so that there is no interruption in the audio or video when the player transitions from one file to the next.
I have two custom controls on my form. Each one is pre-loaded with an AVI file, and before playback begins I set up all the DirectShow interfaces, set the video windows and resize them, call IMediaControl.Run(), then IMediaControl.Pause(), then IMediaSeeking.SetPositions to reset to frame 0, on both controls. On the form, you can see that both files are paused at their initial frames.
I then call IMediaControl.Run() on the first control, and wait for it to complete before calling Run() on the second control. Initially, I hooked into the first video's EC_COMPLETE notification message, and used this to start the second. Thinking that this event might be slow to arrive (turns out it is, but for a weird reason), I tried two other approaches:
Check the first video's current position inside a timer that goes off every second or so (using IMediaPosition.get_CurrentPosition). When the current position is within a second of the video's stop time (known in advance from IMediaPosition.get_StopTime), I go into a tight while loop and wait for the current position to equal the stop time, and then call Run() on the second video.
Same as the first, except I replace the while loop with a call to timeSetEvent from winmm.dll, with a delay set so that it fires right when the first file is supposed to end. I use the callback to Run() the second file.
Either of these two methods substantially cuts down the delay between the end of the first file and the beginning of the second, indicating that the EC_COMPLETE message doesn't arrive immediately after the file is complete (I also tried hooking the EC_SEGMENT_COMPLETE message, which is supposed to be used for looping within a file, but apparently nobody supports this - it never occurs on my machine, at least).
Doing all of the above has cut the transition delay from as much as a second, down to a barely perceptible glitch; about a third of the time the files transition with no interruption at all, which suggests there's no fundamental reason I can't get this to work all the time.
The slight delay is still unacceptable, unfortunately. I assume (and I could easily be wrong) that the remaining delay is due to a slight variable delay between the call to IMediaControl.Run() and when the video actually starts playing.
Does anybody know anything I can do to eliminate this little lag? It would also help to be told this is fundamentally impossible for whatever reason, which wouldn't surprise me. I've never encountered a video player in Windows that doesn't have this problem, so it may not be doable.
More info: the AVI files I'm playing are completely uncompressed (video and audio are uncompressed), so I don't think the lag is due to DirectShow's having to uncompress the video ahead of play start, although it may still buffer ahead as matter of course (and this may be the source of the problem). I would have though that starting play, pausing and then rewinding to the beginning would fix this.
Also, the way I'm handling the transition is to actually have the second control underneath the first; when the first completes playing, I start the second and then call BringToFront on it, creating the appearance of a single video transitioning between the two originals. I don't think the glitch is due to this, because it works perfectly some of the time, and even if this were problematic, it wouldn't explain the matching audio glitch.
Even more: I just tried starting the second video 30-50 milliseconds "early" and that seemed to eliminate even more of the gap, so I'm guessing that the lag in Run() is about that long. It appears to be variable, though, so this is still not where I need it to be.
Still more: perhaps I could eliminate this delay by loading the AVIs from memory rather than from a file. Unfortunately, I have no idea how to do this. IMediaControl only has a RenderFile() method, not something like a RenderStream or RenderMemory method.
If you call IMediaControl::Run on a stopped graph, the graph manager will post the call to a worker thread (so there's some variability). On the worker thread, the graph will be paused. Render filters only complete a pause transition once they have received data, so once GetState() returns S_OK, the graph manager knows that the graph is fully cued. At this point, it picks a time roughly 10ms into the future, and calls Run on each filter with that time as the start point. Since it takes time to tell each filter to Run, the dshow Run method has a parameter which is the refclock time at which a sample timestamped zero should be played -- i.e. the time at which the actual transition to run mode should take place.
To synchronise this with another graph, you first have to ensure that both graphs have the same clock. Query the graph (not the filter) for IMediaFilter, and call GetSyncSource on one graph and SetSyncSource on the other. Then you need to pause the second graph, so that it is cued and ready. When you want to start it, call IMediaFilter::Run instead of IMediaControl::Run, and you can pass your own start time. This still has to be a few milliseconds into the future, so the best thing might be to set the start time of the second graph to be the first graph's start time plus its duration (for an indexed container of uncompressed streams, the duration should be accurate).
Another approach is to use multiple graphs. Separating source from rendering would allow you to switch seamlessly between sources since they feed into a common render graph. There is sample source code for this approach at www.gdcl.co.uk/gmfbridge.
G