Rockbox

  • Status Closed
  • Percent Complete
    100%
  • Task Type Patches
  • Category Operating System/Drivers
  • Assigned To No-one
  • Operating System All players
  • Severity Low
  • Priority Very Low
  • Reported Version Daily build (which?)
  • Due in Version Undecided
  • Due Date Undecided
  • Votes
  • Private
Attached to Project: Rockbox
Opened by pondlife - 2009-03-04
Last edited by pondlife - 2011-10-22

FS#9981 - Tidy up dircache use of audiobuf and safety lock on buffer_alloc

This patch removes the code in dircache.c that directly modifies ‘audiobuf’ and replaces it with buffer_alloc() calls.
It also adds a lock to buffer_alloc() to ensure nobody attempts to call it once it’s being used for audio.

Probably nothing too radical, but I’d like a dircache expert to take a look at it before I commit.

It would be good if an Archos owner could try it too - the MAS audio setup (especially with talking) might not work in the way I expect.

Closed by  pondlife
2011-10-22 09:40
Reason for closing:  Out of Date
Additional comments about closing:   Warning: Undefined array key "typography" in /home/rockbox/flyspray/plugins/dokuwiki/inc/parserutils.php on line 371 Warning: Undefined array key "camelcase" in /home/rockbox/flyspray/plugins/dokuwiki/inc/parserutils.php on line 407

Yes.

One other note - the dircache.c variable ‘thread_enabled’ seems like it should be unneeded. Any thoughts on this?

from a very quick look it looks fine, its no question a good idea to stop everything manually fiddling with audio_buf.

I’m not sure I see the point of buffer_lock() though. is there any reason why you couldnt just replace the few lines which fiddle with audio_buf() to just be buf_alloc() calls?

buffer_lock() was inspired by some hacking I did trying to improve the timestretch patch. I did a buf_alloc() call after audio had been initialised, yet all appeared to work fine most of the time. With this safety net it would have been obvious I was corrupting things Still, it does add a little binsize, so maybe not needed.

well, if its useful screw bin size and keep it.

Sync to r22617 and fixed the type mismatch warning in the panicf call.

As reported in  FS#10516 , when disconnecting the cable after a USB connection, the panic screen here introduced is showed.
I can’t tell anything more, but surely it reveals either an illegal operation attempt or a wrong management in the patch.

I think software USB uses the audio buffer since it needs to stop playback for UMS anyway. It probably frees it after again. I assume the panic is due to that.

Sync to r23221.

About the panic: should it have meaning to avoid the check when disconnecting USB?

Isn’t this outdated due to the dircache/buflib rework?

Loading...

Available keyboard shortcuts

Tasklist

Task Details

Task Editing