Re: [AD] Amiga OS 4.3.10plus patch

[ Thread Index | Date Index | More lists.liballeg.org/allegro-developers Archives ]


Hi Elias.

Sorry for the delay in replying - been sorting out some other bugs.

On 29/01/2009, you wrote:
>> 
>> the mixer code supports real-time conversion to signed if the sound
>> > driver asks for it.
>> 
>> Could you elaborate?  I had a look through src/sound.c and src/mixer.c
>> but couln't find anything like this.
>
> http://www.liballeg.org/stabledocs/en//alleg001.html#SAMPLE
>
> The data field of SAMPLE is a public, documented field, so games access
> it directly and modify it. Therefore it always is unsigned. This can't
> be changed.

This is a problem.  :-(

>> This is the "big" issue that I have to sort out before I can submit
>> the OS4 port.  Currently I have a system that got rejected when I
>> suggeseted it whereby I updated the routines that load audio samples
>> from .dat files, from .voc files and from .wav files so that they can
>> convert the loaded data to signed format if requested by the sound
>> driver.  This works well but when I suggested doing it like this on
>> this list a while ago it got rejected.  Are you saying that this can
>> be done dynamically already?
>
> The last parameter of _mix_some_samples tells the Allegro mixer whether
> to output to signed or unsigned - so if the Amiga sound system expects
> signed data, you should set it to TRUE (then send the data in the
> buffer to the sound system). Maybe look at src/unix/alsa9.c or
> src/win/wdsndmix.c or src/macosx/soundman.m.

The problem here is that _mix_some_samples isn't called by default.  Are you
saying that I should allocate some buffers in my sound driver and use this
to convert the sample data to signed format dynamically, every time I play
a sample?  This is inefficient, and could have issues with the streaming
MP3 and MOD libraries, which seem to output in signed format already (!).

>> Also, even if my suggestion got accepted, we have a situation where
>> some games are a bit "odd" in that they seem to use the "opposite"
>> signedness of what they should.  For example, in .dat files 8 bit
>> samples are in unsigned format and 16 bit samples are in signed
>> format.  Normally the datafile loader will leave 8 bit samples as they
>> are and will convert 16 bit samples to unsigned.  So I put in some
>> code to do the opposite and leave the 16 bit samples as they are and
>> convert the 8 bit samples to signed.  Fine.  This works 99% of the
>> time.
>
>> But then I found some games where the occasional sample is *opposite*
>> what it should be!  So I end up feeding a sample of the wrong
>> signedness into my sound card and get white noise.  Yet this same game
>> works fine on Windows but I can't see anywhere where Allegro checks
>> the signedness of samples when loading them!
>> 
>
> Is the source and data of this game available? As far as I understand,
> that shouldn't be possible. But it's some time I looked at the sound
> code, and maybe I never fully understood it either.

I think that I understand it now.  When loading .wav or .voc files then 8
bit data is in unsigned format and 16 bit data is in signed format.  I
*assumed* that this meant that when loading a SAMPLE from a datafile with
load_datafile() then this would also be the case.  But it seems that it is
not and that when loading from a datafile both 8 and 16 bit data is in
*unsigned* format already.

I looked through the documentation but couldn't find anything "official" but
from the source it seems that this is the case.  Can anyone confirm this?

-- 
/-------------------------------------------------------------------\
[Hitman/Code HQ - 6502/z80/68000/604e/80x86/ARM coder - Amiga rulez!]
[VZ-200/VIC-20/MZ-700/c16/c64*10/c128*8/Plus-4/CPC464/CD32/500*2    ]
[600/1000/1200*2/A4000/SNES/N64/Dreamcast/Athlon 1100/AmigaOne      ]
[Assembly Language: The most fun you can have with your clothes on! ]
\-------------------------------------------------------------------/





Mail converted by MHonArc 2.6.19+ http://listengine.tuxfamily.org/