[Scummvm-devel] New release, same FMOPL

[Max Horn]

Am Freitag, 11.07.03 um 04:12 Uhr schrieb J.Brown (Ender):

> There was no discussion.
Yes there was a discussion. Check the #scummvm logs.

>  I had originally veto'ed instating the new
> emulator for performance reasons, however somebody inserted it in CVS
> anyway,
Yes I inserted it. After discussion. And you did veto it. When asked by 
us why, all reasons you gave at that time were easily disproved. Since 
you didn't come up with any rational reason against it, we (several 
people on #scummvm) agreed to go with it anyway.

>  insisting there were great noticable gains in sound quality.
Err... at least quote properly, Ender. Even better, actually quote what 
was that using our IRC logs, instead of incorrectly paraphrasing  8-)


> I'm a bit tone-deaf myself, but if you yourself say there isn't, then I
> see no reason to keep the 'new' FMOPL code.
<shrug> If it causes concrete problems for people, revert it.

>
> The FMOPL emulator is from MAME, and there HAVE apparantly been fixes 
> made
> recently. However unless any of them fix the problems on the iPaq and
> similar devices, please feel free to roll back to the previous emulator
> perminently in CVS.
>
There are definitely bugs in the old FMOPL code when it comes to 
accuracy. But since it is apparently to slow to run smoothly on iPaq 
(and DC?), we can revert it. Also I am not really convinced it's too 
slow, nobody gave any data. Stutter in a sound callback drive playback 
engine does *not* mean the system is too slow to handle the load, 
rather it just means that the sound data generation takes longer than 
the max. allowable latency of the sound callback. Usually that 
"problem" is easily solved by using the producer-consumer thread 
pattern.

As it is the easiest right now to revert the changes, rather than 
implementing this, do it (you probably did already anyway, still need 
to catch up with CVS).


Cheers,

Max