I’ve been having some problem with recording to tape in norns shield.
Basically after a few minutes of recording it tends to skip recording for a bit, causing a glitch.
First I thought this was due to certain scripts being loaded, but it also happens when I don’t load up anything and just recording incoming audio.
Could this be a shitty SD card? I am using a MediaRange 16gb class 10 SD card, quite new.
Here’s a bit of audio, glitch happening at 0:02 and 0:06
Any log I could read to see what went wrong?
Thanks in advance!
I can add a datapoint here, but I don’t have any solutions.
I recorded about 4.5 hours of audio through TAPE on two norns shields simultaneously. I have audio coming into norns 1 (newer norns shield) which is being recorded using TAPE. the output of norns 1 is going into norns 2 (older norns shield). norns 2 routes the audio into an engine (and mutes the incoming line-in monitor) and records the engine output using TAPE. both norns 1 and norns 2 have the same software, are the same raspberry pi, and are using the same voltage supply (CanaKit 2.5A).
in this setup, norns 1 is creating glitches in the recorded audio. norns 2 is not creating a single glitch in its recorded audio. the glitches happening in the recording on norns 1 do not happen frequently, probably every 10 minutes there will be a few glitches spaced ~minute apart.
again the main difference (I think) is that norns 1 is recording from line-in and norns 2 is recording from the engine (the line-in is turned all the way down). could it be a issue between recording from line-in vs recording from an engine? (the audio source is the make noise strega…I’ve never heard it create a glitch on its own so I don’t think its the audio source thats the issue either).
I’m open to troubleshooting ideas. right now I’ve just been post-processing them away. I’m not sure what it is - norns 2 is running tapedeck which takes a lot of cpu and is having no problem. norns 1 is running a softcut recording program with all six voices enabled but only one recording at a time…and no engine…so norns 2 has less CPU available but it has never glitched…
here’s the two TAPE recordings from norns 1 and 2 side-by-side, with the red arrows pointing to where the glitches occurred in the recording from norns 1.
Occam’s razor suggests some characteristic of storage media. I doubt it’s dropped sample from ADC (but I guess it’s not impossible.) Suggest watching journalctl for jack xrun warnings. (Or use newly added jack_cpu_capture tool.) I predict glitches will not actually be correlated with xruns, suggesting disk access issue
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?)
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.
I went ahead and tried this. I’ve recorded about 10 minutes and had no glitches on either. I just realized that I can record a whole bunch of audio and use that stft depopping we wrote to automatically do this detection. I’ll collect some data doing that.
however, if this is the case, the glitch is likely getting filtered out - my setup exists so I have a “dry” signal (norns 1) and a “wet” signal (norns 2). norns 2 is processing the signal with the engine (fx including filters) and I neglected to mention that the audio is passing through a reverb between norns 1 and norns 2. so from my setup it wouldn’t be easy for me to distinguish if the glitch is passing through to norns 2 since its very likely getting washed out in the reverb/filter fx. when I do the long sampling I’ll just make everything dry.
norns 1 is not doing any disk access. norns 1 has softcut simply recording one voice at a time for the first minute, and then for the rest of the time it is just sending crow signals and doing softcut playback - no further recording, no softcut rate changing, softcut filters are dry. the glitches don’t seem to be co-localized with the “recording” or “playback” - it seems to be random. and also it seems to be sporadic as I can record for 5 minutes without any glitches, and then record another 5 minutes and have 3 glitches.
I’ve removed the effects between norns 1 and norns 2 and I’ve swapped them. so now “norns 2” is doing the softcut recording (and recording to its TAPE) and “norns 1” is receiving the audio from “norns 2” and doing nothing (no tapedeck / no effects) and recording to its TAPE.
it looks like in this case, “norns 1” (which is now receiving audio from “norns 2”) is still getting glitches in its recorded audio (audibly and also measured using the stft):
My Norns shield has also suffered from similar glitching. Its the older board revision and my power supply is 5.25v 2.4A but I’ve experienced the issue on a number of different PSUs. It generates little pulses of noise on the meters even when nothing is running (which I think is known to be clock bleed from the LCD driver?) but additional to that when processing incoming audio I frequently get those same little glitches. It doesn’t seem to be a problem when using a saved audio file and a softcut script so I think my issue, at least, originates at the Input jack?
I’ve looked at using Connect-OPz or some mod to run audio thru an audio interface but its too much trouble so I find I just don’t end up using my Norns.
For what it’s worth, I’ve had a similar issue with my first gen Norns shield with recording line in to tape. No problem on the directly monitored audio, very occasional tiny glitches on the tape recording. I’ve not noticed it on any recordings that aren’t using line in (but not done that many of them so can’t be sure that’s a real difference).
honestly both are totally fine for me, I only had some trouble with the old shield transients when I was trying to do some onset detection. but (for me) its impossible to actually hear those -30 dB transients.
that’s interesting. does it happen with a particular script or no script at all? some scripts are cpu-intensive and when SuperCollider maxes out it is prone to making sounds that could be called “glitch” sounds or “crunch” sounds. that would be a script-dependent issue I would think though.
ah that’s interesting too. I’ve only ever used line-in. but It could be a sampling problem - it sometimes take 15 minutes before I get any glitches (and its still only happening with one particular shield - the newer one actually - and not the other…).
I have a new SD card coming tomorrow so I will try that.
yeah the natural conclusion is that it is probably the sd card (b/c of swapping the roles.)
i would try actually swapping the sd cards as well though. (or equivalently, the shield hardware.) just to eliminate some weird thing in the shield PCB/codec.
i hate SD cards for audio. not even going to get into trying to determine which ones are ok and which are garbage. they are little computers with their own firmware, and sometimes the firmware is just bad. our learning from Aleph was that it is much preferable to work with hardwired storage for realtime I/O.
so, i forgot that i actually did add an overrun check to Tape, but it is ifdef’d out.
i think that would be the thing to capture and report.
I’m considering the purchase of a Norns shield vs regular norns. Is it known if this issue occurs only on the shield? Or since it is looking like sd card issue, is it just as likely to occur on either?
Any advice much appreciated - I’m thankful for this community and ecosystem and glad to be joining it
In this particular case it seems it was the specific sd cards (since swapping them changed behavior more or less). I wouldn’t let this report hold you back from purchasing either based on people generally having an all-around great time with both
I am curious if anyone else is having audio dropouts in the tape app.
I’m getting some strange behavior besides the dropouts:
-The loop points (end/beginning of audio file) don’t coincide with where the counter returns to zero. So with each successive pass the minutes:seconds counter is further displaced where the audio file is playing.
-The displacement seems to happen on all included audio files, as well as newly recorded ones. The audio dropout happens on the hermit_leaves.wav at the loop point (which isn’t where the counter indicates it to be, so a little confusing).
-If anyone could confirm this is happening for them or not, I’d really appreciate it as I’m trying to figure out if there’s a problem with mine, if I need to send it in or if it’s an SD card issue