WARNING: current CVS recording code not stable [ NOW FIXED! ]

[jhMikeS]

I'm thinking about designing another type of queue that lets the waiting thread know that it's particular instance of its message in the queue is processed. The audio_* recording functions are not safe in this regard since a sequence like stop->other messages->stop would result in the thread waiting on the last stop being released when the first stop is processed.

[jhMikeS]

Stil brainstorming...  

Having a synchronous "int queue_send(int msg, void *ev_data)" would eliminate the extra private queue in playback.c as well that is responsible for the resume deadlocks. The audio thread can just do queue_reply(value) which would be a no-op if the last dequeued message was posted.

Well, it's more complicated than that but this mechanism appears to be nescessary to release threads at the proper time/order they waited. Yes, KISS, but not _too_ simple.

[jhMikeS]

Do check out and test http://www.rockbox.org/tracker/?getfile=13213

Flyspray URL:
http://www.rockbox.org/tracker/task/6109

I'm the most confident I've been so far in a change to make recording more durable. Hopefully it will close this issue.

[petur]

Sounds great. To be tested tomorrow at a concert

[jhMikeS]

I'm not feeling the pressure!  

I appreciate your putting your valuable material on the line to check things out.

[petur]

Fact is that I have little confidence in either version so I might as well try the latest fix. If it turns out to work reliable it will give me confidence and less worries while taping And we do indeed need to get this thing done...

[Davide-NYC]

Guys I've been way to busy to help out lately and for that I really do apologize.

But this sounds like it must be tested and I am willing to do some tests.

Unfortunately my VMWare dev environment was recently overwritten and I haven't had time to set it back up again.

Would it be too much to ask for a custom H120 build with this patch included?

And is the only way to test for dropped samples to listening back for hours? (I'm willing to do it but I'd like to know if there is a faster way)

Again, sorry for my absence.  

[jhMikeS]

Hey Davide!

Yeah, I could do that. Is an email attachment ok? I'll get it out to you ASAP.

As far as dropped samples, no, not any more. If any overflows occur you'll get a warning flashing over the recorded time display which should tell you. Though, it could come up falsly depending on timing but would be quite a narrow escape at that. If you see it, take the number down and report back. It will persist until you leave the screen or start a new recording after stopping.

[jhMikeS]

Fact is that I have little confidence in either version so I might as well try the latest fix. If it turns out to work reliable it will give me confidence and less worries while taping And we do indeed need to get this thing done...

That was intended as irony. Actually I'm biting nails and drinking too much coffee waiting for hopefully good news about this.  

[petur]

Current code seems to be rock stable. Thanks jhMikeS for fixing!

Case closed

[jhMikeS]

Your welcome. I'm just sorry I didn't fix it sooner but it's just another instance of identifying the problem and a solution being obvious by stepping away from it and for awhile. I just hope it will stay fixed all by itself.  Important features and refinements will be the order of business from now on I pray. 8-)

[whatboutbob]

Aye, i've been testing and can't break recording.  Thanks Mike!

[perjak]

Hello everyone,

I have most probably encountered a skip (dropped samples) on a recording I made last Saturday. Have to compare with another source to be sure, but in my ears it sounds as if....

I have a H140 and the build is of 06.12.2006 (December 6th). Approximately half of the disc space is in use.

I ran a defrag from windows recently.

I have tried to read this thread, but in between things gets very detailed and technical  , so I only ask, if this issue is fixed now?

Are there any other advices.....?? I have HATED skips since the early days of cdr-burning.

Thanks a million

Per in Denmark

EDIT: I recorded via optical in, as I had my SBM-1 with me.
EDIT2: The build is 061207, ~ Dec 7th, 2006 (had to find my reading glasses.....)

[jhMikeS]

For one, sorry for getting real technical about the internal details For another, a threading issue was addressed in February as you can see in the previous messages. Please update. Stability was verified for that in the field and in buffer checks.

[petur]

I have a H140 and the build is of 06.12.2006 (December 6th). Approximately half of the disc space is in use.
EDIT2: The build is 061207, ~ Dec 7th, 2006 (had to find my reading glasses.....)

I can only join jhMikeS: update....