What dermixd does to provide gapless output
===========================================

1. not making it worse
	follow command with copying the first frames of new track right after the last track in one buffer
	no opening/closing of audio device in between
	
additional stuff in mp3 input, since the mp3 format is causing all this (when one takes a perfect source before compressing as granted):

2. skipping some silence at begin
	-easy as such, when the beginning is clear, but difficult together with seeking and the sample (2 (or 4) frames) ingorning	
	-> read even more (+1 frame) and search the whole read buffer for some (10, 100 samples???) silence or at least a clear minimum, when nothing special found, take the start of the additional frame as the track start.

3. skipping some silence at end
	on near_end issued my backwatch, read all left data and scan for non-zero from the end. We assume we have at least a frame after the ending message. What if not? Can't help it...
	Worst case: We read till the end but don't _know_ it. After a sched_yield there should be near_end present with 99% certainity.
	Another possibility would be total prebuffering. Always be a chunk in advance. When we see that there is not enough left when reading the _next_ chunk, we know that the one in the buffer was the last full one and both combined should be enough...
	...thinking that over: There doesn't have to be a buffer of only a chunk's size. It can be arbitrary big.
	This method looks a lot like that whan nearly everyone else does on this issue...
	
Could this full buffer be also helpful for the ignore?
	
And in extremeo: silence sparebuffer tips the end, also (we have a 2-frame file or even an empty file!)

Hey-ho! what about using fancy super clever double-buffering all the way?

-> Having a prebuffer makes is easy to find the track end in the future
-> Need the prebuffer anyway for silence seek (well, not exactly, but it is done that way currently)
-> possibility to make seeking accurate!

Lets talk about the last one:

I'm somewhere in the track, having a properly filled prebuffer. A seek command occurs; the target it is either within the buffer, when we can serve it directly without touching mpg123 at all, or elsewhere. When elsewhere, we do this: Seek to a position whose audio we have somewhere near the beginning of the buffer, read a very small amount of samples, pause, read (!) what is left, search in the old junk for the start of the part we wanted by comparison with buffer -> remember the position in prebuffer up to which we had the same audio.
Now seek to the position we really wanted, reading all junk (pipe clearing and reading after unpause) into a spare buffer.
We know that most likely we still have old sound in the new data that should be in prebuffer, starting from the remembered position.
Now just compare until it differs from prebuffer: That's my new sound!

Two questions: Is the old data we get _really_ the old data we expect and not just some random junk? Hard to tell from 1000 samples. How big should the buffer be?


First step: I need the prebuffer. With some size. For correct seeking I need a copy of the old buffer; meaning I need two buffers to switch between. Size: currently I ignore 2 (layer 3) Frames... to be sure, the buffer should contain 4 Frames. Think:

have 4 Frames ready, got seek: pause, throw away stuff, seek to buffer start, read 2 Frames (ingnoring these killed the junk for sure), pause, read left stuff (another 2 frames?), find start of buffered audio in this 4-frame buffer ... look how many samples we got there (sidenote: one should use the stream and 
