Sound distorted when using AHI and a sound card

[DvdBoon]

Using AHI together with a sound card results in a distorted sound. Using the Paula audio-modes from AHI does not give this distorted sound.

Current hypothesis is because there is no priority-based scheduler yet in the sonnet.library (all tasks get equal time) the sound task gets not enough cpu time (switches away too much).

[rkujawa]

I'd think so, since reports so far indicate the problem appears more often with higher sample playback rate.

The other thing that might happen is some PCI bus contention, note the traffic on PCI bus is pretty high in case of game that uses PCI to transfer data between 68k, PPC CPU, graphics and sound cards.

[DvdBoon]

Well, been busy this weekend with the sound issue. Thinking out loud here:

Looking into the various programs using AHI shows that the programs actually not really use different priorities/niceness for the various tasks. Frogger uses a nice level of 1 for audio and video decoding which means it gets slightly less CPU time than the main program. The rest have a nice level of 0.

Upping the switch frequency from 20 ms to 0.5 ms removes the stuttering from single threaded programs like Quake and glQuake, but not for multi-threaded games like Quake2.

It's still either scheduler or interrupt related. There's still the strange observation that Run68K does a context switch of 0.5 ms according to WarpRace, while RunPPC does 6.0 ms (while using the same mechanisms on both sides). Maybe there's a problem in the task switching on the PPC side with tasks having a default run time of 6 ms because interruption/signalling fails somehow. In the case of Quake2 (which has 3 tasks running) it would mean a latency of 18 ms before the sound task would get CPU time again, even when asking CPU time long before that. (resulting in a buffer under-run).

The fact that upping the frequency of the decrementer interrupt helps with single threaded software would indicate a problem with getting tasks back from the wait status correctly. Upping the decrementer frequency did not lower the RunPPC lateny of 6 ms.

I'll add debug code to measure the switch latency of RunPPC directly, bypassing the scheduler.

[DvdBoon]

The 6 ms RunPPC issue was caused by MEMF_Clearing a lot of memory inside the RunPPC() function. This has been fixed and the RunPPC functions now takes 0.5 ms which is in line with WarpOS. Did did not fix the sound stutter, however.

[rkujawa]

Out of curiosity: is the DMA buffer allocated withitn graphics card memory, or Sonnet memory? Now that we have the same extended attribute as pci.library-installed memory.

[DvdBoon]

I assume that DMA buffer is allocated at initialization of pci.library which means that it always goes to graphics card memory. Have not checked it, though.

[DvdBoon]

It's also with Paula when playing Curse of Monkey Island.

[rkujawa]

You mean ScummVM version or native Amiga version?

[DvdBoon]

The PC version. There is no native Amiga version (It's Monkey Island 3).

[rkujawa]

Right. The whole problem is rather mysterious. Now that it appeared for Paula too, I'd say it has nothing to do with the DMA buffer (which I though might be the culprit).

Sound issues are always highly dependant on the scheduler too. But now that its latency was fixed... I can't even take a guess what else might be wrong here.

[DvdBoon]

This needs a retest. With the new experimental internal builds, PCI memory can be set to Write-Through memory (instead of Cache-Inhibited). This speeds up 68K execution in the PCI memory range. It slows PPC execution down with 5%, however due to extra cache-flushing.

[togflops]

AmigaAMP doesn't sound distorted playing MP3s locally. I guess what is happening is depending on 68k CPU load AHI will start to distort or if too many channels trying to mix at the same time. ScummVM will play at 44khz rate with no discernable distortion but if there is speech over the soundtrack or it's a later game the sound will get distorted. Frogger is almost always distorted when using AHI to a sound card.