Re: XROAR 0.35 issues
Posted: Tue Feb 26, 2019 1:07 pm
Hi Pere,
I'm running Debian, so can't offer you much insight as far as Win10 is concerned. When I was running WinXP, I remember having audio trouble when emulating NTSC machines (60Hz video), so there's a clue: The audio buffering needs to be arranged to never run out of data while xroar is blocked waiting for the video.
This means you might have to spend a bit of time tuning your audio settings. There's a load of settings in the xroar manual but here's a few worth concentrating on...
Try to match the audio rate to that of the underlying hardware. That should prevent the driver from resampling the audio. If you don't know the rate then you could try common options like the following:
-ao-rate 44100
-ao-rate 48000
Then there's buffer size. It would be good to match this to the underlying hardware, but I didn't find it very easy to discover the hardware buffer size on my laptop. Try powers of 2 like these:
-ao-fragment-frames 256
-ao-fragment-frames 512
-ao-fragment-frames 1024
Then you have the number of buffers to allocate. At first glance you would think 2 or 3 should be enough, providing the total time is bigger than the video interval but I'm guessing if the software buffer size is not a multiple of the hardware buffer then the mismatch reduces the advantage of having more buffers. Try settings like these:
-ao-fragments 8
-ao-fragments 6
-ao-fragments 4
The total buffer size needs to be bigger than the video interval (fragments * frames / rate) otherwise the audio will run out of data. (crackles and silences). Again just guessing, but it may be better to have a larger number of small buffers, rather than a smaller number of large buffers, to mitigate the effect of a mismatch in buffer size.
The longer the total buffer time, the longer it takes the sound to travel through the layers and out of the speakers, which can add up to a noticeable delay. This is one of the reasons it's good to match the buffer size to the hardware as it can make a big difference to the latency.
I've used the option "-vo null" in the past to run without video and get cleaner sound for recording, but I don't know if that option is available for Windows.
The manual also mentions that not all options are available for all drivers, so you may need to experiment.
A quick note regarding the SN76489AN: The datasheet says it requires approx 32 clocks between writes, which is about 8 normal speed 6809 cycles.
Good Luck!
I'm running Debian, so can't offer you much insight as far as Win10 is concerned. When I was running WinXP, I remember having audio trouble when emulating NTSC machines (60Hz video), so there's a clue: The audio buffering needs to be arranged to never run out of data while xroar is blocked waiting for the video.
This means you might have to spend a bit of time tuning your audio settings. There's a load of settings in the xroar manual but here's a few worth concentrating on...
Try to match the audio rate to that of the underlying hardware. That should prevent the driver from resampling the audio. If you don't know the rate then you could try common options like the following:
-ao-rate 44100
-ao-rate 48000
Then there's buffer size. It would be good to match this to the underlying hardware, but I didn't find it very easy to discover the hardware buffer size on my laptop. Try powers of 2 like these:
-ao-fragment-frames 256
-ao-fragment-frames 512
-ao-fragment-frames 1024
Then you have the number of buffers to allocate. At first glance you would think 2 or 3 should be enough, providing the total time is bigger than the video interval but I'm guessing if the software buffer size is not a multiple of the hardware buffer then the mismatch reduces the advantage of having more buffers. Try settings like these:
-ao-fragments 8
-ao-fragments 6
-ao-fragments 4
The total buffer size needs to be bigger than the video interval (fragments * frames / rate) otherwise the audio will run out of data. (crackles and silences). Again just guessing, but it may be better to have a larger number of small buffers, rather than a smaller number of large buffers, to mitigate the effect of a mismatch in buffer size.
The longer the total buffer time, the longer it takes the sound to travel through the layers and out of the speakers, which can add up to a noticeable delay. This is one of the reasons it's good to match the buffer size to the hardware as it can make a big difference to the latency.
I've used the option "-vo null" in the past to run without video and get cleaner sound for recording, but I don't know if that option is available for Windows.
The manual also mentions that not all options are available for all drivers, so you may need to experiment.
A quick note regarding the SN76489AN: The datasheet says it requires approx 32 clocks between writes, which is about 8 normal speed 6809 cycles.
Good Luck!