Support and General Use > Recording

Recording Enhancements Pack

<< < (150/189) > >>

jhMikeS:

--- Quote from: petur on April 16, 2007, 02:58:37 AM ---/me gets slightly worried when he also sees http://taperssection.com/index.php/topic,83004.0.html... Probably also using REP though...


--- End quote ---

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.

Navigation

[0] Message Index

[#] Next page

[*] Previous page