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

pushsamplesreaquestbuff overflow #74

Open
AsheX1 opened this issue Jul 16, 2022 · 3 comments
Open

pushsamplesreaquestbuff overflow #74

AsheX1 opened this issue Jul 16, 2022 · 3 comments
Labels

Comments

@AsheX1
Copy link

AsheX1 commented Jul 16, 2022

i dont know if this is and emu problem or settings as i find 0 settings to change anything about video at all

@ocornut ocornut added the audio label Aug 3, 2022
@sverx
Copy link
Contributor

sverx commented Aug 31, 2022

I'm getting a ton of these errors too... but I'm not concerned about the messages, mainly about the audio being totally broken, at least on my Linux machine. 🤔

I'm trying to understand if I can fix it. It seems like there's not enough space in the buffer to put newly rendered audio data, but even creating a much bigger audio buffer it doesn't solve at all, the buffer gets all used quickly and audio stutters.

#define SOUND_BUFFERS_SAMPLE_COUNT (16384)

But according to the code, when there's not enough space in the buffer to write more data, it just means it's pretty full of data already, so the audio renderer should just not produce any more audio data and come back later. But then audio breaks, which likely means the buffer underruns, even if the Audio Debug window shows plenty of data in the buffer. I'm very puzzled.

@sverx
Copy link
Contributor

sverx commented Aug 31, 2022

I suspect for some reason the replay of the audio uses less data than what the audio engine renders, or the audio engine renders too much data compared to what it needed. I had set #define SOUND_BUFFERS_SAMPLE_COUNT (65536) and the audio becomes totally fine for a few seconds, then the clearly visible effect is that the buffer becomes full of audio data that still need to be played and the emulator wants to push more.

So I would say it's either generating more than 44100 samples/sec or it's reproducing less than that.

@sverx
Copy link
Contributor

sverx commented Aug 31, 2022

The audio coming from the application is definitely at 44100 samples/sec according to pactl list sink-inputs

Sink Input #62
	Driver: protocol-native.c
	Owner Module: 12
	Client: 160
	Sink: 3
	Sample Specification: s16le 2ch 44100Hz
	Channel Map: front-left,front-right
	Format: pcm, format.sample_format = "\"s16le\""  format.rate = "44100"  format.channels = "2"  format.channel_map = "\"front-left,front-right\""
	Corked: no
	Mute: no
	Volume: front-left: 65536 / 100% / 0.00 dB,   front-right: 65536 / 100% / 0.00 dB
	        balance 0.00
	Buffer Latency: 13990 usec
	Sink Latency: 23848 usec
	Resample method: n/a
	Properties:
		media.name = "Allegro Voice"
		application.name = "meka"
		native-protocol.peer = "UNIX socket client"
		native-protocol.version = "33"
		application.process.id = "12699"
		application.process.user = "sverx"
		application.process.host = "redacted"
		application.process.binary = "meka"
		application.language = "C"
		window.x11.display = ":0"
		application.process.machine_id = "939972095cf1459c8b22cc608eff85da"
		application.process.session_id = "c2"
		module-stream-restore.id = "sink-input-by-application-name:meka"

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

No branches or pull requests

3 participants