MarkKremer
commented
2 years ago Some notes:
- The new Oto player requests samples instead of that we push samples to it.
-
UnplayedBufferSize()could potentially give us some fine-grained control over the buffer, however:-
Oto's internal buffer seems to be 1/4th or 1/2nd of a second long: link
// oneBufferSize returns the size of one buffer in the player implementation. func (c *context) oneBufferSize() int { bytesPerSample := c.channelNum * c.bitDepthInBytes s := c.sampleRate * bytesPerSample / 4 // Align s in multiples of bytes per sample, or a buffer could have extra bytes. return s / bytesPerSample * bytesPerSample }
// maxBufferSize returns the maximum size of the buffer for the audio source. // This buffer is used when unreading on pausing the player. func (c context) maxBufferSize() int { // The number of underlying buffers should be 2. return c.oneBufferSize() 2 }
- It will only add the player after the whole buffer is filled and it will request samples until it has done so or it receives an `EOF`. This is fine if you want to play a song but for game sounds this is an unacceptable delay. ```golang if !p.eof { buf := p.ensureTmpBuf() for len(p.buf) < p.context.maxBufferSize() { n, err := p.src.Read(buf) if err != nil && err != io.EOF { p.setErrorImpl(err) return } p.buf = append(p.buf, buf[:n]...) if err == io.EOF { if len(p.buf) == 0 { p.eof = true } break } } } if !p.eof || len(p.buf) > 0 { p.state = playerPlay } p.m.Unlock() p.players.addPlayer(p) p.m.Lock()- After the player is added we can return however many samples we like. But it will keep requesting samples until the buffer is filled so that may use unnecessary cpu power.
-
- I would like it if we could check which buffers on our end we really need and if they do potentially add any delays if they aren't filled completely. I want to reduce any delays we can.
- It could be an option to remove
beep.Mixerfrom thebeep.Playerimplementation by adding a Oto player for each streamer. This would remove another buffer on our side. Another benefit is that the shared buffer doesn't need to be drained before an additional sound can be played. For example, for background music in a game it's fine to have >0.5sec buffered. But when you want to play an attack sound at the same time, you don't want to wait before the shared buffer is drained. When adding a new player, we need to provide 0.5sec of samples of that sound still, but we don't have to wait on the shared buffer to start playing. This may or may not make the speaker slightly unpredictable if you want to play 2 sounds at the exact same time. We could try to minimize this effect when implementing, but if it is not possible the user could always just use a mixer themselves.
I may be wrong on some things here. There are a lot of small details to oversee.
I would like to hear other people's thoughts/wishes on this as well.
I may try to implement Oto 2 with Beep. If it takes too long, feel free to work on this yourself. I can't spend loads of time on the computer right now.
mewmew
hajimehoshi
faiface
tinne26
arthurspa
Oto v2.0 was just released :) https://github.com/hajimehoshi/oto/releases/tag/v2.0.0
This issue tracks the work to update beep to use the latest version of Oto, bring with it performance increases.