I didn't hear anything about rumored interrupts on the P2, did you guys???
Chip, I'm sure you meant how you were interrupted from streamlining the Verilog to answer a few questions when you said "interrupts".
Thanks for spending some time with us....now, back to work!!!!
It's awesome to have the instruction set, see an example of some code and a few scope traces.
I think its about time to start having some serious fun with this thing, looking forward to some FPGA images.
C.W.
Now, I know this interrupt thing is kind of different, and goes against established orthodoxy, especially my own. We probably shouldn't speak about any of this above a whisper, even in our own minds, for a while. We don't need any crises of conscience at this stage of the game.
How about we bury the interrupt discussion and announcement 100 pages into a 3000+ post thread, shortly after a major forum upgrade. With a crippled forum search. They'll never find it.
(actually the forum search picks it out beautifully)
Thanks for the logic traces Chip. Sums it up very nicely. Its great that tasking may be possible too
Now, I know this interrupt thing is kind of different, and goes against established orthodoxy, especially my own. We probably shouldn't speak about any of this above a whisper, even in our own minds, for a while. We don't need any crises of conscience at this stage of the game.
How about we bury the interrupt discussion and announcement 100 pages into a 3000+ post thread, shortly after a major forum upgrade. With a crippled forum search. They'll never find it.
See, all you naysayers, ne'er do wells and assorted nattering nabobs of negativism!!!! Parallax did have a grand strategic plan for all of the recent changes!!!!
Thanks for pointing this, now obvious, plan out, Tubular!
Chip,
How difficult would it be to capture CNT when the interrupt is triggered (as opposed to when the LINK is inserted)? This would allow the interrupt handler to compensate for the variable latency. Maybe the C or Z flag in GETCNT could be used to get this value instead of the normal CNT?
Interrupts? What interrupts? I thought we were talking about a hardware initiated event switch or vectored jump!
I find it highly amusing that people preached against interrupts for the entire time I've been on these forums and now they become a great new feature of P2!
Interrupts? What interrupts? I thought we were talking about a hardware initiated event switch or vectored jump!
I find it highly amusing that people preached against interrupts for the entire time I've been on these forums and now they become a great new feature of P2!
We are not amused. I think interrupts are a major step backwards. More later.
Preemptively (no pun intended), I'd like to point out that this is an entirely optional feature. If you ignore it, the P2 will behave no differently than you thought it would at the beginning of the week. I think this strikes a nice balance between traditional interrupts and polling with WAITxxx. Unlike most traditional MCUs with interrupts, the use of this feature is optional. Just another tool in the toolbox.
As has been mentioned also with table-based cog prioritization, you don't have to use it, and it is off by default.
While you could also say this about single-core microcontrollers, the (big) difference is that if you write a driver or routine for them, you don't know how it will be interrupted, and it will be up to the poor sap using it to make sure it all works together.
With the propeller, if you write a driver or routine, you can be pretty sure that you have 100% of available cycles on that cog - if the poor sap modifies it to add an "interrupt", that's on him, and with 16 independent cores, there should be no need to do so. The only use of this feature that I see is integrated with the driver/routine in the cog, not separate from it... but I'm sure we'll find uses for it that no one is currently envisioning.
I would take the tasker feature in the "hot" chip over this in a quick, easy minute. But that's not an option on this design path. I don't know why. As for "great new feature!" I personally see the timer interrupt as necessary given how this design is playing out. The rest? meh It's gonna have to play out in FPGA land to know anymore than that.
But I'm in, and have been for years, to see this actualized. That has not changed. If this is necessary, then let's make it as robust, simple, pain free, etc... as possible. Not my call.
So in the back of my mind:
1. Was it too hot to do it that way, like did we learn process limits favor an interrupt structure at some performance level or other? This warrants a serious discussion. It's been on my mind for some time.
2. There are specific design visions for the P2, and given those same limits, this is how to get them.
3. Now it's going to play out. All of those who said, "it's just an option" get it. Sweet, right? We shall see whether or not the general utility of the P1 carries over or not. Dropping code into COGS? Maybe. Of course, HUBEXEC sort of already broke that barrier down somewhat. We have yet to see what a smart pin really is and that may favor this path strongly. I don't know.
Maybe adding HUBEXEC more or less changes the dynamics to a point where the strict isolation of the P1 really doesn't make the same sort of sense. That has been on my mind since P2 "hot" too, though it wasn't any sort of driver to favor interrupts.
4. Without the tasker, I think we need 'em. It's that simple. These P2 COGS cannot do the sorts of things the "hot" P2 COGS did. And having been there, it's compelling. Compelling enough to rethink things, and that's precisely what Chip did. A lot of stuff got stripped away on this design. Arguably, stuff that should be.
5. They (interrupts) are, or can be, contained in a COG and used to improve on what a COG can do as a COG just as much as they can be a mess of code sprinkled around in HUB nobody wants to sort through.
The source, vector, and mechanics of how they work is portable across COGS, so "drop code into a COG", even while another program is running, is still possible as we saw it on P1. So, doing things like dropping in TV or VGA, or maybe USB, into a program isn't going to be harder than it is on a P1, unless... Say those things are written with or that require some HUBEXEC code. Now it's more like ordinary CPU designs where a memory map, etc... are going to need consideration. Where it can be packed into a COG only, not a lot changes.
As an example: WAITVID is gone, replaced with a more general purpose thing FIFO / STREAMER. We are going to really like this, because it goes both ways, in and out.
One of those interrupt sources is a block wrap trigger on the FIFO / STREAMER. (I don't know what we call 'em, because Chip has not told us enough yet) If we are going to do more in software, and the hardware is more general purpose, that interrupt source means being able to implement the cool WAITVID stuff needed to produce great video in simple, robust ways like we do on P1, as just one example. Just saying...
Think about it. Without it, the COG will do nothing but monitor the thing, and make changes as needed, doing little else. With it, one can implement what a WAITVID was, and a P2 COG can do more and do it in a way more like a P1 COG does, with the benefit of a much more general purpose hardware feature than WAITVID.
That's how I see these personally. If I'm right in that assessment, then we need them on this design path.
6. The TIE toggle might be a problem. Would still prefer two explicit instructions, or an optional state bit, so that it either toggles, or just sets on or off, so that known state points can be established. The toggle will require parsing all the way back to the initial state to debug. I always sort of disliked toggles for this dynamic.
7. It's Chip's chip. I'm in, until it makes sense not to be. So, when we get an image to jam on, the mess or not will be quickly known then. It's been a long journey. I'm going to stick it out, because I believe in what Chip wants to get done here. And what I see is the "orthodoxy" may just be getting in the way of that, and if so, at considerable expense. On this, again, I don't know.
8. I very strongly suspect some great stuff is going to be learned on this one. Let's just say, orthodox code is going to compete, and I'm very interested in seeing that all play out.
9. Again, we've not seen what a smart pin is. Some things we consider difficult, or let's say require easy, strict determinism, just might not require that anymore. We do know there is smart mode and not smart mode now. When a pin is not smart, the usual rules on P1 are going to apply. When a pin is smart? I don't know.
I sent this note to Chip on contemplating the timer:
I think people would get a lot of use out of it. I also think people will want a lot more. Could be can of worms. I personally think that (timer interrupt) could help with users using a supervisor COG to make tasks.
The task case is an easy one for me. Makes great sense. A general expansion? I don't know, but I will absolutely give it a go.
The P1 is awesome. Over his career, Chip has made great stuff.
10. If it's horrible, it can be ripped out too, or modified.
For me then, onward! Let's check it out. Chip is no fool here.
I'm not the sharpest pencil in the box but my understanding on the new feature is that if you don't want to use it, you don't have to and you really won't even know it is there. It adds some very interesting and flexible capabilities if you do choose to use it with minimal impact on chip resources.
It does challenge the Propeller philosophy a bit. I don't have strong feelings on this either way.
I think the positive potential (far?) outweighs the negative the way it has been implemented.
Chip, I see the Cog byte sized addressing in your code. Is that just an assembly thing or is the machine code actually encoded that way too?
Yeah, that change made a whole lot of things simpler. All addressing is bytes. I'm struggling to find the post in this mess of development threads, but the overall pain was how to match up addressing and make things mesh in HUBEXEC land, among other things.
When we get to Pnut.exe perhaps a directive can toggle addressing to longs for ease of coding for those who have come from P1.
I've just checked the two instructions he used and it looks a bit like both machine encodings in Cog space might be used, ie: Depending on the instruction the Cog may use long addressing for some instructions while for others byte addressing is direct encoded.
This leads to the next question: What happens when addressing a non-long alignment in Cog space?
Here's how the instructions wound up:
1101011 00L CCCC 000000000 000110xxx
xxx000 INTX D/# (start interrupt on every D/# clocks)001 INTPX D/# (start any-edge interrupt on pin D/#, Q captured for hold-off count)010 INTPR D/# (start pos-edge interrupt on pin D/#, Q captured for hold-off count)011 INTPF D/# (start neg-edge interrupt on pin D/#, Q captured for hold-off count)100 INTRO (start interrupt on transfer rollover, allows background Goertzel)101 INTBW (start interrupt on block wrap, allows background video/streaming with FBLOCK)110 ISTOP (shut down the interrupt system)111 IFREE (allow interrupt, the case after INTX..INTBW)111 ILOCK (don't interrupt, any intervening interrupt will be held off until IFREE)
For IFREE, immediate d[0]=0For ILOCK, immediate d[0]=1
Interrupts? What interrupts? I thought we were talking about a hardware initiated event switch or vectored jump!
I find it highly amusing that people preached against interrupts for the entire time I've been on these forums and now they become a great new feature of P2!
Ditto!
LOL, Thritto. Coming up next, maybe a small ARM0+ can be fitted as the hidden 17th CORE?
Seriously, this simple, brief excursion and five-finger discount grab from the Dark Side may make the Prop2 far less Alien to many folks who are going to instantly compare it against the P1.
People are instantly going to dismiss it as not having interrupts, until someone pops up and points out, No, the P2 supports Interrupts!
Now, the P2 should be able to marketed as one of the few uC available that can support Standard Interrupt and Non-Interrupt programming methodologies.
I don't think you missed it, I think Chip just mentioned it and it stuck.
There's a post several pages back where he say the interrupt itself just stuff a LINK $1F4,$1F5 into the pipeline and from then on, $1F5 was the interrupt vector and $1F4 became your P counter to return to.
He then provided this code as an example
On each interrupt, a 'LINK $1F4,$1F5 WC,WZ' instruction is mux'd into the pipeline.
Here is how you could make a round-robin timed task switcher:
' Interrupt routine - $1F5 always points here' $1F1..$1F4 contain C/Z/PC's for different tasks.' Task is switched on each timer interrupt.
intcode mov temp,$1F4 mov $1F4,$1F3 mov $1F3,$1F2 mov $1F2,$1F1 mov $1F1,temp jmp $1F4 wc,wz
Which make me wonder did $1F6 and $1F7 become sometime special registers. They aren't special on the last instruction set:
You set $1F5 with the address (and optionally initial C/Z). See this example here. Note that, in the case of pin interrupts, you must also first use SETQ to avoid spurious interrupts.
I think people would get a lot of use out of it. I also think people will want a lot more. Could be can of worms.
All the other stuff aside, the moment that Parallax released the original Propeller, it opened a can of worms in terms of a desire for more. Propeller 2 will be the same regardless of how many features Chip can cram in there.
Specifically addressing the P2 "hot" tasking hardware, I think this is a better approach. Why? Because it comes close to providing 80% functionality with only 20% complexity. This interrupt mechanism does not pretend to be a full-blown interrupt subsystem (no vector tables, no inerrupt priorities, and no "you can only do xyz with interrupts" mentality). I think that the tasker hardware in P2 hot, for what did provide, did not meet that 80/20 mark.
Personally, I think this simple interrupt capability will make the P2 a serious competitor with more traditional architectures. But not because it's now more capable (though that helps). It's because it provides familiarity to a tremendous number of people that would not have given the P2 a second thought otherwise. And when those people discover that P2's simplified "interrupt" approach is made possible in part by the larger Propeller architecture and philosophy that we all love, I think those people will embrace it instead of going back to "the old way".
Chip,
How difficult would it be to capture CNT when the interrupt is triggered (as opposed to when the LINK is inserted)? This would allow the interrupt handler to compensate for the variable latency. Maybe the C or Z flag in GETCNT could be used to get this value instead of the normal CNT?Another, very similar, approach would be to make the buried counter readable (writable?), which would allow progress. as a percentage of INT frame to be checked at any time.
If the CNT opcodes (including WAITCNT) could easily mux to either (currently buried) INT counter or global counter
(Or maybe that is what you meant ?)
Better to have no latency jitter, but this may give a work-around.
Comments
Chip, I'm sure you meant how you were interrupted from streamlining the Verilog to answer a few questions when you said "interrupts".
Thanks for spending some time with us....now, back to work!!!!
I think its about time to start having some serious fun with this thing, looking forward to some FPGA images.
C.W.
Now, I know this interrupt thing is kind of different, and goes against established orthodoxy, especially my own. We probably shouldn't speak about any of this above a whisper, even in our own minds, for a while. We don't need any crises of conscience at this stage of the game.
How about we bury the interrupt discussion and announcement 100 pages into a 3000+ post thread, shortly after a major forum upgrade. With a crippled forum search. They'll never find it.
(actually the forum search picks it out beautifully)
Thanks for the logic traces Chip. Sums it up very nicely. Its great that tasking may be possible too
Now, I know this interrupt thing is kind of different, and goes against established orthodoxy, especially my own. We probably shouldn't speak about any of this above a whisper, even in our own minds, for a while. We don't need any crises of conscience at this stage of the game.
How about we bury the interrupt discussion and announcement 100 pages into a 3000+ post thread, shortly after a major forum upgrade. With a crippled forum search. They'll never find it.
See, all you naysayers, ne'er do wells and assorted nattering nabobs of negativism!!!! Parallax did have a grand strategic plan for all of the recent changes!!!!
Thanks for pointing this, now obvious, plan out, Tubular!
How difficult would it be to capture CNT when the interrupt is triggered (as opposed to when the LINK is inserted)? This would allow the interrupt handler to compensate for the variable latency. Maybe the C or Z flag in GETCNT could be used to get this value instead of the normal CNT?
I find it highly amusing that people preached against interrupts for the entire time I've been on these forums and now they become a great new feature of P2!
I find it highly amusing that people preached against interrupts for the entire time I've been on these forums and now they become a great new feature of P2!
Ditto!
Preemptively (no pun intended), I'd like to point out that this is an entirely optional feature. If you ignore it, the P2 will behave no differently than you thought it would at the beginning of the week. I think this strikes a nice balance between traditional interrupts and polling with WAITxxx. Unlike most traditional MCUs with interrupts, the use of this feature is optional. Just another tool in the toolbox.
As has been mentioned also with table-based cog prioritization, you don't have to use it, and it is off by default.
While you could also say this about single-core microcontrollers, the (big) difference is that if you write a driver or routine for them, you don't know how it will be interrupted, and it will be up to the poor sap using it to make sure it all works together.
With the propeller, if you write a driver or routine, you can be pretty sure that you have 100% of available cycles on that cog - if the poor sap modifies it to add an "interrupt", that's on him, and with 16 independent cores, there should be no need to do so. The only use of this feature that I see is integrated with the driver/routine in the cog, not separate from it... but I'm sure we'll find uses for it that no one is currently envisioning.
-David
I would take the tasker feature in the "hot" chip over this in a quick, easy minute. But that's not an option on this design path. I don't know why. As for "great new feature!" I personally see the timer interrupt as necessary given how this design is playing out. The rest? meh It's gonna have to play out in FPGA land to know anymore than that.
But I'm in, and have been for years, to see this actualized. That has not changed. If this is necessary, then let's make it as robust, simple, pain free, etc... as possible. Not my call.
So in the back of my mind:
1. Was it too hot to do it that way, like did we learn process limits favor an interrupt structure at some performance level or other? This warrants a serious discussion. It's been on my mind for some time.
2. There are specific design visions for the P2, and given those same limits, this is how to get them.
3. Now it's going to play out. All of those who said, "it's just an option" get it. Sweet, right? We shall see whether or not the general utility of the P1 carries over or not. Dropping code into COGS? Maybe. Of course, HUBEXEC sort of already broke that barrier down somewhat. We have yet to see what a smart pin really is and that may favor this path strongly. I don't know.
Maybe adding HUBEXEC more or less changes the dynamics to a point where the strict isolation of the P1 really doesn't make the same sort of sense. That has been on my mind since P2 "hot" too, though it wasn't any sort of driver to favor interrupts.
4. Without the tasker, I think we need 'em. It's that simple. These P2 COGS cannot do the sorts of things the "hot" P2 COGS did. And having been there, it's compelling. Compelling enough to rethink things, and that's precisely what Chip did. A lot of stuff got stripped away on this design. Arguably, stuff that should be.
5. They (interrupts) are, or can be, contained in a COG and used to improve on what a COG can do as a COG just as much as they can be a mess of code sprinkled around in HUB nobody wants to sort through.
The source, vector, and mechanics of how they work is portable across COGS, so "drop code into a COG", even while another program is running, is still possible as we saw it on P1. So, doing things like dropping in TV or VGA, or maybe USB, into a program isn't going to be harder than it is on a P1, unless... Say those things are written with or that require some HUBEXEC code. Now it's more like ordinary CPU designs where a memory map, etc... are going to need consideration. Where it can be packed into a COG only, not a lot changes.
As an example: WAITVID is gone, replaced with a more general purpose thing FIFO / STREAMER. We are going to really like this, because it goes both ways, in and out.
One of those interrupt sources is a block wrap trigger on the FIFO / STREAMER. (I don't know what we call 'em, because Chip has not told us enough yet) If we are going to do more in software, and the hardware is more general purpose, that interrupt source means being able to implement the cool WAITVID stuff needed to produce great video in simple, robust ways like we do on P1, as just one example. Just saying...
Think about it. Without it, the COG will do nothing but monitor the thing, and make changes as needed, doing little else. With it, one can implement what a WAITVID was, and a P2 COG can do more and do it in a way more like a P1 COG does, with the benefit of a much more general purpose hardware feature than WAITVID.
That's how I see these personally. If I'm right in that assessment, then we need them on this design path.
6. The TIE toggle might be a problem. Would still prefer two explicit instructions, or an optional state bit, so that it either toggles, or just sets on or off, so that known state points can be established. The toggle will require parsing all the way back to the initial state to debug. I always sort of disliked toggles for this dynamic.
7. It's Chip's chip. I'm in, until it makes sense not to be. So, when we get an image to jam on, the mess or not will be quickly known then. It's been a long journey. I'm going to stick it out, because I believe in what Chip wants to get done here. And what I see is the "orthodoxy" may just be getting in the way of that, and if so, at considerable expense. On this, again, I don't know.
8. I very strongly suspect some great stuff is going to be learned on this one. Let's just say, orthodox code is going to compete, and I'm very interested in seeing that all play out.
9. Again, we've not seen what a smart pin is. Some things we consider difficult, or let's say require easy, strict determinism, just might not require that anymore. We do know there is smart mode and not smart mode now. When a pin is not smart, the usual rules on P1 are going to apply. When a pin is smart? I don't know.
I sent this note to Chip on contemplating the timer:
I think people would get a lot of use out of it. I also think people will want a lot more. Could be can of worms. I personally think that (timer interrupt) could help with users using a supervisor COG to make tasks.
The task case is an easy one for me. Makes great sense. A general expansion? I don't know, but I will absolutely give it a go.
The P1 is awesome. Over his career, Chip has made great stuff.
10. If it's horrible, it can be ripped out too, or modified.
For me then, onward! Let's check it out. Chip is no fool here.
It does challenge the Propeller philosophy a bit. I don't have strong feelings on this either way.
I think the positive potential (far?) outweighs the negative the way it has been implemented.
Yeah, that change made a whole lot of things simpler. All addressing is bytes. I'm struggling to find the post in this mess of development threads, but the overall pain was how to match up addressing and make things mesh in HUBEXEC land, among other things.
When we get to Pnut.exe perhaps a directive can toggle addressing to longs for ease of coding for those who have come from P1.
I've just checked the two instructions he used and it looks a bit like both machine encodings in Cog space might be used, ie: Depending on the instruction the Cog may use long addressing for some instructions while for others byte addressing is direct encoded.
This leads to the next question: What happens when addressing a non-long alignment in Cog space?
The two LSBs are ignored.
1101011 00L CCCC 000000000 000110xxx
xxx000 INTX D/# (start interrupt on every D/# clocks)001 INTPX D/# (start any-edge interrupt on pin D/#, Q captured for hold-off count)010 INTPR D/# (start pos-edge interrupt on pin D/#, Q captured for hold-off count)011 INTPF D/# (start neg-edge interrupt on pin D/#, Q captured for hold-off count)100 INTRO (start interrupt on transfer rollover, allows background Goertzel)101 INTBW (start interrupt on block wrap, allows background video/streaming with FBLOCK)110 ISTOP (shut down the interrupt system)111 IFREE (allow interrupt, the case after INTX..INTBW)111 ILOCK (don't interrupt, any intervening interrupt will be held off until IFREE)
For IFREE, immediate d[0]=0For ILOCK, immediate d[0]=1
How do you tell it where to jump to on interrupt?
I find it highly amusing that people preached against interrupts for the entire time I've been on these forums and now they become a great new feature of P2!
Ditto!
LOL, Thritto. Coming up next, maybe a small ARM0+ can be fitted as the hidden 17th CORE?
Seriously, this simple, brief excursion and five-finger discount grab from the Dark Side may make the Prop2 far less Alien to many folks who are going to instantly compare it against the P1.
People are instantly going to dismiss it as not having interrupts, until someone pops up and points out, No, the P2 supports Interrupts!
Now, the P2 should be able to marketed as one of the few uC available that can support Standard Interrupt and Non-Interrupt programming methodologies.
Very Good Job Chip!
How do you tell it where to jump to on interrupt?
I don't think you missed it, I think Chip just mentioned it and it stuck.
There's a post several pages back where he say the interrupt itself just stuff a LINK $1F4,$1F5 into the pipeline and from then on, $1F5 was the interrupt vector and $1F4 became your P counter to return to.
He then provided this code as an example
On each interrupt, a 'LINK $1F4,$1F5 WC,WZ' instruction is mux'd into the pipeline.
Here is how you could make a round-robin timed task switcher:
' Interrupt routine - $1F5 always points here' $1F1..$1F4 contain C/Z/PC's for different tasks.' Task is switched on each timer interrupt.
intcode mov temp,$1F4 mov $1F4,$1F3 mov $1F3,$1F2 mov $1F2,$1F1 mov $1F1,temp jmp $1F4 wc,wz
Which make me wonder did $1F6 and $1F7 become sometime special registers. They aren't special on the last instruction set:
-- addressable registers
--
-- addr read write name
--
--
-- 000-1F7 RAM RAM
--
-- 1F8 PTRA RAM+PTRA PTRA
-- 1F9 PTRB RAM+PTRB PTRB
-- 1FA INA RAM INA
-- 1FB INB RAM INB
-- 1FC RAM RAM+OUTA OUTA
-- 1FD RAM RAM+OUTB OUTB
-- 1FE RAM RAM+DIRA DIRA
-- 1FF RAM RAM+DIRB DIRB
How do you tell it where to jump to on interrupt?
You set $1F5 with the address (and optionally initial C/Z). See this example here. Note that, in the case of pin interrupts, you must also first use SETQ to avoid spurious interrupts.
All the other stuff aside, the moment that Parallax released the original Propeller, it opened a can of worms in terms of a desire for more. Propeller 2 will be the same regardless of how many features Chip can cram in there.
Specifically addressing the P2 "hot" tasking hardware, I think this is a better approach. Why? Because it comes close to providing 80% functionality with only 20% complexity. This interrupt mechanism does not pretend to be a full-blown interrupt subsystem (no vector tables, no inerrupt priorities, and no "you can only do xyz with interrupts" mentality). I think that the tasker hardware in P2 hot, for what did provide, did not meet that 80/20 mark.
Personally, I think this simple interrupt capability will make the P2 a serious competitor with more traditional architectures. But not because it's now more capable (though that helps). It's because it provides familiarity to a tremendous number of people that would not have given the P2 a second thought otherwise. And when those people discover that P2's simplified "interrupt" approach is made possible in part by the larger Propeller architecture and philosophy that we all love, I think those people will embrace it instead of going back to "the old way".
How difficult would it be to capture CNT when the interrupt is triggered (as opposed to when the LINK is inserted)? This would allow the interrupt handler to compensate for the variable latency. Maybe the C or Z flag in GETCNT could be used to get this value instead of the normal CNT?Another, very similar, approach would be to make the buried counter readable (writable?), which would allow progress. as a percentage of INT frame to be checked at any time.
If the CNT opcodes (including WAITCNT) could easily mux to either (currently buried) INT counter or global counter
(Or maybe that is what you meant ?)
Better to have no latency jitter, but this may give a work-around.