Rockbox Technical Forums
Support and General Use => Hardware => Topic started by: Zakalwe on March 20, 2017, 12:57:07 AM
I am not entirely sure whether this is a hardware issue, so depending on the background it might have to get moved to the database forum.
Anyway, I am using the most current build (35d69c8) on my Sansa e280v2, though I have encountered similar problems/symptoms with earlier versions, including 3.13 stable.
The problem is, when I enable the "Load to RAM" option in the database settings, then database browsing is greatly accelerated (as it should be), but the player can no longer play back music. Instead, when trying to play back music, with the current build I get a white screen with kernel panic. The stable build would simply do nothing, just show the playback screen but not play.
I have quite a lot of music on the player, as I use a 256GB card with about 22,000 files spread over 2,000 directories. Playback works fine again if I disable "Load to RAM", so I think it is a reasonable guess that my database takes up so much RAM that not enough is left for playback.
What is odd to me is that the same card and "Load to RAM" work fine in my Clip+. It was my layman's understanding that these two DAPs were quite similar internally. Do they differ in their amount of RAM? I could not find the amount in the e280v2. Or maybe the prettier big-colour-screen-GUI in the e280v2 also needs more memory, and in combination this takes too much for playback?
I am not really hoping for a solution to this, but I am curious and would like to know what is going on. :)
There does seem to be a specific issue with 'Load to RAM' causing tagnavi errors and possible playback and resume failures.
I've been trying to investigate it, but without much success so far (http://forums.rockbox.org/index.php/topic,51710.0.html).
Activity on the forum seems quite low, in general, so I guess we may have to wait for an answer...
What exactly is the kernel panic?
Ah, sorry, I should have included it in the first place.
The white screen says this:
audio_reset_buffer_noalloc(): EOM (526104 > 118652)
pc: 30044B80 sp: 300CC1A8
This output happens both when trying "Resume Playback" from a previously playing file, and when picking some new file to play using the database.
Yep, it's running out of ram. That database is enormous and that player only has 8MB RAM. You've got 118k left at that point, not enough for even the PCM buffer. The database has to either completely loaded or not at all and there's no size restriction on how much it will try to load. That's how it's been since it was created a decade ago (and revising it is no trivial matter).
Personally, I think panicking is overkill for anything not a broken internal state.
Edit: It given the impression of something catastrophically broken when it might be trivial.
Thanks, that puts my mind at ease. ;) It is not really a problem, directory navigation works well. Do you by any chance know how much RAM the Clip+ has? I am surprised how much better it copes with that card.
It has the same amount of memory, but the firmware uses less since it doesn't have a color screen.
Nice, thanks. It is kinda funny how restricted these older devices are compared to smartphones, for example - by orders of magnitude. Yet still they are so capable. Every now and then I try to use my phone as my main player, to carry only one device. I always end up going back to some rockboxed Sansa, the user experience is so much better. And with microSD cards slowly growing along/ahead of my collection, I can see myself sticking to these old little machines for years to come.
Good news (to myself ;)) - after digging around in the debug options (those one should stay out of) I found that the directory cache was taking up quite a bit of RAM. I disabled this, and now I can load the database into RAM and still play music. Also, I do not really notice any slowdown in the directory browsing, but I might be misunderstanding the purpose of the directory cache. Anyway, this works great for me. :)
Dircache will speed up buffering, database build and database playlist creation considerably since the file code doesn't have to go to the storage to read directory contents.
Ah, I see, thanks. Well, I will keep it like this for a while and test how it works for me. If it doesn't, then I know why. :)