Norns shield glitches in recordings when recording with tape

zebra · 2022-01-30T02:59:22.285Z

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

infinitedigits · 2022-01-30T03:06:58.927Z

thanks @zebra, I will check the cards and monitor the xruns!

zebra · 2022-01-30T05:36:22.634Z

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.

infinitedigits · 2022-01-30T14:49:49.475Z

zebra:

or you know, just swap their roles i guess?

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.

as for the disks:

“norns 1” (the one that had glitches):

original_921c48f3-5b7f-498a-b56b-7784fada3ed4_PXL_20220130_1416041091259×944 90 KB

“norns 2”:

original_66f217d4-ad84-4b29-b856-4329f677b181_PXL_20220130_1415247601016×762 53.8 KB

zebra:

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.

oh sorry! I took that picture in ableton and it does seem to be a visual interpolation:

ableton:

image1236×488 34.8 KB

audacity:

image1881×784 16 KB

zebra:

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.

yes this is possible.

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.

zebra:

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?

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.

EDIT:

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):

image1298×481 31.5 KB

and “norns 2” (which is now the one doing softcut recording and sending its output to “norns 1”) still has no glitches:

image1046×458 31.3 KB

this seems to indicate its not a softcut issue…maybe be sd card then? I’ll try popping the “norns 1” sd card with something else.

Na0s · 2022-01-30T17:23:36.711Z

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.

SimonKirby · 2022-01-30T18:15:29.767Z

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).

infinitedigits · 2022-01-30T20:20:21.802Z

Na0s:

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?)

yes, the old shield (mine is 200323) does have little pulses of noise that peak (very soft…I can only see if I amplify the signal by 30 dB. the noise floor is even lower though).

in contrast - the new shield has a super flat noise floor - no spurious peaks.

here’s a plot:

signal1325×606 163 KB

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.

Na0s:

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?

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.

SimonKirby:

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

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.

zebra · 2022-01-31T00:29:22.329Z

just to be clear, this thread is now about at least 2 different issues.

Na0s · 2022-01-31T04:28:35.950Z

infinitedigits:

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.

Unfortunately I don’t have a perfect list or memory. But the only scripts I’ve used enough to be certain I’ve had this issue with are: Barcodes, Granchild, Silos, & Cheat Codes (1&2).

infinitedigits:

yes, the old shield (mine is 200323) does have little pulses of noise that peak (very soft…I can only see if I amplify the signal by 30 dB. the noise floor is even lower though).

Copy that. There were times when I thought I could hear them but looking back on it, it was probably just the other little glitch sounds occurring at the same time as the meters peaked.

zebra · 2022-01-31T06:43:27.354Z

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.

github.com

monome/norns/blob/main/crone/src/Tape.h#L166-L172

      
        
            #if 0 
                                std::cerr << "Tape: writer overrun: " 
                                          << bytesAvailable << " bytes available; " 
                                          << bytesToPush << " bytes to push; "
                                          << numFramesCaptured << " frames captured" 
                                          << std::endl;
            #endif

i think that would be the thing to capture and report.

infinitedigits · 2022-01-31T22:35:59.744Z

zebra:

i think that would be the thing to capture and report.

I recompiled with those lines to report tape overruns, but nothing appeared.

I replaced my card on “norns 1” (bought another of the exact same card that is in “norns 2”) and situation has improved. I was getting ~20 glitches / hour. now its ~3 glitches / hour.

1131510×445 33.7 KB

seems like SD card is very likely the culprit and replacement was a decent fix for me.

zebra:

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.

yeah no need! SD cards do seem really finicky - I bought the same exact card (though ~6 months apart) but one still behaves better (no glitches) than the other (very few glitches). weird!

anyways I’m perfectly happy with this solution.

if anyone wants to check their audio files for pops, here’s the super simple python script that made those plots: findpops.py · GitHub

(maybe relevant too: and here’s the super simple python script that can find and excise pops: depop.py · GitHub)

awwaiid · 2022-02-01T00:04:05.499Z

For those two sdcards, here is a doc on u-1 vs u-3. Spoiler - u-3 has 3x faster write speeds.

lapseoftheshutter.com

U3 vs U1 SD Card Ratings: What’s the Difference? – Lapse of the Shutter

vires · 2022-02-06T18:54:29.780Z

Hi! New member here - interesting thread.

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

awwaiid · 2022-02-26T05:28:23.395Z

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

zebra · 2022-03-15T21:18:10.129Z

[mod hat] i am moving some posts here, even though they are about playback glitches instead of recording, some of the info above seems potentially helpful.

vires · 2022-03-15T16:43:21.056Z

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

zbs · 2022-03-15T19:26:21.764Z

what is “the tape app”? I wonder if you’re looking for a different thread?

vires · 2022-03-15T19:49:32.654Z

Screen Shot 2022-03-15 at 3.48.01 PM1075×410 61.1 KB

Sorry @zbs - wasn’t sure what to call this. What is the proper terminology for what to call this page/feature of the norns system?

zbs · 2022-03-15T19:57:35.511Z

Nothing to apologize for! that’s usually referred to as the tape page / tape, and it’s persistent no matter what script you’re running. while app/script usually refers to the program you’ve loaded up.
That offset behavior is really weird. I’m still a bit confused though - ~~the tape page doesn’t loop, it just plays back or records one file at a time.~~

edit: nope, i am wrong, sorry. I am clearly too distracted to provide good help so I’ll step back

mei · 2022-03-15T20:10:55.003Z

i’m not on the most recent update yet, but at least on my shield the tape does loop when you play back a file; i thought that was always intended behavior?

@vires i can confirm that on my 2020 diy shield what you’re describing does not happen for me, looping seems fine with no dropouts and the time on the files seem right, to me