Problem:

pause playing track, seek to some other place, unpause: there is a short noise/click/sound from the position we left before the good stuff

additionally: when shutdown with a track on pause, something ticks, too. This efffect is also seen in mpg123 alone (on console).

The funny part: This is not _one_ problem. I can write silence when there is no sound with the effect that the shutdown-tick is gone and also is the sound-from-yesterday-part-1, confirmed with pause-seek 0-vol 0 0-pause: utter silence.
But with volume 100 I hear sounds from the grave! 

So, we have the output effect (fixable by writing silence or maybe by SNDCTL_DSP_POST) and an input or mixing effect.
Whose buffering is to blame?

Some testing later:

Concerning the output effect, the only way seems to be feeding constantly _something_ (zeroes when there is no data). No practicable way found for preventing the click on program end (audio file close). Maybe access the mixer, mute pcm, close, unmute pcm? Ugly. One may have a look if the ALSA driver does not do this, or other hardware than my notebook's Maestro2E, respectively.

Concerning the other side, I made a crude raw (16bit Stereo) file input module that doesn't show the bad behaviour. So it is the fault of mpg123, my mpg123 input module or the great void in between.

I narrowed my view to playing a bit, pausing, seek to 0, unpause using a track that starts with 0 on both channels (adiemus from dream dance 1). Then i installed some code in the reading loop that delays the finish until it saw two zeroes.
And in fact, that does it: Even after the (attempted) pipe cleaning, there are some thousand samples from the old times lurking at the pipe's end. With the detection I have clean sound.

So, two basic options:

1. The pipe cleaner doesn't work (either because of faulty design or black pipe magic) 
2. MPG123 is nasty.

I'll look at the pipe cleaner, first...

I'm fed up: Doimg the dirty, dirty, hack: I'll ignore the first 2304 samples (1/20s) after a seek. This gives me mostly about 1/40s wrong (mostly too late) positions. But since I have to round to frames anyway for mpg123, the difference won't be so big.
Not the solution, but that what I can do to get some sleep, finally!
What still is quite bad: I'm loosing the position. Very frequent seeking kills it. Of course I must have lost sync formerly, too, because of old sound that counted as new but wasn't. This reencourages usage of the length info for informational purposes only. It is never accurate and is likely to become unaccurate otherwise. The track ended when mpg123 told so and there is nothing more at the pipe. Amen.

THE END:
--------

This bastard almost had me! Now, the final conclusions:

- no greedy 16K pipe buffer, it's an internal mpg123 buffer! Added some strategical audio_flush() calls to fix the issue on that part
- still junk on begin: Looks like mpg123 always spits out a frame of drek before the good stuff. Being unaware of the probable internal uses of this junk (eq?), dermixd is now just ignoring 1152 samples on every concerned situation... Should check if this would be 576 samples for the special low-bitrate files.

Now we should have some resonable playback that at least tries to please the ear on seeks. 

