Bug 92055

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.