What data goes where when? (mpg123 and I)
-------------------------

We have a pipe. This pipe has a buffer of apparently 16K on my laptop's 2.6.7 Linux. There fit 3 Frames and part of a fourth. That is what mpg123 does: write 3 Frames and hang in the middle of writing the fourth.

I want to seek. Testwise to position 0 just after fresh loading or seeking to 0. I send "pause" and empty the pipe by reading 2944 samples... So, why only 2.6 frames in there??? Funny is: Add a full frame to that and we have the 16K. But mpg123 is stuck in writing the _fourth_ frame, not the third! So, at least 3456 samples should be there! But they aren't.

Then there are times when I a at position 20 (dermixd paused) and seek to 0, clearing 5120 samples from pipe. That are exactly 20K. 16K full pipe plus a 4K write.
Seeked from 0 to 100: the 2944 samples again. One frame less than ... a filled buffer.... Wait! Don't forget the ignoring! Disabling it.

I now give the pause command to mpg123 before waking readily. This is logically correct, but there is still the pending problem that the control pipe is full. This can happen when the channel is paused and there are many seq commands sent, for instance. mpg123 is blocked until I read. When I send commands before read, I'm blocked. I'll have to keep track of pending commands in the pipe. I may stll be a good idea to use the pipe clearing seq variant that hides in a comment already...

- fresh start
- load a track (adiemus from dd01)
	- pipe cleaner: 0
	- mpg123 playing 0,1,2,3(stuck)

This means that there should be bow a full pipe with 3,6 frames in 16K, the fourth frame being written.
A successful clearing should get 4308 samples.

- seek 0 (senseless, but technically mpg123 is not at that position)
	- pipe cleaner: 4096
	- mpg123 playing 0,1,2,3(stuck)

There are now 212 samples from 4th frame still around.

- (un)pause
	- I hear a faint sound from the 212
- pause
	- mpg123 playing ..85,86,87,88(stuck)
- seek 0
	- after clearing 1 frame, mpg123 has 88 done

We had a full buffer, read 1152 samples, wich gave mpg123 enough space to fully put frame 88 in.

	- pipe cleaner: 2176
	
	
That's not much. when we had full 16K buffer before, that would have been 4096 samples, plus the rest of frame 88.
And additionally:

	- mpg123 playing 0,1,2(stuck)
	
It only gets 2 frames fully in! Another clue for the pipe not being empty.
At least one frame should now be there. I must hear that.

- (un)pause
	- yes, a not so faint sound from the past
	
- pause 
	- played frame 80, playing frame 81 and read 2*1152 samples

- seek 10
	- after 1 frame cleared, mpg123 played 81
	- pipe cleaner: 2048	
	- mpg123 playing 382,383,384(stuck)

THE PIPE IS NOT CLEAN!!!! No place for lousy 3 frames! It has space for 3.6 frames!

Atomicity: PIPE_BUF on Linux is 4096B. Mpg123 always wants to write full frames (I assume). One frame is 4608B big. An attempt to write less (or same) than PIPE_BUF is guaranteed to be atomic. When there is not enouth space, the write doesn't even start. Question: When mpg123 wants to write 4608B, are the first 4K guaranteed to be atomic? Consequently the remaining 512B?
That would mean for ar fresh load and the 16K pipe buffer:

Pipe empty, space of 4096B
write frame 0: 4096 atomic, 512 atomic
Pipe: 4608/16384
write frame 1: 4096 atomic, 512 atomic
Pipe: 9216/16384
write frame 2: 4096 atomic, 512 atomic
Pipe: 13824/16384
write frame 2: not enough space for 4096B, blocking

So, there are 3456 samples in the pipe. The cleaner got 4096 of them. It reads 3456 samples, mpg123 finishes writing the 4th frame, cleaner gets additional 640 samples. That makes 4096 samples, 16K. But there should be 1152 additional samples, not 640! Still 512 left.

So, what's happening here? Pipe just got ripped off the 3 frames that were in it. Mpg123 is clear to write the 4th frame. In theory, the pipe should be empty and at least 1024 samples should get through. In fact, all gets at least out of mpg123 as it finishes the write. But the other end of the pipe only sees enough bytes to make up the full pipe buffer size together withthe stuff just read! 

Now, after the jump to 0, mpg123 gets to the 4th frame again. We assume the 512 missing 512 samples are now magically there.

Pipe: 2048/16384
write 3 frames: 13824
Pipe: 15872/16384
write frame 3:...

Next seek to 0: We get the familiar 4096 frames, leaving 1152-(16384-15872)/4=1024 samples of 4th frame in pipe void.

Pipe: 4096/16384
write 2 frames: 9216
Pipe: 13312/16384
write frame 2:...

Next seek to 0: again getting 4096, leaving 1152-(16384-13312)/4=384 samples from 3rd frame.

Pipe: 1536/16384
write 3 frames: 13824
Pipe: 15360/16384
write frame 4...

Now seek to 10 seconds: cleaned 4096 samples, as usual. 

Pipe: 3584/16384
write 2 frames: 9216
Pipe: 12800/16384
write 3rd frame...

Seek to 53: read 4096...

Pipe: 1024/16384
write 3 frames: ...

...and so on: The pipe swallows the data after a fill and spits it out not before the next fill.
Does that mean that a single frame would never come through? Can't be, can it?

No, it isn't. See NOTES.skipclick
