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]

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

Yeah, that's actually me again... I'm back to the regular build for now.

[Mmmm]

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.

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

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

[Mmmm]

Hmmm Mike, just realized that to test this I am going to have to have an optical input signal.. but I have nothing that can give me one.....
Just to check, If I can find an input , on your recording utility the uppermost bar (pcm) is the one that I should be looking at right?

If I cant find any optical input its going to have to be down to people to test some things out for me... any volunteers?

[Mmmm]

Ok, a slightly modified version of the REP in my sig (some yields() included)... Needs lots of testing from as many people as possible to find out if I've fixed it or not...

This build includes JSMikes recording debug screen which is activated by toggling the remote lcd on and off while you are recording (Vol - key on remote, press stop to exit the debug screen). I think that on this screen you should see the top bar staying on 0. if it changes there could be a problem... This screen is a bit new to me so cant be certain.
You can obviously still record as normal....

If any errors or dropped samples come up with this build then post here and I'll try something else...

[petur]

I've just looked at the REP patch for the first time and I'm wondering:

1) where does the changed dB conversion come from. I once committed changes to that (from Vinylivo), and I wonder it this reverts to the old values or is a new fix that results in more accuracy?

2) I'm thinking of moving the peakmeters below the last line and add a simple if(LCD_HEIGHT > xxx) to double the peakmeter height. That will also leave a nice upper-right corner for a REC/PAUSE symbol.

More recscreen layout changes should wait until after the viewport stuff, and it should go towards a WRS

[Mmmm]

I've just looked at the REP patch for the first time and I'm wondering:

1) where does the changed dB conversion come from. I once committed changes to that (from Vinylivo), and I wonder it this reverts to the old values or is a new fix that results in more accuracy?

I dont know.... The histogram etc patch came from Vinylivo and I haven't really looked carefully at it (apart from a couple of cosmetic changes).  The changes for the DB values are as they were in his latest version which was quite a while ago.. Maybe they are an update to his update... It'd be odd if he reverted the change, can't think how that would've happened.

2) I'm thinking of moving the peakmeters below the last line and add a simple if(LCD_HEIGHT > xxx) to double the peakmeter height. That will also leave a nice upper-right corner for a REC/PAUSE symbol.

Double the peakmeter height? you mean to 4x font height? if(LCD_HEIGHT > xxx) already exists in the present svn code. (the recorder only gets a single height peakmeter).
Personally, I like the present placing of the peakmeter. It breaks the screen up a little...makes it look more interesting.

More recscreen layout changes should wait until after the viewport stuff, and it should go towards a WRS

Ahhh yes...WRS.... that would pretty much make the REP completely redundant...That's what we want!

[bugg100]

Hey Petur & Mmmm,

I'm the person with a h320 that has also gotten the  same errors as Chuck.  

I've gotten the errors in different recording sessions.  My drive is 80% filled and I am using Paulheu's most recent build (mid Feb.) with REP.  Analog of course.......  I am not sure if any optical issues apply to these errors.....

I will pay closer attention to this thread and not at tapperssection.com, so the people ACTUALLY addressing my problems (rockbox & REP devs) have less steps out of there way.

Thanks are in order, as always, for rockbox development.

Joe

[petur]

I've gotten the errors in different recording sessions.  My drive is 80% filled and I am using Paulheu's most recent build (mid Feb.) with REP.  Analog of course.......  I am not sure if any optical issues apply to these errors.....

H3x0 has no optical, as you know

I will pay closer attention to this thread and not at tapperssection.com, so the people ACTUALLY addressing my problems (rockbox & REP devs) have less steps out of there way.

I try to monitor here and at taperssection, but for support issues this forum is the best place.

[Mmmm]

I've gotten the errors in different recording sessions.  My drive is 80% filled and I am using Paulheu's most recent build (mid Feb.) with REP.  Analog of course.......  I am not sure if any optical issues apply to these errors.....

Interesting...so it seems it is not optical only which means that I should be able to test a bit myself..... and Feb I think was before I did the last major update...(could be wrong though, time is just flying by at the moment...).

I'll do you an H3xx build later with those yields in it for you to test with...

[jhMikeS]

Ok, a slightly modified version of the REP in my sig (some yields() included)... Needs lots of testing from as many people as possible to find out if I've fixed it or not...

This build includes JSMikes recording debug screen which is activated by toggling the remote lcd on and off while you are recording (Vol - key on remote, press stop to exit the debug screen). I think that on this screen you should see the top bar staying on 0. if it changes there could be a problem... This screen is a bit new to me so cant be certain.
You can obviously still record as normal....

If any errors or dropped samples come up with this build then post here and I'll try something else...

Yes, the top bar should pretty much stay at zero for WAV and AIFF. But one thing is using the interface to test while in the screen, say by replacing the recording screen text lines with the bars or numbers which would give more accurate results since all the screen functionality would be running too. I suppose a button could toggle what's displayed on those lines.

[Mmmm]

An H3xx build HERE

JsMikes: ahh yes...without the histogram drawing there will probably be no problems anyway eh?
Ill just butcher the first 2 lines out of the display and plonk then on the recording screen - for testing... should fit somewhere...:-/

[bugg100]

Pualheu's build most recently:

In sync with SVN at 5 Feb 18:29GMT
I am downloading the h320 build now and will test this evening.  Thanks