Notices

I have also appreciated this app. Thanks so much.

BTW how does one place a feature request (or find out if it's already there)?
(I would like to adjust/remove the long gap between tracks)

Well, that would be song pre-buffering, and as far as I know, most good players these days have that as a standard feature. It's also dead easy to implement without much of a memory footprint. It just requires that 10-15 seconds of the song be queued in memory prior to the end of the previous track. Usually the trigger point for queuing the next track is when the song has 10 seconds or less of playtime left. Code wise that's dead easy to implement.

Unfortunately the DSP prevents implementing this easily.

Anyway, bugs and enhancement requests should be filed in Bugzilla.

now that it is free, what are the next steps? Is there a roadmap of who is working on certain features or fixes?

Hmm, this is probably some obscure meaning of 'dead easy' ;-)

Even without DSP I wouldn't call gapless playback (or crossfading which is similar problem) to be dead easy.

On tablets this is further complicated by DSP doing both mp3 decoding and playback inside one black box. So you can't decode next song in advance without playing it and also most probably the mp3 dsp task does not allow concurrent usage anyway so you can't use it at all while first song still plays.

When non-programmers say that something is "dead easy" to implement, then it means that it's possible to implement. When they say "easy", then it's impossible, and when they say "hard", then you'll do it in 10 seconds with three lines of code.

Anyway, what happened to the plans of INdT to port libxine to maemo to allow crossfading by decoding with the CPU?

lol. Fanosh, you're thinking in a file by file mentality. DSP's don't see the data they handle as files. They see it as streams of information that needs to be processed. It's up to the program to provide that stream of information. Thus to start playing it opens a file, reads the data into memory, then feeds that data to the DSP as a stream. Therefore to make gapless playing, all the program needs to do is append to the first stream and the rest is child's play. The DSP won't notice the difference. It'll just blindly process whatever is handed to it.

well, yes, you are mostly right. In case both songs are in mp3 format and you are parsing mp3 file yourself and your code is talking directly to mp3 decoding dsp task you could do some shortcuts like this. The other half of the problem is that nobody talks directly to dsp like this (except mplayer, ask Serge how dead easy it was). DSP is wrapped in gstreamer framework so for each file gstreamer pipeline with several elements is constructed and then started. This takes some time on the beginning of each file. I'm not sure you can pre-create such pipeline for next song while first one is playing and somehow queue/join them so there is no gap. And also I'm not sure you can feed next song to existing pipeline since the pipeline is specific to that file and its properties (song name and other tags, position, length, codec, bitrate, ...).

Well many things are possible but I wouldn't call it dead easy or child's play. Maybe for mp3 songs one could make shoutcast stream out of them and feed local network connection to gstreamer :-) Not sure what to do when you have mixed playlist with mp3, ogg and aac songs then.

BTW, I admit I don't understand both gstreamer and dsp tasks enough to be on your 'dead easy' level so I may be wrong with lot of stuff described above.

Well, even if it doesn't do it natively, it's easy enough to create a tiny wrapper that can modify the behavior of gstreamer.

Recognising my ignorance of the above problems it seems like if a player could play a 25 min track w/o stopping then why not five 5 min tracks? it would just have to stitch them together before starting. It could even add user defined gaps of mp3 silence to make it completely flexible. Of course, different formats might be tricky. Am I missing something?