Version: 2.1.1 (using KDE 3.3.1-0.2.2.kde, Fedora Core release 2 (Tettnang)) Compiler: gcc version 3.3.3 20040412 (Red Hat Linux 3.3.3-7) OS: Linux (i686) release 2.6.7 When playing songs through juk my hard disk is accessed every 5 seconds or so to read new data from the song. It would be a great feature if juk could cache in advance to prevent the disk being accessed so much and continuously. While this is not important on a desktop machine it is very useful on a laptop as it allows the disk to spin down and conserve battery power. The other advantage for portable devices is that there is less likely to be a skip in playback if the device is jolted. I actually discovered that Linux kernel is quite good at caching from the disk. If I cd into a directory with songs and then "cat * > /dev/null" then whenever I play songs from this directory the hard disk is never accessed. This is a very simple but powerful way to implement the cache as the kernel will automatically free the cached memory if it is required for something else (as opposed to a cache malloced within juk). So if juk could just read ahead a configurable amount of songs that would be perfect.
This isn't really a JuK thing. My personal opinion is that this is the job of the OS, not the application, but I'll give Allan (aKode author) the final say on such...
To a certain extent I agree. However, if juk is in random mode there is no way the OS can predict which songs would be played. It would be nice if more than one song could be cached. Only juk will know what the playlist order is when in random mode. Even when playing an album the OS would have to be pretty intelligent to realize that and cache the album. So I think this is better done in juk. A separate thread that reads files before accessing them in advance and does nothing with the data. In effect the OS would then be responsible for the caching which is probably best anyway. It's a bit similar to kdm preloading KDE for faster longins - it just reads common files used by KDE startup scripts before they are required while the user types in their login information. Then the login is much faster. I agree the OS should be mostly resaponsible for the caching but it does need a bit of help from the application to say which files will be accessed.
A decoding library such as akode can only know which song is played currently, and only cache that. (aKode advices the kernel that it is going to read the file sequentially, and lets the kernel decide the optimum strategy). The way to solve this would be for JuK to load the next song in extra Player object set to pause. JuK should not deal with caching itself, but without help the playback components cannot do it. Another strategy we could consider in conjunction with kdemm could be the ability to load multiple songs (atleast two) in the player, this would also make true gap-less playback possible.
Assigning to kde-multimedia, because it requires a different way of using decoders.
Hi, I've briefly read through the comments on this bug. I think the best way to handle buffering is within the play objects. You just have to tell it how much memory it is allowed to buffer. This will solve the problem of the disk spinning up too frequently. Also, you can apply this concept to video playback quite easily. I don't know how amarok or juk work internally, but it seems sensible to assume that there's some kind of playback engine that knows what song is going to be played next (even for a shuffled playlist). You can even go and buffer more than one song in advance, by having a list of playobjects for the next N songs. Doing it that way, the disk would only have to spin up once every N songs - but believe me, it does not matter much, in terms of power consumption. regards, matthias On Thursday 04 November 2004 17:28, Allan Sandfeld wrote: > ------- You are receiving this mail because: ------- > You are the assignee for the bug, or are watching the assignee. > > http://bugs.kde.org/show_bug.cgi?id=92055 > kde carewolf com changed: > > What |Removed |Added > --------------------------------------------------------------------------- >- AssignedTo|kde carewolf com |kde-multimedia kde org > Status|UNCONFIRMED |NEW > everconfirmed|0 |1 > > > > ------- Additional Comments From kde carewolf com 2004-11-04 17:28 ------- > Assigning to kde-multimedia, because it requires a different way of using > decoders. _______________________________________________ > kde-multimedia mailing list > kde-multimedia@kde.org > https://mail.kde.org/mailman/listinfo/kde-multimedia
Could this be still valid for phonon too? P.S: Sorry for having changed the product from kdemultimedia to phonon, but I don't know the email of the phonon mailing list (I didn't find it googling)
@ Matthias Kretz: Any updates on this, are you still working on this one and are we working on integrating phonon in this problem.