In thread [fuse-emulator-devel] Fwd: Emu Speed runaway, on 03/05/16 17:56, BogDan wrote:
I experienced the same problem on Android (Check the attached patch from https://sourceforge.net/p/fuse-emulator/patches/349/) . The problem is that FUSE expects that the sound engine waits until it process the sound data which in some cases is not ok :).
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
It's like this as syncing to the computer version of time will mean that we occasionally do not have enough sound to fill the buffer and will get a sound glitch (maybe a lesser issue on a soc device like a phone as there is likely one master clock for all of sound/cpu/video and opens the possibility of syncing to video frames instead like on zxds).
In the general case Fuse requires that when sound is enabled that the audio driver perform audio syncing and that is probably what is missing from the pulse audio driver).
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi BogDan,
What sound driver do you use on Android? Does it have a blocking write or sound playback callback mode?
It seems like you are wanting a third sound enabled mode that just has Fuse running with a 10ms time buffer like we do with sound off but generating sound to the lowlevel driver.
I think we can do that with less conditional compilation in timer.c than in the proposed patch with a little refactoring but it would be nice to understand why neither of the two existing options works for you :)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I'm using Qt's http://doc.qt.io/qt-5/qaudiooutput.html wrapper, which on Androd it uses OpenSL ES to stream the audio data. Last time I checked it has no blocking write and there is no callback (QIODevice::bytesWritten signal is not fired).
I tried compute & wait for bytesWritten myself, but it didn't woked well.
I also tried alsa way, to try to write until all the pending data is sent to the second buffer (I'm using double buffering), again I faced probelms (pops & cracks).
This patch is small and it should not affect the other implementations.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Background from BogDan:
In thread [fuse-emulator-devel] Fwd: Emu Speed runaway, on 03/05/16 17:56, BogDan wrote:
My feedback at the time:
Hi BogDan,
What sound driver do you use on Android? Does it have a blocking write or sound playback callback mode?
It seems like you are wanting a third sound enabled mode that just has Fuse running with a 10ms time buffer like we do with sound off but generating sound to the lowlevel driver.
I think we can do that with less conditional compilation in timer.c than in the proposed patch with a little refactoring but it would be nice to understand why neither of the two existing options works for you :)
Hi,
I'm using Qt's http://doc.qt.io/qt-5/qaudiooutput.html wrapper, which on Androd it uses OpenSL ES to stream the audio data. Last time I checked it has no blocking write and there is no callback (QIODevice::bytesWritten signal is not fired).
I tried compute & wait for bytesWritten myself, but it didn't woked well.
I also tried alsa way, to try to write until all the pending data is sent to the second buffer (I'm using double buffering), again I faced probelms (pops & cracks).
This patch is small and it should not affect the other implementations.