[MPlayer-dev-eng] [PATCH] Add audio support for sndio API.

[Reimar Döffinger]

On Tue, Dec 17, 2013 at 08:28:31PM +0100, Reimar Döffinger wrote:
> On Thu, Dec 12, 2013 at 10:06:31AM +0100, Alexandre Ratchov wrote:
> > On Wed, Dec 11, 2013 at 09:39:55AM +0100, Reimar Döffinger wrote:
> > >
> > > Then at least we wouldn't just hang but could get some message to
> > > the user and/or drop the data to continue playback without audio.
> > 
> > Sorry, I failed to understand how to continue after a write error.
> > I couldn't find examples either, the few backends I tried didn't
> > handle it:
> > 
> > alsa: video hangs
> > oss: video hangs
> > pulse: process loops displaing an error message
> > jack: process gets SIGPIPE and terminates
> > 
> > FWIW, I prodiced write errors by disconnecting the usb audio device
> > in use (alsa or oss) or by terminating the server process (pulse or
> > jack).
> 
> Sorry, I wasn't really expecting it to work without further changes.
> Being able to reliably detect the error would be a first step.
> Though it might be possible to extend the MSGTR_AudioDeviceStuck case.
> Either way, I did make some progress.
> I noticed that "/etc/rc.d/sndio stop" actually doesn't work either,
> but hangs for a long time and then says "failed".
> And sorry, but for this I don't take the VM excuse, a server
> that doesn't manage to terminate itself is just bad code.
> However after manually killing the server, -ao sndio suddenly works.
> No idea how or why so far.
> I also didn't manage to test for the small issues I expect so far.

First test result: Repeated framestepping doesn't work.
If you start a video and then keep '.' pressed it should
play almost in realtime (with a good API, including audio,
but without is ok). With sndio it gets just stuck (doesn't
actually hang, just makes no progress).
-ao oss loses audio in that case but at least video plays.
I suspect you fill in too much data on unpause.
get_space() and get_delay() should return about the same values
after resume as before pause.
See ao_oss for an approximate example.
It isn't correct for sndio, since it assumes that on resume
the buffers are empty - but sndio does not drop the buffers,
so you must take into account how much data the buffers still
contain and only add as much silence to bring them up to the
proper value.
This actually should mean that for the example I gave of keeping
'.' pressed you should get smooth video and proper audio, at least
if the video fps is below your keyboard repeat rate.
If it doesn't, there's probably still something wrong in the
implementation.