Recording Enhancements Pack

[petur]

warning:0000001
warning:0000002

I got this on both my Mmmm Rockboxed iHP-120 and iHP-140, last week, while recording Toslink in. The warning came up in the time display on the recording screen...

Can someone tell me what this warning means?

jhMikeS can... I'll have a look at the code too. Can you please see that this also occurs with the 'official' build? Patched builds (I guess you're using REP) are not supported.

[TaperChuck]

I am running a test now, in a more controlled enviroment...  with Mmmm's build... If it happens again, I'll test with the regular build.

[petur]

in any case, those warnings indicate some serious problems (buffer overflows in PCM and ENCODER)

Do try with the latest SVN build, not Mmmm's

[TaperChuck]

  that can't be good ... The clip light came on a few times, but other than that, everthing seemed OK. I also have done the RTC mod and patch, if that info is important.

[petur]

how's your player? Disk nearly full, disk fragmented?

[jhMikeS]

The warnings as defined in pcm_record.h:

/* pcm (dma) buffer has overflowed */
#define PCMREC_W_PCM_BUFFER_OVF         0x00000001
/* encoder output buffer has overflowed */
#define PCMREC_W_ENC_BUFFER_OVF         0x00000002

As petur said and I second, please test with SVN.

PCM Buffer overflows should be nearly impossible in the newer SVN builds (post reliability fix) if not actually so even if the encoded data can't be written. I've never seen the PCM buffer fuller than 1 second with any codec at any data rate and you've got 11 seconds worth. Encoder not so much if your disk is on the slow side for some reason in which case not much can help.

More info on warnings: If both of these occurred during the same session, you would be looking at Warning: 0x00000003 since the bits OR together as problems occur.

[TaperChuck]

No, I always record on a clean drive. Plenty of room on the HD.

One thing I noticed is that my ANSR light was off on my V3 when I got home. It was on when I started recording the night this warning came up. I also had my other pre-amp, a DMIC-20, synced to the V3 via coax cable, and the recorders got off sync somewhere in the last hour of the recording.

So, for testing, I just switched the ANSR off, on the V3, to see if that warning pops up again.

Unfortunately, I don't have much more time to test today.
I'll report back if I can make the warning come up again.

[TaperChuck]

The warnings as defined in pcm_record.h:

/* pcm (dma) buffer has overflowed */
#define PCMREC_W_PCM_BUFFER_OVF         0x00000001
/* encoder output buffer has overflowed */
#define PCMREC_W_ENC_BUFFER_OVF         0x00000002

As petur said and I second, please test with SVN.

PCM Buffer overflows should be nearly impossible in the newer SVN builds (post reliability fix) if not actually so even if the encoded data can't be written. I've never seen the PCM buffer fuller than 1 second with any codec at any data rate and you've got 11 seconds worth. Encoder not so much if your disk is on the slow side for some reason in which case not much can help.

More info on warnings: If both of these occurred during the same session, you would be looking at Warning: 0x00000003 since the bits OR together as problems occur.

Thank you for the info on what the warning means. I'll have to test the SVN at another time.

[petur]

/me gets slightly worried when he also sees http://taperssection.com/index.php/topic,83004.0.html... Probably also using REP though...

[TaperChuck]

Well, I tested the the REP yesterday, recording for 8 hours, and no problems. Hopefully it was a fluke...

[jhMikeS]

/me gets slightly worried when he also sees http://taperssection.com/index.php/topic,83004.0.html... Probably also using REP though...

Frankly, I ought to have a quick look at that REP and see if there's any big nono's there.

[jhMikeS]

Come to think of it, who knows what optical might throw at it. If the CPU reports an error, it will drop stuff and who knows if something could deceive it into thinking it has finished a chunk of data too soon. Before the update I burdened flushes by just wasting so many CPU cycles they'd take over a minute to complete and I still didn't have problems so conditions on the recording side should have to be just atrocious to have any. The old problem was just the encoder being starved too much by boosting the flushing thread but they both boost now. As of now, I'm thinking the scheduler change to use priority_yield in the ATA driver could do something since we're balancing two threads to not starve one another of CPU. The codecs could use it as well to make sure they have equal footing. I've performed no evaluation of the behavior of recording since changing the ATA driver.

With optical the CPU should always be boosted as well (WAV /AIFF is practically like having nothing running at all so should never not be able to keep pace esp. boosted) and if something new in SVN messed with that, glitches will occur if it goes back to boosting dynamically as well.

[TaperChuck]

I was recording optical in on both iRiver recorders.

Mics> Grace V3 (optical)> iHP-120

SBD> modified DMIC-20 (optical)> iHP-140

It was loud, so maybe the recorders were feeling the thumping bass? They both reported errors. But, I was at the SBD position, and the I've recorded successfully, with those recorders, at much louder shows.

I had both the pre-amps sync to the V3 clock, which makes it easier to align the separte recorders for mixing. In editing, I noticed that about a third of the way through the show, the pre-amps lost sync, with the audience recording on the V3 running increasingly behind the SBD recording. I figured it was from dropped samples  

If it happens again, I will report back.

[jhMikeS]

Your problems point to encoder starvation since the only possible way the PCM buffer could overflow is if something is keeping the encoder thread from running enough....period.

Some counterintuitive points:
You could get an encoder buffer overflow and not a PCM overflow because the codec is starved and then dumps a huge payload on the output all of a sudden when flushing is starting because it starts encoding data rapidly when the PCM buffer is _nearly_ full. The starvation can disappear as flushing waits in the ATA driver and starts yielding alot.

To maintain stability the PCM buffer must be maintained nearly empty all the times then when the codec gets a lot of run cycles it only dumps a small quantity into the output when the flushing is able to do nothing more than wait for a disk spinup.

I will, right now, give a check on the thread stuff. The pcmrec and codec threads really have to be peers and the ATA change may have affected that.

[jhMikeS]

Sorry to go on and on here  

There are some more possibilities with S/PDIF recording:
1) An series of errors not being read as an errors when the boxes lost sync advanced the queue very rapidly leading to PCM buffer overflow - this will cause mega glitches or a jump in time and symptoms very much that same as starved encoder.

2) Your unsynced clocks have slightly different samplerates - No glitches or errors, just drift over time when both files are played back using the PC soundcard clock.

BTW: My checks show the threads to still be peers in SVN.