zikichombo / sio

sound I/O
BSD 3-Clause "New" or "Revised" License
25 stars 4 forks source link

proposal for xrun interface #15

Open wsc1 opened 6 years ago

wsc1 commented 6 years ago

Would like to propose introducing an sio.ErrXRun error which can be returned from sio linked sound.{Source,Sink,Duplex} to handle xruns (under-runs for playback, over-runs for capture)

This would be in combination with a Source,Sink,Duplex wrappers that handle sio.ErrXRun and don't ever return them.

The error itself would provide timing information

It would also require interface documentation changes in module zc/sound, as for now the existence of an error implies unrecoverability (which is nice and simple)

wsc1 commented 6 years ago

After some thought, it seems a temporary error is a bad idea for the non i/o use cases of {Source,Sink,Duplex}

Perhaps it would be better to have sio define an XRunner interface

type XRun struct {
    StreamStart time.Time
    FirstLostSample int64
    LastLostSample int64
}
type XRunner interface {
    // returns nil if last I/O did not correspond with an XRun
    XRun() *XRun    
}

type XRunSource interface {
    sound.Source
    XRunner
}

type XRunSink interface {
    sound.Sink
    XRunner
}

type XRunDuplex interface {
    sound.Duplex
    XRunner
}

And then have sio.{Capture,Play,Player,Duplex} return the type with the XRunner extension.

Then the user can test for XRun when they want and handle it at a higher level.

wsc1 commented 6 years ago

This API is traditional and based around the assumption that the interface is to an exposed ring buffer.

cb is not traditional and

  1. Is the first known design to not introduce sample buffering latency in implementing a blocking call by asynchronous callbacks.
  2. As a result of the above, cannot distinguish exactly when xruns appear, but can only track deadlines that would guarantee to not generate xruns if there are no misses.

See the pr and docs for MissedDeadline