Recording Enhancements Pack

[jhMikeS]

Well, looking at things in the pcm driver reveals that the S/PDIF code may in fact miss certain error conditions. I really only moved the S/PDIF driver implementation around in RB to the HAL and never changed it so this could be the answer and why digital recording seems to be where continued bug reports are coming from...notably overflows.

If an S/PDIF error is detected on the receiver, in SVN, the PCM chunk should be dropped and the queue not advanced...but if it's not detected...well...there ya go. A simple check to see if the transfer actually completed and filled the chunk might be all that's needed.

[jhMikeS]

More and more....: Hehe...seems someone set the wrong bits in the driver.

[TaperChuck]

Did I expose a bug?  
I hope it's fixable, as I love my REP Rockboxed iRiver.

[jhMikeS]

Yes, I think so. I can't say for sure yet if it is _the_ bug though. The driver one is fixable by checking the correct flags though and I'll commit the changes as soon as I run some tests.

[jhMikeS]

Well, I committed the bugfix anyway and checked it by pulling the optical cable about half way out where it just made a lot of crunching noise. Recording properly rejected that invalid data and progress just held steady with no warnings. Best I could do to check that.

[Mmmm]

So after all that it's nothing to do with the REP at all.... cor I don't know  



I suppose Id better update to get that fix in....

Edit: update in post#1

[jhMikeS]

Never mind about it. Allergies, cold medicine and programming don't mix.   My bit counting was off that day and I couldn't tell bit 22 from bit 20 so after all that it's still in the air and nothing actually changed. Regardless, the few reports of problems these days seem to come from digital sources so after all that...

BTW, what should your REP have to do with the pcm driver and DMA1?

[NorTheBear]

Hello everybody,

I have to confess that the Recording Enhancements Pack seduced me some time ago to move constantly from iRiver firmware to Rockbox. The feature set of the recording section is really amazing, though most crucial for me was when I was able to control the gain while recording on my beloved H320.

Well, there is one little thing that might be so minor an improvement that nobody else might ever have thought about it but hell, I was think of it whenever I missed a nice recording because of me pressing the wrong key and realising only when it's already too late. I am sure some of you know what I mean.

Thus I am daring to bring in the idea of colorized peak meters as another record indicator which is visually easy to spot (in addition to the other helpful indicators like file size increasing and the small icons on the top of tehe screen (for me too small):

Colorized peak meters, e.g.
black = no recording at the moment  ||||||||||||
red = recording is running at the moment  |||||||||||||||||
yellow = recoding is on hold (i.e. recording is interrupted)  |||||||

I would have coded and patched it myself if only were able to do it ...

See manipulated dump screens and see what I am talking about.

Thank you for your kind consideration.

Enjoy your life and your favorite music, NortheBear


[attachment deleted by admin for age]

[Mmmm]

BTW, what should your REP have to do with the pcm driver and DMA1?

I seriously doubt that the REP would have anything to do with it as it is mostly to do with display rather than the real nitty gritty stuff. The only potential problem is that all that histogram info may be too much for the unboosted CPU but I'm pretty sure it is ok.....

Colorized peak meters, e.g.
black = no recording at the moment  ||||||||||||
red = recording is running at the moment  |||||||||||||||||
yellow = recoding is on hold (i.e. recording is interrupted)  |||||||

I would have coded and patched it myself if only were able to do it ...

Ahh, Very nice....Unfortunately I have a lowly H140 which has no colour, so for me this wouldn't bring any joy...
You could always learn to code and patch it....

[jhMikeS]

I seriously doubt that the REP would have anything to do with it as it is mostly to do with display rather than the real nitty gritty stuff. The only potential problem is that all that histogram info may be too much for the unboosted CPU but I'm pretty sure it is ok.....

As I've mentioned, the CPU is always boosted during digital recording or should be and since the only reports seem to be coming from S/PDIF users, there could be a problem in the boost being turned off perhaps? I didn't spot any boost fiddling in the patch but I could have missed it. Nonetheless I'll keep pushing myself to find an answer to any lingering issues and probably test recording with the debugging screen I made up with and without patch to see if it changes the behavior.

[redwood]

Hello everybody,

*snip*
Colorized peak meters, e.g.
black = no recording at the moment  ||||||||||||
red = recording is running at the moment  |||||||||||||||||
yellow = recoding is on hold (i.e. recording is interrupted)  |||||||

If it were to happen, colorization of the peak meters should be tied in with background and foreground colors because some people don't use the defaults. I for example use a black backgound with blue text, which would  render the no recording mode invisble to me.

Personally I think there are better ways to indicate recording status other than meter color or the small indicators in the status bar, but this has been discussed before.

jp

[TaperChuck]

I got the:

warning: 000000001

again last night.
I was recording optical in from a Grace v3.

Maybe my hard drive is going bad? My other recorder, iHP-140, was fine. No problems.

[TaperChuck]

Could a bad (cracked) optical cable be causing this? Or, is it hard disc or software related? It's frustrating, because I tested for eight hours + last weekend with no problems...  

Is there a version of the REP that is approved, so I can start using that, to see if that's the problem?

[Davide-NYC]

Hello everybody,

*snip*
Colorized peak meters, e.g.
black = no recording at the moment  ||||||||||||
red = recording is running at the moment  |||||||||||||||||
yellow = recoding is on hold (i.e. recording is interrupted)  |||||||

Personally I think there are better ways to indicate recording status other than meter color or the small indicators in the status bar, but this has been discussed before.

jp

I feel this is a good time to resurrect the BIG STATUS ICON idea.

Also adding a line to the REP that states which input is currently being used would be huge.


[attachment deleted by admin for age]

[jhMikeS]

Could a bad (cracked) optical cable be causing this? Or, is it hard disc or software related? It's frustrating, because I tested for eight hours + last weekend with no problems...  

Is there a version of the REP that is approved, so I can start using that, to see if that's the problem?

It could I imagine though I'd hope the CPU would properly detect the errors and not flood out the buffers if that's what really happened. I think pulling the connector half way out would give similar problems to that but if the equipment you're using did something bad when trying to keep sync or if the coldfire CPU doesn't report all errors correctly, I'm not sure rockbox can do anything about it.

Despite my idiocy the other day, I did notice not every flag is being checked (for real, they're not) and that could possibly be it though I'll have to do some reading and make sure the other flags are at all relevant to detecting stream errors.

So this is either outside the software pervue or else there's some creepy little obscure bug hiding out in the REP or in SVN that messes with digital in. Due to the fact there was a PCM buffer overflow when it really should not even be possible,  that's what my gut tells me.

So, I'll just shut my trap now and I'll check my recording debug screen soon. I'd love to have that in SVN so the buffers can be watched but the recording screen isn't modular enough to keep functioning correctly while showing it. That's something I plan to change in the near future.