XROAR 0.35 issues

A place to discuss everything Dragon related that doesn't fall into the other categories.
sorchard
Posts: 530
Joined: Sat Jun 07, 2014 9:43 pm
Location: Norwich UK

Re: XROAR 0.35 issues

Post by sorchard »

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!
Stew
pser1
Posts: 1655
Joined: Sun Mar 25, 2012 7:32 pm
Location: Barcelona (SPAIN)

Re: XROAR 0.35 issues

Post by pser1 »

Hi Stew,
thanks a lot for this amount of info!
And you are right, the docs talk about 32 cycles instead of 24 as I had thought.
This means that I will have to add an extra NOP to a few places but this will not correct the sound 'artifacts'
because they do happen even from BASIC :-(
Will be playing with these params and hopefully I could find a friendly combination!
cheers
pere
dublevay
Posts: 173
Joined: Wed Jan 23, 2019 3:41 pm

Re: XROAR 0.35 issues

Post by dublevay »

sixxie wrote:Testing locally (which means Linux), there's no difference in CPU usage between the two. Doesn't mean some defaults changes aren't messing you up under Windows though.

Do you see high CPU usage with 0.35? If so, there are more fundamental problems. But if not, try running XRoar with -C (start a console) and seeing what audio settings you get - it may be that tweaking those helps out.

Current dev branch does eat quite a lot more for GMC emulation, but so far I'm calling that a reasonable tradeoff to get more accurate audio... And that doesn't affect what you've been trying anyway :)
Well I had a bit of fun typing xroar -c several times and nothing happened. So I then tried xroar /c, and XROAR starts, but there seems to be no console window at all.
pser1
Posts: 1655
Joined: Sun Mar 25, 2012 7:32 pm
Location: Barcelona (SPAIN)

Re: XROAR 0.35 issues

Post by pser1 »

Hi, I might be wrong, but I think that the parameter (in this case) should be written in uppercase ( xroar -C ... )
cheers
pere
sixxie
Posts: 1346
Joined: Fri Jul 18, 2008 8:36 am
Location: Hertfordshire
Contact:

Re: XROAR 0.35 issues

Post by sixxie »

Oh yes, uppercase -C. Lowercase -c specifies an alternate config file.

BTW: thanks Stewart for providing some excellent tech support there - couldn't have put it better :)

The SDL2 (what Windows uses) defaults are for three fragments of 1024 frames, which should be enough for anyone, but you never know. The format may affect things too - it's worth playing around with "-ao-format float" or "-ao-format s16".

In each case, the defaults are what just what seems to cause the least issues for testers...
pser1
Posts: 1655
Joined: Sun Mar 25, 2012 7:32 pm
Location: Barcelona (SPAIN)

Re: XROAR 0.35 issues

Post by pser1 »

Hello,
I have added the parameter
-ao-format float
Now the sound is continuous whithout any artifact/spike
It works flawlessly with the GMC alone and in the setup with MPI and CoCo-SDC

@Stew and Ciaran
Thanks a lot for your help!

cheers
pere
sixxie
Posts: 1346
Joined: Fri Jul 18, 2008 8:36 am
Location: Hertfordshire
Contact:

Re: XROAR 0.35 issues

Post by sixxie »

Hmm, so same problem with same solution as Bosco.

Does Windows now prefer floating point audio generally? It never used to!

Or I wonder if somehow my gain defaults introduce clipping somewhere now which probably shows up worse in integer formats...
dublevay
Posts: 173
Joined: Wed Jan 23, 2019 3:41 pm

Re: XROAR 0.35 issues

Post by dublevay »

I'm still none the wiser on this. If I do XROAR /C, I get...

Module init: Windows SDL2 UI
Module init: Windows file requester
Module init: SDL2 video
Module init: SDL2 audio
16-bit signed little-endian, stereo, 48000Hz
3 frags * 1024 frames/frag = 3072 frames buffer (64.0ms)
No joysticks found
Machine: Dragon 64
Loading ROM image: ./d64_1.rom
Loading ROM image: ./d64_2.rom
32K mode BASIC CRC = 0x60a4634c
64K mode BASIC CRC = 0x17893a42
Cartridge: DragonDOS
Loading ROM image: ./ddos10.rom
CRC = 0xb44536f6

It works...but it's REALLY slow.
sixxie
Posts: 1346
Joined: Fri Jul 18, 2008 8:36 am
Location: Hertfordshire
Contact:

Re: XROAR 0.35 issues

Post by sixxie »

Actually noticeably slow (rather than just audio glitchy) on a modern machine is a bit of a mystery. Best I can think of is somehow your video drivers aren't allowing SDL2 to use acceleration, but I don't know how that could be.

In pre-SDL2 days, fast video scaling in XRoar depended on OpenGL, but SDL2 is supposed to abstract all that direct-whatever stuff which AFAIK is bolted into every windows these days. And I think you'd know if that wasn't working as pretty much everything is going to use it now...
dublevay
Posts: 173
Joined: Wed Jan 23, 2019 3:41 pm

Re: XROAR 0.35 issues

Post by dublevay »

sixxie wrote:Actually noticeably slow (rather than just audio glitchy) on a modern machine is a bit of a mystery. Best I can think of is somehow your video drivers aren't allowing SDL2 to use acceleration, but I don't know how that could be.

In pre-SDL2 days, fast video scaling in XRoar depended on OpenGL, but SDL2 is supposed to abstract all that direct-whatever stuff which AFAIK is bolted into every windows these days. And I think you'd know if that wasn't working as pretty much everything is going to use it now...
OK - am updating nVidia drivers now (card is a few years old - GeForce 660 Ti - but not exactly from the dark ages!)
Post Reply