Buffering and generic remote control did not interact nicely before. Now I added
some explicit draining and dropping to make sense.
This means that, on track input end, there is a phase of draining the output buffer
that you cannot interrupt with a command. Decide between quick control or stable
playback. Seamless buffered track transitions are not really in the picture. That
would need more invasive changes in the control logic.
A re-implementation of the mpg123 player with differing interfaces would improve
on that behaviour. We're carrying the tradition of some decades of hacks here.
git-svn-id: svn://scm.orgis.org/mpg123/trunk@5291 35dc7657-300d-0410-a2e5-dc2837fedb53
This introduces software muting in libout123, to be triggered via terminal control
key 'u' (m was taken) or the remote control commands 'mute' and 'unmute'. For this,
libout123 needs to know what a zero looks like in the current encoding. I hope
I handled that smartly enough with the MPG123_ZEROSAMPLE macro in fmt123.
I explicitly decided against linking in libsyn123. That makes only sense when
going all-in and deciding that libout123 shall convert, resample, and mix
on-the-fly to make input data match the output. This might be nice to have,
but it is also nice to have a library that does not really care about the
content it transports. It is a simple transporter with a buffer. Said buffer
necessitates that the transporter knows what empty sound looks like, but I
really don't want to burden it with more knowledge for simplicity.
This muting needs to be inside libout123 whe the buffer is used. Feeding
silence from the client application does not have latency you expect when
(un)pause is already negotiated with the buffer.
git-svn-id: svn://scm.orgis.org/mpg123/trunk@4589 35dc7657-300d-0410-a2e5-dc2837fedb53
