7

morethoughts:

  • since you have such a clean setup for the issue, might be interesting to just swap the SD cards in the nornses and see what happens. (or you know, just swap their roles i guess?)

BUT

  • in the second image (protools?) there is a ringing shape around the glitch. assuming that’s not some kind of visual interpolation, it suggests that the glitch occurred before some kind of (low-pass) filtering stage. maybe in softcut, maybe actually in the source before ADC capture (e.g. in norns 1 DAC output) and in fact in contradiction with my last post this would almost certainly not be originating from the tape module itself or its disk writing routines.

… but on the other hand i am confused. i think you are saying that norns 1 is doing something with softcut, recording its output, and sending the same output to norns 2. then norns 2 records that same signal processed with tapedeck or something. so we would assume that any glitch that actually ends up in norns 1 signal also would end up norns 2 tape output. that was my original assumtion, let’s call it assertion A.

A being true limits the possibilities and implies that really it must somehow be the TAPE module. but i cannot come up with any reason we would see that filtered shape unless it was something applied later (e.g. reconstruction filter from sample rate conversion on import.) that’s what makes me think that A could actually be wrong, and the glitch is in fact in norns 1 signal but processing in norns 2 is eliminating it somehow (e.g. just more aggressive filtering.)

final unconnected thought: is norns 1 softcut program also performing disk accesses? (e.g. buffer reads/writes?) if so, is the timing of these routines correlated with timing of glitch?

(disk worker is not on audio thread, so xruns / jack cpu load not likely to catch anything that is just due to disk writes stalling or failing to keep up with audio thread. [those measures will only catch the opposite situation, which actually shouldn’t result in glitches on file since disk thread waits for audio thread to signal when new samples are ready to write.] however i don’t think this feels super likely because (1) it doesn’t explain the filtering, (2) we’ve seen disk thread ringbuffer overrun before, and it tends to be a nastier glitch. still worth checking.)

i think i am going to be incorporating the cpu/jack xrun measurement tool into matron with a lua interface. (we really need convenient and accurate performance sampling going forward with audio backend changes.) i think it would be easy enough to check programmatically for disk output overruns as well.

7 Likes