SDL 2.0.4, MacOsX and 32 Bits: bad sound, bad render

SDL Development
1

Hello,

I’m working on the MacosX build of Hatari (https://hatari.tuxfamily.org/).

While trying to make an universal build (32/64 bits), I have some
problems when running in 32 Bits mode:

  • bad sound (crack/noise)
  • bad render (looks like screnn is aliased, which is not supposed to
    be). Screen have a little black border that do not appear while running
    in 64 bits mode.
  • very slow rendering.

The sound problem may be related to the 2 others, as Hatari look like
slower in 32 bits mode.

It work perfectly in 64 bits mode.

It’s SDL related, because when building with 2.0.3, it works (but bugs
in SDL 2.0.3 build of SDL on MacOsX prevent the use of 2.0.3, such as
mouse capture, full screen, etc).

It came in the 2.0.4 sources, some months ago, but cannot say when
exactly… One people have some working 2.0.4 sources, when he used
them, it’s working well.

Any help ?

JV

2

Le 19/09/2016 ? 19:37, Jerome Vernet a ?crit :

Hello,

I’m working on the MacosX build of Hatari (https://hatari.tuxfamily.org/).

While trying to make an universal build (32/64 bits), I have some
problems when running in 32 Bits mode:

  • bad sound (crack/noise)
  • bad render (looks like screnn is aliased, which is not supposed to
    be). Screen have a little black border that do not appear while running
    in 64 bits mode.
  • very slow rendering.

I can say that the sound problem appear between revision 8910 and 9000
of the mercurial ;).

Trying to find the right one…

JV

3

Le 19/09/2016 ? 22:14, Jerome Vernet a ?crit :

Le 19/09/2016 ? 19:37, Jerome Vernet a ?crit :

Hello,

Ok, found the revision wich cause the sound problem in 32 bits:

Changeset: 8919 : c9be8299ba6b
Parent: 8917
Author: Sam Lantinga
Branch: default
Description: Fixed bug 2467 - bad memcpy in
SDL_OpenAudio/open_audio_device/prepare_audiospec chain

Rainer Deyke

If ‘SDL_OpenAudio’ is called with ‘obtained == NULL’,
‘prepare_audiospec’ performs a bad ‘memcpy’ with the destination and
source pointing to the same block of memory. The problem appears to be
on in ‘SDL_OpenAudio’, which calls open_audio_device with ‘obtained =
desired’ when ‘obtained == NULL’. ‘open_audio_device’ cannot deal with
’desired’ and ‘obtained’ pointing to the same block of memory but can
deal with 'obtained == NULL’
Modified: src/audio/SDL_audio.c

Before: it works, after, don’t. No problem in 64 bits on MacOsX, even
after this revision.

Any direction to deal with that ? Is it a SDL bug or Hatari bug ?

JVDate: 2 years ago (24 juin 2014 10:38)

4

Hello,

Found the problem. It’s not (really) SDL problem but in Hatari.

When using SDL_OpenAudio, you NEED to pass as second parameter a
SDL_AudioSpec, NOT null. SDL return in this SDL_AudioSpec what it get,
NO MORE in the first parameter.
In 32 Bit, on MacOsX, desiredAudioSpec.size is not initialized and take
whatever value.

So the code have to be:

SDL_AudioSpec desiredAudioSpec,obtained;
…
if (SDL_OpenAudio(&desiredAudioSpec, &obtained)) /* Open audio device */
{
fprintf(stderr, “Can’t use audio: %s\n”, SDL_GetError());
bSoundWorking = false;
ConfigureParams.Sound.bEnableSound = false;
SDL_QuitSubSystem(SDL_INIT_AUDIO);
return;
}

SoundBufferSize = obtained.size;    /* May be different than the

requested one! /
SoundBufferSize /= 4; / bytes -> samples (16 bit
signed stereo -> 4 bytes per sample) */
if (SoundBufferSize > MIXBUFFER_SIZE/2)
{
fprintf(stderr, “Warning: Soundbuffer size is too big!\n”);
}