TAPE noise

[catfact]

i heard the noise explosion after recording 4 minutes of audio to TAPE. successive TAPE recordings are all noise, even if short.

[simonvanderveldt]

Can confirm, don't have full steps to reproduce but I made a 10 minute recording of Awake with all "out of the box" settings (using the image provided by @tehn) then played it, put tape's volume up and after +-2 to 3 minutes I got static/noise as well. It's purely coming from tape, turning tape's volume down turns down the noise.

Can't find anything about the playback causing issues in the logs, but I did get a lot of

Mar 09 00:06:51 norns crone[11597]: Tape: writer overrun

when recording. I only checked the logs from norns-crone which I think provides the tape functionality.

[catfact]

ok, that msg means that for whatever reason, the disk writer thread can't keep up with incoming audio. will try more buffering and bigger write chunks or something.

[simonvanderveldt]

So that message wasn't there for fun :P The audio written to the file contains the noise/incorrect data it seems

[okyeron]

I think we also have the reverse of this previous problem: https://github.com/monome/norns/issues/673

The file format appears to be WAVE, but the extension is written as AIFF (causing the file not to open in QuickTime in one case)

[tehn]

file extension is a simple fix (sorry!) will PR

[catfact]

can't reproduce on x86 with SSD (many attempts of sequential recordings of 10-40+ minutes), using OSC interface directly with crone.

will try on hardware / with menu...

the fact that recordings after the first are borked from beginning, strongly suggests the application state is being left in a bad way.

hard to imagine a platform discrepancy doing this, easier to imagine some incorrect sequence of commands doing it. should add better error handling. would appreciate help double-checking the glue from menu -> crone.

[tehn]

i'll double-check the OSC event order in crone to see what gets printed in the OSC debug

the process is:

• open file (arm)
• start recording
• stop recording

https://github.com/monome/norns/blob/dev/lua/core/menu.lua#L1433

[catfact]

i dunno, menu -> module -> weaver -> oracle looks normal.

[catfact]

also, user said they got a float32 file. i don't know if this is true; if it is, something is very wrong. i'm requesting 24b fixed PCM from libsndfile, and this is what i'm getting on x86 debian:

Input #0, wav, from 'tape-test-7.wav':
  Duration: 00:15:54.47, bitrate: 2304 kb/s
    Stream #0:0: Audio: pcm_s24le ([1][0][0][0] / 0x0001), 48000 Hz, 2 channels, s32 (24 bit), 2304 kb/s

[okyeron]

FWIW - I had that lines user send me one of the files in question and it shows up like this in one editor (Fission): Whereas in Audacity it shows this:

No idea why Audacity says 32-bit float there. Maybe yet another reason I hate Audacity.

[catfact]

did some stuff

• tested on norns hardware and indeed got the writer overrun after some period (ranging from 20s - 4m.) overruns always coincided with the onset of garbage in the audio file. subsequent recordings also garbage. i only get the overruns on norns HW, presumably because of some variability in write times for the eMMC.

• added some stuff to print more info about overruns when they happen

• did two things to prevent overruns: 1) made the ring buffer way, way bigger; 2) remove limitation on how many bytes the writer thread pulls from the ringbuf on each cycle.

• these made the o-runs go away for me; but in any case o-runs shouldn't actually result in smashing the ringbuffer with garbage. fixed that. now it will just discard the input samples if the ringbuf is full.

• also removed a behavior where the writer thread would set a flag to put itself to sleep if it was woken up with an empty ringbuf. this shouldn't happen anyways, but i don't think the behavior was helpful.

my testing time has been limited but hoping this will fix the issue generally.

[phonk]

Still getting garbage after the update, but it happens later in the recording. After that, all recordings are garbage. This is the (presumably) relevant part of the syslog:

