Support and General Use > Recording
Recording Enhancements Pack
petur:
Looking at http://taperssection.com/index.php/topic,83004.0.html it seems something is funky with the REP build.... maybe the gui stuff is overloading the cpu during some peak moments?
Warning 00000001 is being mentioned in above link
jhMikeS:
If something is funky with the REP build which it seems to be, esp. for digital in users, I'd suggest mmmm take a look and make sure:
1) No threads are being boosted in priority (via thread_set_priority) as this will require the codec and pcmrec threads to also be priority boosted. This was _the big_ stability issue where the boosted pcmrec thread starved the codec. Boosting the codec thread at the same time keeps it stable since the codec cannot over the long term output data exceeding the data rate from the ADC. The empty state makes the codec yield a lot to other threads.
2) CPU frequency scaling is set to boosted at all times when running S/PDIF. Make sure no cpu_boost(false) call is made unpaired with cpu_boost(true). I wasn't part of developing the digital support itself but was told switching frequencies when recording S/PDIF is very bad and glitchy and it must not be put in a state where is goes back to actively frequency scaling.
3) That all code yields very frequently and never starves the codecs of cycles. I've mentioned elsewhere that, in SVN, running the WAV/AIFF codecs while observing the buffers - even with the CPU frequency unboosted - never showed PCM buffer usage over zero bytes. It's almost as good a situation with MP3 and WavPack. The codecs are very fast if allowed to run enough. See to it large numbers of graphics operations have yields in between each one. Putting up a quick display for debugging to watch the PCM buffer is easy...test at the highest possible samplerate, stereo WavPack and it should pass that worst case without fault.
If I think of any more points to check, I'll post.
TaperChuck:
--- Quote from: petur on April 23, 2007, 03:45:15 AM ---Looking at http://taperssection.com/index.php/topic,83004.0.html it seems something is funky with the REP build.... maybe the gui stuff is overloading the cpu during some peak moments?
Warning 00000001 is being mentioned in above link
--- End quote ---
Yeah, that's actually me again... I'm back to the regular build for now.
Mmmm:
--- Quote from: jhMikeS on April 23, 2007, 03:46:43 PM ---If something is funky with the REP build which it seems to be, esp. for digital in users, I'd suggest mmmm take a look and make sure:
1) No threads are being boosted in priority (via thread_set_priority).
2) CPU frequency scaling is set to boosted at all times when running S/PDIF.
3) That all code yields very frequently and never starves the codecs of cycles.
If I think of any more points to check, I'll post.
--- End quote ---
I suspect that no. (3) will be the one if any. I don't think that there is any extra boosting/unboosting at all in the patch so 1 and 2 are not possible (I'll check though, there may be the odd case that I havent noticed).
There is a very large amount of extra graphics code and no extra yields so I'd put my money on it being that.
It is weird that this has suddenly surfaced and there were no reports of it a couple of weeks ago - maybe it's something I did in the last update....Don't know what it could be though... Or maybe it's because people have started using more recent builds since I did the update...Arggghhhh too many possibilities.... :D
jhMikeS:
Nothing has really changed in the builds since the update that stopped problems in the SVN code that petur was reporting. The scheduler change afterward should have no effect either since priority_yield gives a thread no advantage over others that are the highest priority running - hence they stay peers anyway.
If (3) is the reason, just verify by monitoring the PCM buffer fullness on the recording screen or wherever. Not much to it really but to watch the read and write positions. If you can ever see anything more than a flicker of > 0 used when running WAV or AIFF, CPU boost or not, there's a problem. For MP3 and WavPack, the same applies when CPU boost is in effect as these can fill to 1 second which kicks the CPU boost in but they'll empty it out really fast.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version