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

examples/flappy: SE sometimes doesn't play on macOS #1680

Closed
hajimehoshi opened this issue Jun 24, 2021 · 5 comments
Closed

examples/flappy: SE sometimes doesn't play on macOS #1680

hajimehoshi opened this issue Jun 24, 2021 · 5 comments

Comments

@hajimehoshi
Copy link
Owner

hajimehoshi commented Jun 24, 2021

CC @wasedaigo

@hajimehoshi hajimehoshi added this to the v2.2.0 milestone Jun 24, 2021
@hajimehoshi
Copy link
Owner Author

I could reproduce this issue with examples/wav. Rewind seems suspicious.

@hajimehoshi
Copy link
Owner Author

There is a race condition: there are two src.Read.

@hajimehoshi
Copy link
Owner Author

git bisect says 72d8d77 is the culprit.

hajimehoshi added a commit that referenced this issue Jun 24, 2021
Apparently #1680 seems pretty hard to fix. Use the old Oto
implementation until this issue is fixed.

Updates #1680
@hajimehoshi
Copy link
Owner Author

So I thought AudioQueuePause must be called regardless of the number of unqueued buffers. However, this caused the same issue as #1650. It seems inevitable to do self-mixing...

diff --git a/audio/internal/readerdriver/driver_darwin.go b/audio/internal/readerdriver/driver_darwin.go
index bcb36a7e..c96e6bee 100644
--- a/audio/internal/readerdriver/driver_darwin.go
+++ b/audio/internal/readerdriver/driver_darwin.go
@@ -33,7 +33,7 @@ import (
 )
 
 func IsAvailable() bool {
-       return false
+       return true
 }
 
 type audioQueuePoolItem struct {
@@ -495,11 +495,12 @@ func (p *playerImpl) resetImpl() {
                return
        }
 
+       if osstatus := C.AudioQueuePause(p.audioQueue); osstatus != C.noErr && p.err == nil {
+               p.setErrorImpl(fmt.Errorf("readerdriver: AudioQueuePause failed: %d", osstatus))
+               return
+       }
+
        if len(p.unqueuedBufs) < 2 {
-               if osstatus := C.AudioQueuePause(p.audioQueue); osstatus != C.noErr && p.err == nil {
-                       p.setErrorImpl(fmt.Errorf("readerdriver: AudioQueuePause failed: %d", osstatus))
-                       return
-               }
                // AudioQueueReset invokes the callback directry.
                q := p.audioQueue
                p.m.Unlock()

@hajimehoshi
Copy link
Owner Author

hajimehoshi commented Jun 24, 2021

hajimehoshi added a commit that referenced this issue Jul 8, 2021
Creating a new AudioQueue is more expensive than expected, and
this caused a little blocking the game when playing a lot of SEs.

Closes #1702
Updates #1680
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant