Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

proposal for xrun interface #15

Open
wsc1 opened this issue Sep 19, 2018 · 2 comments
Open

proposal for xrun interface #15

wsc1 opened this issue Sep 19, 2018 · 2 comments

Comments

@wsc1
Copy link
Member

wsc1 commented Sep 19, 2018

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
Copy link
Member Author

wsc1 commented Sep 28, 2018

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
Copy link
Member Author

wsc1 commented Sep 29, 2018

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant