|
Top-level
 @neauoire audio callbacks run in a separate thread, so if you were to share a stack it would have data races and lead to unpredictable behaviour right now all audio devices share the audio stack, but this isn't a guarantee and can depend on the implementation, in any case, audio vectors should make sure they left the audio stack in the same state as they found it 13 comments
 @bd This is kind of messy, it create device specific scaffolding in uxn, could we spawn a new uxn instead, and kill it at the end of the vector? It would have its own stacks, and device page, and share access to the RAM @neauoire that's a no-go from the performance perspective, if you were to copy all the ram everytime that a vector has to be used you will drop the FPS to pretty much 0 to the best of my knowledge any cpu with multiple cores has its own stack for core so this mirrors real hardware you still have access to the ram and zero-page, and as long as no other thread interact with the memory being modified, it's safe to read/write from the audio thread see in my ex. you the zp variables progress0-3 @bd maybe I didn't explain it right, uxn instances don't have their own ram. They just have a pointer to it, I meant creating a uxn with an access to the ram, not create a copy of it. @neauoire I mean this is how it currently works, each thread has a pointer to the ram, but they have to have their own stack if execution is going to be multi-threaded we *could* create a copy of the stacks when the audio vector is called, but this doesn't solve anything, it will still be subject to race conditions and unpredictable behaviour @bd nono, I don't want to create a copy of the stack.. Like, I mean, I think we should create a new Uxn for the thread, instead of shoving the audio stacks into the main uxn instance that's evaluating the program. @neauoire the new UXN core fast implementation takes the PC vector and two stack pointers, one for wst and other for rst. Ram and stacks are globals. For the sdl implementation we can have a new instance of the UXN struct as you say, since the evaluation function takes a struct iirc. In either case the behavior is the same right? Or am I missing something? @bd It depends, why are the stacks global? Are they mapped to the ram someplace? @neauoire not really, just how I organized it for simplicity as this implementation came as a port of my ARM ASM core. I can wrap it in a struct, makes no difference @bd aah okok :) I'm just trying to find a way to explain this as simply as possible for the docs. There's antecedants where I use devices to call threads with new uxn instances with private stacks, and if the audio logic uses something similar that makes explaining this more standard than, also since the code is a source of documentation, I wouldn't want audio things in the uxn core since there's device facilities already. I'm just trying to make sense of it in my head so I can explain it too @neauoire no worries, I feel you I can clean up the code and move a few things around. Also I’ll try to help in writing the docs as I mentioned. Just want to make sure we are on the same page haha If all is good I’ll do the sdl port and there I’ll try to use the same general structure in place. Will keep an instance of audio specific UXN struct on the audio .c files @bd perfect, yeah, as much portable code as possible the better, you'll see that the sdl/x11 port have a special structure where it reuses as much device code as possible. Everything looks good on my end with the new audio device. |
Gregory's Server
@bd that's going to be hard to document properly. Lemme see, so do audio vector call create a new Uxn instance to evaluate it, or does it fork the main Uxn instance?