Click in the nick column to highlight everything a person has said.
The icon identifies that the person is a core developer (has commit access).

Notice: Only Gecko based browsers prior to FF4 support the multipart/mixed "server push" method used by this log reader to auto-update. Since you do not appear to use such a browser, this page will simply show the current log, and not automatically update.

little question, is there with current build a problem with flac files? it just stops playing after or while rebuffering, no hard crash. could it be a problem with the file being larger than the buffer?

JdGordon: okay, I have added the patch to FS #8008 - seems to work fine in sim, but haven't tested on target and need to sleep now. Feel free to commit if you are happy with it, otherwise I'll do it in the mmorning

Nico_P: (for when you return, if you read logs) I think that any bufopen or bufalloc should take an argument of a callback to say to whomever buffered this item that it is being freed and that if the caller needs the resource again they need to rebuffer it.

Nico_P: I'm trying to get a logfdump of it happening on target but I _think_ that what's happening when playback stops is that the buffer_low_callback is somehow not being treated when the buffer is low but fully allocated.

uhm im a newb. i have rockbox and ipod linux on my ipod. evrything was fine until i used ipod wizard. i actually used ipod wizard before i put the rockbox and ipod linux on there. but anyways i downloaded a theme from the ipod wizard.com and uploaded it to my ipod using the wizard. once i ejected it it rebooted like it should have but the pics and evrything wasnt there. so i used ipod wizard again to load my

karashata: ahhh, that actually explains the bug I'm seeing too. I thought that it was a problem with the allocated buffer space being full and therefor not being able to fill, but it's actually a problem that if the compressed filebuffer ever runs low enough that the codec can't satisfy a request then it stops.

Llorean: I disagree −− it still applies that if you are shaking the player it won't be able to buffer during the shaking and that buffer is roughly how long it can be shaken for continuously during a buffer fill attempt without skipping

Llorean: the pcmbuffer holds roughly 1-3 seconds of audio, full spin up time can be up-to 2 seconds and it's never good to starve the pcm buffer, it's there for a reason (to allow for decreased decoding speed during any kind of UI operations)

so short versions: PCM buffer is to allow for CPU slowness (for any reason, but mostly caused by disk activity or UI activity). There are two watermarks on the compressed buffer, the low watermark is the same as the anti-skip buffer and is dual purpose, it is to allow for jostling during buffer fill and also for disk spin time. The other (only on high mem targets) is a high watermark which is the level below which the buffering code con

As far as my brain goes, if you need to spend 45 seconds buffering total, and can get it with 7 spinups by piggybacking on user initiated ones, or 12 spinups if you ignore a few of them if the buffer isn't low enough, the 7 spinups is better even if one of them only buffers 3mb.

Llorean: not exactly, the cost in this case is the same no matter how empty or full the buffer is −− it's the loss of the ability to skip back to the last played track w/o buffering and that's the only track that matters that's going to be clobbered

The anti-skip buffer isn't meant for working around rockbox bugs wrt low watermark calculation, but for using the (hdd based) dap in a shaky environment, where the hdd might take longer for reading data

JdGordon: There is a fundamental problem with the read-only lists (e.g. the info screens in debug you converted to lists) on targets with small displays (Player, other archoses when selecting a large font)

On Player, the old layout was rather nice, with the parameter currently displayed shown at the top line, in brackets, and the bottom line showing the actual contents/value, scrolling when longer than that line

We should have a dedicated info list thingy, which would take the parameter names and values as separate items, and then either switch dynamically based on font, or the two-line layout selected permanently (player)

I like the idea of linuxstb (keeping the original .rock at the end of the plugin buffer.) If the plugin is small enought we could reuse its binary image. If it's big it will be reloaded. All transparent and requires no plugin rewrites.

preglow: Do you think it's worth spending any time on faad, or should we keep waiting for ffmpeg? I'm thinking it could be simplified, first by stripping out all the unused code (i.e. everything in undefined #ifdefs, plus maybe more), and then seeing if it could be restructured. Seeing how the ffmpeg and helix codecs are structured might help with that.

I recently flashed rockbox to my H120 (for speed and efficiency), but I *think* I flashed it to RAM as well as ROM. Is there any way of removing the RAM image to ensure I take advantage of the extra RAM buffer?

pondlife: for a track longer than the buffer, the next track metadata cannot be on buffer, but for a track that happens to be at the end, it can be no the buffer but will only be if we do an early rebuffer

linuxstb: I was just running some scenarios in my head −− it would be possible to make the api reserve space at the end of buffering for an id3 struct which playback reads when it needs that metadata and immediateyl frees.

i did something while a song started playing: i held the rewind button in thinkin it would continue from the last songs ending position. but my sansa blacked out the screen and became unresponsive.. now the scroll wheel is lit up the entire time and the little thing wont power off

Nico_P: I thought about storing the metadata strings as offsets, but am not sure it's a good idea. IIUC, they are read many times, so it may be more efficient to keep them as they are, and adjust the pointers if you move the struct. You would also need to change all the metadata parsers...

kind of funny. did you knwo that the wording "xtreme" and "insane" were taken over from musepack and that this wording was defined in a night telephone conference with one tester, several beers and cigarettes? ;o)

linuxstb: put the following 2 statements in lcd_init(), then build, install (just core is sufficient), boot and watch the screen during boot. Then do a quick measurement of fps (doing just one cpu freq is sufficient)

amiconn: I know how im going to fix the info list things so it doesnt take much effort to fix the current screens... _BUT_ on bitmap lcd it is going to have to be a setting... the text callbacks dont know which display they are on so it cant reposition automatically)

but first I have to know when libmpeg2 is actually done with a packet so buffering can safely overwrite it. I have a video where buffering ends up clobbering one or more during fill before libmpeg2 is done with it. (ah, but details)