Mar 11 22:09:51 norns crone[386]: Tape: writer overrun
Mar 11 22:09:51 norns crone[386]: Tape: writer overrun
Mar 11 22:09:51 norns crone[386]: Tape: writer overrun
Mar 11 22:09:51 norns crone[386]: Tape: writer overrun
Mar 11 22:09:55 norns systemd[1]: Started Session c3 of user we.
Mar 11 22:10:15 norns jackd[306]: JackEngine::XRun: client = softcut was not finished, state = Running
Mar 11 22:10:15 norns jackd[306]: JackAudioDriver::ProcessGraphAsyncMaster: Process error

[tehn]

successfully recorded 2 minutes of awake

started again for a much longer take and eventually:

Tape: writer overrun: 1023 bytes available; 1024 bytes to push; 26832384 frames captured
Tape: writer overrun: 0 bytes available; 1024 bytes to push; 26832384 frames captured
Tape: writer overrun: 0 bytes available; 1024 bytes to push; 26832384 frames captured
Tape: writer overrun: 0 bytes available; 1024 bytes to push; 26832384 frames captured
Tape: writer overrun: 0 bytes available; 1024 bytes to push; 26832384 frames captured

[catfact]

@tehn ok, dang. i will try harder to eliminate these, though it's not immediately clear what else to try.

but importantly, the other part of the change is the way o-runs are handled - do they still produce garbage in the recording for you? (which would be a bummer) or just dropouts? (which i would hope for)

@phonk this indicates that the code change hasn't actually been applied. belatedly i realize your forum posts indicates that you fetched the fix branch, but not necessarily that you actually checked it out.

[tehn]

well 6 minutes into the 17 minute recording it's still not 100% static so indeed perhaps just dropouts. not listening closely... will do a second pass at this--- norns battery just died :P

[catfact]

if it's not producing total garbage after the first orun, and doesn't bork future recordings, then this is a net win. (previously, we were blithely writing to a ringbuffer with no space in it. i'm surprised that jack_ringbuffer doesn't handle this more gracefully but oh well.) [BTW, i have been transferring the captured files and doing visual inspection as first step.)

the oruns themselves seem to be an eMMC symptom. they may well be happening with other recording systems like SC DiskOut. it's stupid to report them like we're doing here, on the audio thread, and the reporting will itself cause glitches, but will leave it in for now as i work on it.

ultimately, if it takes 16k audio frames worth of time to write 1k worth of input, there will eventually be overruns no matter what we do. the next thing i'll try is forcing a minimum write size. (and of course, maybe i'm doing something very dumb, stalling the writer thread, and just can't see it yet.)

if another headless recording program works better i am happy to scrap the Tape module in crone and put it on the books as a learning exercise

[tehn]

we can probably remove the reports and say it's generally ok. i listened again to the file and had a hard time noticing dropouts

[catfact]

sorry to report that still actually getting the garbage sporadically... back to drawing board.

[catfact]

ok, belatedly noticed a dumb error in disk thread. standby...

[catfact]

the PR above fixes the meltdown as far as i can tell. (have tested pretty extensively on norns HW, recording up to the limit of disk space)

[simonvanderveldt]

I'll try to get some tests done on your branch this evening as well

[simonvanderveldt]

Recorded +-14 minutes, looking good so far

No errors in the logs either (this is on a CM3+ btw, not sure if relevant):

Mar 14 03:24:33 norns crone[365]: osc rx: /tape/record/open
Mar 14 03:24:35 norns crone[365]: osc rx: /tape/record/start
Mar 14 03:38:40 norns crone[365]: osc rx: /tape/record/stop
Mar 14 03:38:40 norns crone[365]: Tape: fade-out finished; stopping
Mar 14 03:38:40 norns crone[365]: Tape::writer closing file... done.

Listened to the recording both on norns and on my desktop just to confirm and no noise issues.

[catfact]

nice, thanks.

this is on a CM3+ btw, not sure if relevant

definitely could be, since the first cause of the overruns appears to be the eMMC itself... (or like, the firmware for NAND access?)

[simonvanderveldt]

If you want I can try on the regular CM3 tomorrow, don't have a screen on that one though, so have to figure out how to trigger the recording (probably by sending an OSC message?)