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

fix pulse buffering #899

Merged
merged 2 commits into from
Mar 31, 2024
Merged

fix pulse buffering #899

merged 2 commits into from
Mar 31, 2024

Conversation

sthibaul
Copy link
Collaborator

No description provided.

Using the simple API is indeed simple, but does not provide flexible control
over audio writing, and can notably lead to underruns. This is
essentially the same as before, except that we keep writing audio data
as much as possible, since we can now control interrupting it from
spd_pa_simple_flush.

What we want is:

- Reduce server-side pre-buffering to min_audio_length
  - So playback can start as soon as reasonably possible without risking
    underruns
- Push as much data to the server as possible
  - So we avoid underruns
- Be able to stop as quickly as possible

Inlining the pulse simple implementation is not that complex and provides
best flexibility to achieve that.

That will also allow use to use pa_stream_get_time etc. to get the
playback position for proper indexing.

Fixes brailcom#885
We are actually fine with the server using a long buffer. What we
however want is for playback to start early. Flushing will discard the
long buffer anyway.
@sthibaul sthibaul merged commit 2ea44ed into brailcom:master Mar 31, 2024
2 checks passed
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

Successfully merging this pull request may close these issues.

1 participant