Support and General Use > Recording
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... ;D
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! ;D
I appreciate your putting your valuable material on the line to check things out.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version