February

Sunday Feburary 16th

I’m glad I’m through that refactor! There’s more to do (the most exciting of which is getting rid of buffer serialization / deserialization which should speed up long renders) but python instruments are thankfully working again after tearing out all the old IPC plumbing. It’s easier to reason about IPC now, and I hope that will make building around it easier too.

Next up:

• Replace the old session value getter/setter interfaces in cython with the new IPC routines
  • For ctx.s. style interfaces
  • And any remaining internal interfaces (built-in instrument params)
• Use the session buffer aquire / release to get sampler segments in the same way as the adc ringbuffer
• Test the autotrigger interfaces in python and pick one (I am leaning towards a callback approach)
• Revisit trigger / message passing in cython
  • serial output (usb tty)
  • MIDI output (alsa MIDI)
  • (adding OSC support would be nice later too: also maybe as the way to transport messages between astrid instances over the network)

Friday February 14th

I’m still cleaning up the astrid cython module, it’s pretty exciting. I discovered a really bad aspect of the previous architecture that was difficult to see until I pulled the new Renderer class out of the catch-all Instrument. Briefly, the instrument cache was (of course, duh, it feels obvious now) local to the renderer process.

Meaning, if there’s a renderer pool of 20 renderers, then you’ve really got 20 copies of the cache. The way the cache is populated is by invoking a (user-defined) callback on the instrument module when the module is loaded or reloaded. The actual reloading is lazy, though, and needs to be provoked by a render event. Which means for 20 renderers, the cache will only be warm after all the renderers have done a render.

It’s not a big deal, but when using the cache to store ~1GB of indexed samples, that cache fill causes real latency on the render. It always felt like the cache was weirdly sticky, but of course this was the reason.

I removed it completely in favor of adding support for storing collections of buffers in the new shared resource interfaces. It could work like a graphics sprite, I think, and just use the existing C buffer storage interface. From cython take a collection of buffers and write them into a single shared buffer – storing the offsets alongside in a shared table?

Reads could be pretty efficient this way, even when needing a copy: load the table first, then use the requested index to look up the appropriate offsets, aquire the buffer in shared memory and copy the requested segment into the result.

Doing the feature in C first before I add support for python is becoming a useful way to work on astrid. It’s nice to worry about the implementation first, just get it working, and then think about a nice python interface for it and how to make that work. It’s weird for me since I tend to go the other way around usually: start with the interface I want and work backward from there. For the type of plumbing I’m doing in astrid right now though, coming from the other direction seems a little easier.

Monday February 10th

Whew – I guess I’m about a month into rewriting all of astrid’s IPC. It has been a while coming, but I’m pretty happy with the new interfaces.

astrid_shared_resource_t * astrid_session_aquire_shared_resource(astrid_session_t * session, char * name, int resource_type);
int astrid_session_destroy_shared_resource(astrid_session_t * session, char * name, int resource_type);
int astrid_session_register_shared_resource(astrid_session_t * session, char * name, void * value, int resource_type, size_t size);
int astrid_session_set_shared_resource(astrid_session_t * session, char * name, void * value, int resource_type, size_t size);
int astrid_session_get_shared_resource(astrid_session_t * session, char * name, void * value, int resource_type, size_t size);
int astrid_session_release_shared_resource(astrid_session_t * session, char * name, astrid_shared_resource_t * resource);

Those replace all the old ipc value / id / sampler interfaces that were getting pretty out of hand.

Instead these new routines all take a resource name, size and type and are backed by either LMDB storage (in a database shared across all astrid instruments) or POSIX shared memory for anything larger. For a moment I thought why not just do everything with LMDB!? Some (most? who knows) of its speed comes from storing data as cache-or-smaller-sized chunks in an optimized tree structure, and it doesn’t do very well at all with large objects getting fragmented across that tree.

The POSIX shared memory segments – and LMDB writes – are synchronized with sempahores. I have such trouble with semaphores, but I think I shook all the deadlocks out again. ;-)

I’m finally now onto the python side of this, which involves splitting the Instrument abstraction up into Instrument and Renderer. The new IPC session is stored in a astrid_session_t struct on the instrument, but can be reopened from anywhere. That’s the first real win for python: no more serialization of state just to set up the render pool. Instead, each comrade opens its own handle to the shared session, and sends renders via the same RENDER_COMPLETE messages.

This should also let me eventually… eliminate copies during the render pipeline entirely??? All renders get copied like… too many times: once to copy into an lpbuffer_t for serialization, then again when copying the serialized buffer into shared memory, then again when deserializing it…

Since the new IPC routines have proper support for shared buffers, that can come down to a single copy when rendering is complete… and when I finish porting pippi’s SoundBuffer abstraction to be lpbuffer_t-backed instead of numpy-backed (not a huge priority but this is motivating me) then renders will be… zero copies!?

That’s exciting – it’s not a huge deal, but starts to have an impact when doing lots of long renders.

(oops I missed September!)