16.58.42 # pondlife ? 16.59.04 # Hi 16.59.10 # hi 16.59.26 # Hi. Is your buffering API progressing ? 16.59.30 # No 16.59.38 # :) 16.59.45 # A quick answer! 16.59.49 # indeed 17.00.07 # I mainly put the page up so that interested parties could run with the idea if they had time (and thought it might be useful) 17.00.07 # Because I think it could very well be the first step toward MoB 17.00.20 # Well, you know what to do then ;) 17.00.48 # I doubt I will have time to put fingers to keyboard much, but am happy to help consider things if you have questions. 17.00.50 # exactly, and I thought you could be of great help, as you probably had a vision of how it would work 17.01.11 # Not much - I've tried to put it all on the wiki. 17.01.39 # I like the way that the AudioHWAPI was handled on the wiki - test cases and all, so that would be next I think. 17.03.55 # pondlife: so there would be a buffering thread controlled with the buf*() functions ? 17.04.25 # That was my idea, yes. It would pretty much replace the current playback thread I think. 17.05.06 # and it would all be in buffering.[ch] 17.05.33 # Something like that, but there are many things still to be considered (and it may not turn out to be viable....) 17.05.33 # well the playback thread would still be needed to handle things like FF/RW and even pause 17.05.52 # Yes... hence "pretty much" 17.06.07 # ok :) 17.06.20 # Codec swapping and much metadata stuff too.. 17.06.40 # And, sadly, keeping the voice thread going! 17.07.55 # what's codec swapping ? changing codecs when two successive files don't use the same one ? 17.08.08 # Yes, and a bit of tracking. 17.08.16 # The codecs live in the audio buffer too. 17.08.39 # |codec|audio|codec|audio|audio|... 17.08.53 # (Or it might be audio then codec, can't remember.) 17.09.13 # I think the codec is before the audi 17.09.14 # With the buffering API, those would also be handled as buffered files. 17.09.19 # yes 17.09.45 # the thing is I have no experience in threading 17.09.52 # Me neither!! 17.10.01 # haha then I'm reassured :) 17.10.08 # Have a look in playback.c at the stuff that starts threads maybe? 17.10.12 # Codec swapping is for voice & playback 17.10.17 # That too 17.10.51 # Hopefully that can go away at some point - a dedicated voice codec would be nice (even if it's just a copy of the MPA codec linked at a different address). 17.10.57 # pondlife: It's only for that. Crossfading is handled differently 17.11.24 # I was referring more to the codecs in the buffer, not in "time". 17.11.35 # pondlife: Then one of them cannot use iram anymore (or both can use less) 17.12.34 # We need to see if IRAM is really needed for MPA voice, or on which targets? 17.12.57 # IIRC it was thought this wasn't need on Coldfire at least. 17.13.12 # Mono, limited bitrate etc. 17.13.41 # pondlife: If it's OK on Coldfire, then I would expect it's OK on portalplayer (apart from maybe the PP5002) 17.14.00 # I might be remembering wrong, this is really still work to be done... 17.14.11 # Does the current code swap the codec stack as well as the 48KB? 17.14.23 # linuxstb_: I think so. 17.17.34 # linuxstb_: The stack doesn't need to be swapped, as the codecs run in different threads, and the stack isn#T in the codec ram or codec iram area 17.18.14 # Is the voice thread's stack in IRAM? 17.18.37 # is the sim a good tool to test threading things ? 17.18.55 # Nico_P: Not really - the kernel is different to the real kernel. 17.18.56 # Nico_P: Not really 17.19.03 # ok :) 17.19.26 # You can run multiple threads, but contention is handled differently. 17.19.47 # A good way to start playing at least. 17.20.03 # my MoB task is looking more and more like a rewrite of the playback system... scary 17.20.52 # Nico_P: It *is* a rewrite of the playback system, no doubt about it! 17.20.56 # And yes, that's scary. 17.21.15 # * Nico_P is about to run away screaming :) 17.21.35 # But it should be a good chance to bring a bit more order to it... and I thank you for taking it on! 17.22.25 # pondlife: I just hope I'll get a lot of help from people like you who know how it's supposed to work 17.23.30 # pondlife: in the current system, only the audio data is kept in the file buffer ? not the entire audio file ? 17.23.34 # Nico_P: I'm not the real expert, just a hacker. Speak to lostlogic (Mr Buffering) and jhMikeS (Mr Threading). 17.23.49 # Nico_P: I think so, the metadata is pre-removed 17.23.59 # pondlife: sadly, lostlogic isn't very available 17.24.03 # I know 17.24.16 # although he's often logged on 17.24.42 # Nico_P: If the metadata is on the buffer, I'm not sure if the codecs know how to skip it.... they should do, but I don't know if they do. 17.25.21 # they probably need the exact location of the compressec audio data, which shouldn't be too hard to give them 17.25.30 # I would think more about the structure and test cases before starting to code anything, anyway. 17.25.43 # what do you mean by test cases ? 17.26.35 # Make a list of various things that playback needs to be able to do. Ensure that your solution can do them. Things like crossfade - WPS next track info,... 17.27.08 # There are lots of them, most will hopefully not be affected too much, but I've not thought about it. 17.27.21 # I see 17.27.24 # I'm sure others can chime in - start a section in the wiki 17.29.28 # Also bear the MAS targets in mind... they don't use playback.c IIRC; I've no idea how they go about buffering. 17.29.52 # One goal here would be to unify things 17.29.58 # Yes 17.30.26 # Currently the MAS playback engine is in mpeg.c, using parts of mp3_playback.c 17.30.31 # amiconn: Am I right to recall that the MAS needs metadata removing to work gaplessly? 17.30.41 # The mpeg thread handles both playback and recording 17.30.58 # What handles the file reading? 17.31.03 # pondlife: Um,, all codecs need that I would think 17.31.28 # pondlife: The whole engine is where I said, that includes file reading, buffering etc 17.31.43 # It just queries playlist.c for the playlist 17.32.21 # OK, so there's a possibility that a generic buffering API could be used by mpeg.c as a stepping stone towards unification? 17.32.41 # I don't think that will work 17.33.43 # amiconn: I know you put some reasons up in IRC before, but if you could put them on the wiki that would be useful. 17.34.10 # http://www.rockbox.org/twiki/bin/view/Main/BufferingAPIProposal 17.35.19 # I know there's the bitswap and metadata removal required... is that it? 17.35.45 # pondlife: is the "Current Status" part of http://www.rockbox.org/twiki/bin/view/Main/SoftwareCodecPlayback the current way the playback engine works or the current (at the time) idea of how to implement MoB ? 17.36.10 # An idea, I think 17.36.26 # Maybe the heading should say "Current proposal" 17.37.03 # The bit at the bottom... "Rockbox software codec current audio playback functional description" is more accurate 17.38.21 # it mentions static "worst case size" metadata buffers. I think that isn't possible 17.39.38 # pondlife: I think metadata must be removed (and currently is removed) on swcodec as well 17.40.00 # Yes, that's what I feared some lines back. 17.40.56 # I don't think that's a problem 17.41.50 # When opening a new track, the metadata reader first gets the metadata anyway, and puts it in a separate buffer slot. Only the pure audio data is bufferend in the main buffer 17.42.27 # For MoB, the metadata buffer slot would "just" be in the main buffer as well, as some kind of header to the audio data 17.42.48 # yes 17.43.04 # The metadata won't be fed to the codec, regardless whether that is a codec library or the mas 17.43.13 # and the buffering API would have to keep track of them as two separate things 17.43.52 # We will need one (or two) extra slots outside the main buffer, for copying the metadata of the current (and next) track into 17.43.55 # so the buffering thread would simply monitor the playlist in order to know what to buffer next or to unbuffer 17.44.02 # yes 17.44.33 # The former because it becomes invalidated after starting the track at the next rebuffer action 17.44.36 # or couldn't they just be accessed in the main buffer 17.44.38 # ? 17.44.46 # how? 17.44.51 # No, they might not be buffered. 17.44.55 # A track can well be longer than the buffer size 17.44.58 # Imagine a long track 17.45.19 # Very common on archos, and also common on swcodec with lossless formats 17.45.21 # well it could be invalidated only when the track is finished playing 17.45.30 # No, 17.45.31 # meaning the track would be buffered in the rest of the buffer 17.45.37 # how?? 17.45.49 # Nico_P: Then you would have a gap in the buffer... 17.45.49 # But where would the next track info be? 17.45.53 # * amiconn even has a 65MB mp3 track 17.46.06 # OK I see the problem 17.46.19 # A suitable test case, right there! 17.46.33 # I also have 200MB+ flac tracks 17.47.18 # and where would the buffering thread keep track of the "file handles" ? 17.47.24 # There's also other metadata it would be nice to load at buffering time - such as seektables, and any codec "extradata" (as ffmpeg calls it) which is required by the decoder before it can decode any audio frames. 17.47.55 # Nico_P: I imagined the "file handles" as actually being offsets to the block of metadata... 17.48.03 # linuxstb_: where is that stored currenty ? 17.48.20 # Nico_P: Why would that be needed? No more than one file should be open at any time 17.48.32 # Nico_P: Either in static buffers in the 512KB codec buffer, or "malloc'ed" out of the 512K codec malloc buffer. 17.48.48 # The latter is something that would be nice to eliminate. 17.48.55 # pondlife: The metadata blocks could just be a linked list 17.48.56 # amiconn: "Handle: An integer that refers to a particular buffered file, not necessarily the file handle as used by standard file i/o." 17.49.46 # pondlife: offsets probably wouldn't work... what would the handle to an unbuffered piece of data be ? we could have that, couldn't we ? 17.49.51 # amiconn: Yes, that's what I was imagining. The "file handles" were just a way for the outside world to find an entry. It could be a list ID... 17.50.08 # that's it, but where is the linked list stored ? 17.50.42 # I did think of a linked list, but where would the structs go ? 17.50.48 # Nico_P: Erm, the blocks would just form a linked list (or perhaps a double-linked list) 17.51.02 # The blocks *are* the structs... 17.51.06 # amiconn: ok I see 17.52.04 # linuxstb_: Why would you need a separate buffer for a list? 17.52.52 # amiconn: well the data buffer for a block would be out of the struct... we'd have sth like |struct1|data1|struct2|data2| ? 17.52.56 # * amiconn exaggerated a little 17.53.03 # My larges flac track is 171MB 17.53.14 # where data can be a codec, audio data, a bitmap... 17.53.26 # which the struct would inidcate 17.53.32 # Yes, sure 17.53.38 # Nico_P: Careful you don't cause buffer fragmentation. What about the as-yet-unbuffered files? 17.54.01 # pondlife: Unbuffered files don't need metadata either 17.54.20 # There won't be any fragmentation from this concept, because everything is written in sequence 17.54.33 # pondlife: well what should bufopen() do in case the buffer is full ? return <0 ? 17.54.44 # Ah, I was thinking Nico_P was also referring to a list of future files to be buffered. 17.54.47 # or maybe keep a queue of the requests 17.55.01 # A seperate queue I guess 17.55.20 # yes maybe so that as soon as some buffer space is freed it can start buffering the next file 17.55.23 # The buffer will be full much of the time, especially with monster files. 17.55.27 # Nico_P: No 17.55.41 # The buffering will wait until it really has to spin up the disk 17.55.49 # true 17.55.58 # The aim is to reduce disk spin-ups, not to keep the buffer full. 17.55.58 # The 'list of future files' is the playlist.... 17.56.33 # No need to copy that as it can be queried as needed 17.56.46 # that's true 17.56.59 # Makes sense, although we might need to allow MPEG2 files into the playlist one day. 17.57.04 # pondlife: so we spin the disk when the buffer runs low ? 17.57.20 # When we think we are in danger of failing a bufread() 17.57.27 # In case the api should be made generic it could specify a callback for that, which would hook to the playlist code in case of music playback 17.57.28 # and then buffer as much of the playlist as possible ? 17.57.44 # Yes, while the disk is spinning we fill the entire buffer 17.58.18 # and what if the buffer is almost empty but there is a buffered file still used that's right in the middle of it ? 17.58.28 # and everything else has been bufclosed 17.58.45 # That can't happen. bufclose() is just an indicator... 17.59.26 # what do you mean ? we overwrite even if bufclosed for that particular handle was never called ? 17.59.35 # A section of a file may be overwritten in the buffer before bufclose(), but it would need re-reading if a subsequent bufread() required it. 18.00.00 # Yes, absolutely. Have a look at how the current code reacts (in the debug View Audio Thread screen)... 18.00.26 # Then play with some large/small tracks and skip forward/backward etc. 18.01.03 # The only point of bufclose() would be to free up a handle, but if the playlist handles all of this, then bufopen and bufclose can be removed. 18.01.51 # The whole API becomes much more about controlling the access to the buffer, not much else! 18.02.43 # how does the playlist remove the need for bufclose and bufopen ? 18.03.17 # You'll just rely on the playlist itself for your "list of files to buffer" 18.04.24 # i.e. just like now, but with a bigger fence around the buffer ;) 18.07.10 # without bufopen we don't have handles anymore, do we ? 18.07.28 # Nope, just whatever index the playlist uses. 18.08.09 # yes but a playlist item relates to several pieces of data 18.08.45 # the audio data, the AA bitmap, the cuesheet, the metadata 18.09.00 # Ah, true.... forget it, keep bufopen/bufclose and have a small structure to track "handles" 18.09.23 # We can put a limit on the number of buffered files, I think I suggested 64 would be plenty. 18.10.28 # well we might not even need a limit if the "files" form a linked list 18.10.29 # Currently playback allows up to 32 tracks to be buffered (although it gets a bit confused if you achieve that) 18.10.42 # I thought MOB was a way to get rid of the limit 18.11.07 # * linuxstb_ wants 5000 SID tracks in RAM at once... 18.11.20 # Fair enough 18.11.21 # an another test case ! ;) 18.11.26 # * linuxstb_ should point out he was joking 18.11.39 # Nico_P: You're getting the hang of it.. ;) 18.12.41 # :) 18.13.12 # does it sound reasonable that the buffering thread would monitor the playlist ? 18.13.55 # the current audio thread does that anyway, doesn't it ? 18.20.11 # Nico_P: I was thinking that the playback thread would monitor the playlist, and call bufopen(). But that might be one abstraction too far... 18.21.23 # seems more logical to me if it's the buffering thread