Multiple sound libraries at once?

Hi,

I’m working on GNU Freedink (http://www.freedink.org/), which is a
port of the Dink Smallwood game / game engine.

To stay compatible I need a sound system that supports:

  • playing MIDIs
  • playing WAVs at a variable frequency (possibly random)
  • at the same time (multiple channels)

Currently I’m using SDL_mixer (MIDI + multiple channels), and I
implemented a work-around to change the WAV samples frequency at run
time. This is done through a empty sound of the right resampled
length, and a SDL_mixer Effect that replaces the empty buffer with the
run-time-resampled WAV.
http://git.savannah.gnu.org/cgit/freedink.git/tree/src/sfx.c

This works fine enough, but sadly this increases the memory usage
quite a bit (the empty/useless memory buffer + the sample is
pre-converted to the hardware 16/8 MSB/LSB mono/stereo format to
reduce the number of filter combinations, usually better quality than
the original 8bit/mono sounds). As I’m currently porting FreeDink to
the PSP this memory usage becomes critical and I need to get rid of it
:confused:

Essentially I want to keep using SDL_mixer for the MIDI support
(through bundled timidity) and possibly use another library for the
sample frequency support.

So I’m wondering what’s your experience with using multiple sound
libraries at once? Are there hidden limitations?

Alternatively is there interest to add frequency shift support in
SDL_mixer? We could use the MIXER macro from Allegro:
http://alleg.svn.sourceforge.net/viewvc/alleg/allegro/branches/4.4/src/mixer.c?revision=12081&view=markup--
Sylvain

Hi,

I’d be interested in seeing SDL_mixer with frequency shifting support.

I’m using libraries more frequently used with hard-real-time audio
processing applications - libsndfile for loading WAV’s straight into
float buffers - libsamplerate for frequency shifting - and LADSPA
plugins for effects processing post-mix (with a floating point mixer).

It works fairly well, but the run-time re-sampling does not always keep
up (remember it’s all floating point) on a 5yr old laptop (but maybe I
could improve my game code/screen updates/etc).

Personally, I’d like to see int freq-shifting and int fx-processing
included into SDL_mixer (or an SDL add-on lib).

Regards,
James.On 25/4/2009, “Sylvain Beucler” wrote:

Hi,

I’m working on GNU Freedink (http://www.freedink.org/), which is a
port of the Dink Smallwood game / game engine.

To stay compatible I need a sound system that supports:

  • playing MIDIs
  • playing WAVs at a variable frequency (possibly random)
  • at the same time (multiple channels)

Currently I’m using SDL_mixer (MIDI + multiple channels), and I
implemented a work-around to change the WAV samples frequency at run
time. This is done through a empty sound of the right resampled
length, and a SDL_mixer Effect that replaces the empty buffer with the
run-time-resampled WAV.
http://git.savannah.gnu.org/cgit/freedink.git/tree/src/sfx.c

This works fine enough, but sadly this increases the memory usage
quite a bit (the empty/useless memory buffer + the sample is
pre-converted to the hardware 16/8 MSB/LSB mono/stereo format to
reduce the number of filter combinations, usually better quality than
the original 8bit/mono sounds). As I’m currently porting FreeDink to
the PSP this memory usage becomes critical and I need to get rid of it
:confused:

Essentially I want to keep using SDL_mixer for the MIDI support
(through bundled timidity) and possibly use another library for the
sample frequency support.

So I’m wondering what’s your experience with using multiple sound
libraries at once? Are there hidden limitations?

Alternatively is there interest to add frequency shift support in
SDL_mixer? We could use the MIXER macro from Allegro:
http://alleg.svn.sourceforge.net/viewvc/alleg/allegro/branches/4.4/src/mixer.c?revision=12081&view=markup


Sylvain


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

To stay compatible I need a sound system that supports:

  • playing MIDIs
  • playing WAVs at a variable frequency (possibly random)
  • at the same time (multiple channels)

Currently I’m using SDL_mixer (MIDI + multiple channels), and I
implemented a work-around to change the WAV samples frequency at run
time. This is done through a empty sound of the right resampled
length, and a SDL_mixer Effect that replaces the empty buffer with the
run-time-resampled WAV.
http://git.savannah.gnu.org/cgit/freedink.git/tree/src/sfx.c

That sounds great! Question: do you find anything negative about your
current solution aside from the hackishness of creating a fake buffer?

I believe that since you are resampling in real-time (that is to say,
you’re doing it inside an “effect” callback,) that you actually do not
need to give the Mix_Chunk any data at all!

I just looked through the source code for SDL_mixer SVN revision 4211.
Here is the function you are currently using to create your fake
Mix_Chunk:

/* Load raw audio data of the mixer format from a memory buffer */
Mix_Chunk *Mix_QuickLoad_RAW(Uint8 *mem, Uint32 len)
{
Mix_Chunk *chunk;

/* Make sure audio has been opened */
if ( ! audio_opened ) {
    SDL_SetError("Audio device hasn't been opened");
    return(NULL);
}

/* Allocate the chunk memory */
chunk = (Mix_Chunk *)malloc(sizeof(Mix_Chunk));
if ( chunk == NULL ) {
    SDL_SetError("Out of memory");
    return(NULL);
}

/* Essentially just point at the audio data (no error checking - fast) */
chunk->allocated = 0;
chunk->alen = len;
chunk->abuf = mem;
chunk->volume = MIX_MAX_VOLUME;

return(chunk);

}

I am pretty positive (spent about 15 minutes looking through the code
step by step) that SDL_mixer will never touch the contents of
Mix_Chunk.abuf if you register your own effect on it.

This works fine enough, but sadly this increases the memory usage
quite a bit (the empty/useless memory buffer + the sample is
pre-converted to the hardware 16/8 MSB/LSB mono/stereo format to
reduce the number of filter combinations, usually better quality than
the original 8bit/mono sounds). ?As I’m currently porting FreeDink to
the PSP this memory usage becomes critical and I need to get rid of it
:confused:

Just write your own Mix_Chunk allocator function that just sets abuf
to NULL (or whatever you want, really.) Just be careful to make sure
that you only try to play it with your own "effect!"On Sat, Apr 25, 2009 at 1:44 PM, Sylvain Beucler wrote:


http://codebad.com/

Hi,

To stay compatible I need a sound system that supports:

  • playing MIDIs
  • playing WAVs at a variable frequency (possibly random)
  • at the same time (multiple channels)

Currently I’m using SDL_mixer (MIDI + multiple channels), and I
implemented a work-around to change the WAV samples frequency at run
time. This is done through a empty sound of the right resampled
length, and a SDL_mixer Effect that replaces the empty buffer with the
run-time-resampled WAV.
http://git.savannah.gnu.org/cgit/freedink.git/tree/src/sfx.c

That sounds great! Question: do you find anything negative about your
current solution aside from the hackishness of creating a fake buffer?

So far I didn’t hit any problem, besides doubling the channels’ memory
usage.

I believe that since you are resampling in real-time (that is to say,
you’re doing it inside an “effect” callback,) that you actually do not
need to give the Mix_Chunk any data at all!

I just looked through the source code for SDL_mixer SVN revision 4211.
Here is the function you are currently using to create your fake
Mix_Chunk:
<snip!>
I am pretty positive (spent about 15 minutes looking through the code
step by step) that SDL_mixer will never touch the contents of
Mix_Chunk.abuf if you register your own effect on it.

It looks to me that chunk->abuf is assigned to mix_channel[i].samples,
then .samples is passed to Mix_DoEffects(…, void* snd, …), where
there’s a memcpy(…, snd, …).

I also had crashes when using a growable shared buffer (instead of one
buffer per chunk), so I think abuf is used to bootstrap the effects
chain. Did I miss something maybe? :slight_smile:

The main point of using ‘abuf’ though is to define when SDL_Mixer
needs to stop playing, so maybe it’s possible to register small
looping sounds and find a way to stop playing while within the
callback (but I think you shouldn’t call Mix_HaltChannell(…) from
within the callback, this may need to be done from the outside).

This works fine enough, but sadly this increases the memory usage
quite a bit (the empty/useless memory buffer + the sample is
pre-converted to the hardware 16/8 MSB/LSB mono/stereo format to
reduce the number of filter combinations, usually better quality than
the original 8bit/mono sounds). ?As I’m currently porting FreeDink to
the PSP this memory usage becomes critical and I need to get rid of it
:confused:

Just write your own Mix_Chunk allocator function that just sets abuf
to NULL (or whatever you want, really.) Just be careful to make sure
that you only try to play it with your own “effect!”

I just realized that implementing frequency shift in SDL_mixer would
get rid of the fake buffers, but that SDL_mixer would still
pre-convert the sound to the hardware format (using
SDL_BuildAudioCVT(…)).

Since the PSP platform apparently locks the output format to
44.1kHz/S16LSB, my low-quality sounds would still take a lot of
memory. I also need to keep the audio chunks in their original format
and convert them to hardware format at real-time.

To reduce the number of combinations, the frequency-conversion temp
buffer (chunksize=4096B) could be fixed to S16LSB (or even floats) and
would be converted to the hardware format in a second pass, it
wouldn’t take much memory nor CPU I think.On Sat, Apr 25, 2009 at 06:27:31PM -0400, Donny Viszneki wrote:

On Sat, Apr 25, 2009 at 1:44 PM, Sylvain Beucler <@Sylvain_Beucler> wrote:


Sylvain

Hi,

I’m using libraries more frequently used with hard-real-time audio
processing applications - libsndfile for loading WAV’s straight into
float buffers - libsamplerate for frequency shifting - and LADSPA
plugins for effects processing post-mix (with a floating point mixer).

I see what you mean.
I take it you’re not using SDL_mixer at all?

It works fairly well, but the run-time re-sampling does not always keep
up (remember it’s all floating point) on a 5yr old laptop (but maybe I
could improve my game code/screen updates/etc).

Do you pre-convert the whole sound before playing, or is it done
incrementally on the current audio buffer (~4kB)?

Personally, I’d like to see int freq-shifting and int fx-processing
included into SDL_mixer (or an SDL add-on lib).

What is fx-processing (compared to Mix_RegisterEffect(…))?On Sat, Apr 25, 2009 at 09:05:45PM +0000, james morris wrote:


Sylvain

Hi,

I’m using libraries more frequently used with hard-real-time audio
processing applications - libsndfile for loading WAV’s straight into
float buffers - libsamplerate for frequency shifting - and LADSPA
plugins for effects processing post-mix (with a floating point mixer).

I see what you mean.
I take it you’re not using SDL_mixer at all?

No. The mixer from http://olofson.net/download/DT-42-0.1.0.tar.gz
modified+converted to handle floating point.

It works fairly well, but the run-time re-sampling does not always keep
up (remember it’s all floating point) on a 5yr old laptop (but maybe I
could improve my game code/screen updates/etc).

Do you pre-convert the whole sound before playing, or is it done
incrementally on the current audio buffer (~4kB)?

No the resampling is incremental using a buffer. 256*sizeof(float).

Personally, I’d like to see int freq-shifting and int fx-processing
included into SDL_mixer (or an SDL add-on lib).

What is fx-processing (compared to Mix_RegisterEffect(…))?

Reverb, echo, high/low pass filter, EQ etc, actual effects processing
alorithms.

If you want a look, there’s code here:
http://jwm-art.net/XorGramana/XorGramana-0.0.10.tar.bz2

resampling+mixer+fx processing: smixer.*
basic sequencing & fx chain creation: audio_gen.*
LADSPA plugin wrappers: sfx_.
LADSPA lib loading: ladspa_loader.*

It’s a work in progress :wink:

James.On 26/4/2009, “Sylvain Beucler” wrote:

On Sat, Apr 25, 2009 at 09:05:45PM +0000, james morris wrote:

It seems your email client doesn’t play well with mine. This latest
email appears to be its own thread, not organized with the others.

I am pretty positive (spent about 15 minutes looking through the code
step by step) that SDL_mixer will never touch the contents of
Mix_Chunk.abuf if you register your own effect on it.

It looks to me that chunk->abuf is assigned to mix_channel[i].samples,
then .samples is passed to Mix_DoEffects(…, void* snd, …), where
there’s a memcpy(…, snd, …).

Yes, you’re right! I don’t know how I overlooked the if (!posteffects)
part. (On an unrelated note, how ridiculous is it to invoke malloc
there?)

I also had crashes when using a growable shared buffer (instead of one
buffer per chunk), so I think abuf is used to bootstrap the effects
chain. ?Did I miss something maybe? :slight_smile:

Growable shared buffer? How did you achieve that? Something like
mmap() /dev/null ?

The main point of using ‘abuf’ though is to define when SDL_Mixer
needs to stop playing, so maybe it’s possible to register small
looping sounds and find a way to stop playing while within the
callback (but I think you shouldn’t call Mix_HaltChannell(…) from
within the callback, this may need to be done from the outside).

Err…

I just realized that implementing frequency shift in SDL_mixer would
get rid of the fake buffers, but that SDL_mixer would still
pre-convert the sound to the hardware format (using
SDL_BuildAudioCVT(…)).

Since the PSP platform apparently locks the output format to
44.1kHz/S16LSB, my low-quality sounds would still take a lot of
memory. I also need to keep the audio chunks in their original format
and convert them to hardware format at real-time.

You know, if you’re writing this primarily for the PSP, you would
probably do better to write your own mixer. SDL_mixer is
inappropriate for you: it has features you don’t need, and doesn’t
have features you do need. Perhaps you’re proposing what I’m now
thinking: to start with SDL_mixer and modify it a bit to suit your
needs.

To reduce the number of combinations, the frequency-conversion temp
buffer (chunksize=4096B) could be fixed to S16LSB (or even floats) and
would be converted to the hardware format in a second pass, it
wouldn’t take much memory nor CPU I think.

Just out of curiosity: is this just resampling? Or proper pitch shifting FFT?On Sun, Apr 26, 2009 at 3:58 AM, Sylvain Beucler wrote:

On Sat, Apr 25, 2009 at 06:27:31PM -0400, Donny Viszneki wrote:

On Sat, Apr 25, 2009 at 1:44 PM, Sylvain Beucler wrote:


http://codebad.com/

I also had crashes when using a growable shared buffer (instead of one
buffer per chunk), so I think abuf is used to bootstrap the effects
chain. ?Did I miss something maybe? :slight_smile:

Growable shared buffer? How did you achieve that? Something like
mmap() /dev/null ?

No, just a realloc. It was for storing the dummy buffer.
Shared == “used by all the chunks” (not by different processes).

I just realized that implementing frequency shift in SDL_mixer would
get rid of the fake buffers, but that SDL_mixer would still
pre-convert the sound to the hardware format (using
SDL_BuildAudioCVT(…)).

Since the PSP platform apparently locks the output format to
44.1kHz/S16LSB, my low-quality sounds would still take a lot of
memory. I also need to keep the audio chunks in their original format
and convert them to hardware format at real-time.

You know, if you’re writing this primarily for the PSP, you would
probably do better to write your own mixer. SDL_mixer is
inappropriate for you: it has features you don’t need, and doesn’t
have features you do need. Perhaps you’re proposing what I’m now
thinking: to start with SDL_mixer and modify it a bit to suit your
needs.

Well it’s a portable game engine, but indeed I could write something
specific to the PSP platform (in addition to the existing portable
version).

However, since I’ve been struggling with SDL_mixer’s limitations for a
couple years and still doesn’t see the end of it, I’m in favor of
improving it.

Writing a mixer from scratch means I’ll have to re-implement the
timidity support, which I’m not exactly interested in :wink:
Unless there’re other decent MIDI engines?

To reduce the number of combinations, the frequency-conversion temp
buffer (chunksize=4096B) could be fixed to S16LSB (or even floats) and
would be converted to the hardware format in a second pass, it
wouldn’t take much memory nor CPU I think.

Just out of curiosity: is this just resampling? Or proper pitch shifting FFT?

Just resampling. The resulting tone change is the desired effect :)–
Sylvain

I also had crashes when using a growable shared buffer (instead of one
buffer per chunk), so I think abuf is used to bootstrap the effects
chain. ?Did I miss something maybe? :slight_smile:

Growable shared buffer? How did you achieve that? Something like
mmap() /dev/null ?

No, just a realloc. It was for storing the dummy buffer.
Shared == “used by all the chunks” (not by different processes).

Ah, I think you need to read up on realloc()! Sometimes it moves your
buffer to another address, invalidating old pointers!

You know, if you’re writing this primarily for the PSP, you would
probably do better to write your own mixer. SDL_mixer is
inappropriate for you: it has features you don’t need, and doesn’t
have features you do need. Perhaps you’re proposing what I’m now
thinking: to start with SDL_mixer and modify it a bit to suit your
needs.

Well it’s a portable game engine, but indeed I could write something
specific to the PSP platform (in addition to the existing portable
version).

However, since I’ve been struggling with SDL_mixer’s limitations for a
couple years and still doesn’t see the end of it, I’m in favor of
improving it.

Good luck!On Tue, Apr 28, 2009 at 3:48 PM, Sylvain Beucler wrote:


http://codebad.com/

There’s a misunderstanding: I mentioned this old realloc solution to
show that abuf was indeed used. I’m aware that the buffer moves.On Tue, Apr 28, 2009 at 04:30:45PM -0400, Donny Viszneki wrote:

On Tue, Apr 28, 2009 at 3:48 PM, Sylvain Beucler <@Sylvain_Beucler> wrote:

I also had crashes when using a growable shared buffer (instead of one
buffer per chunk), so I think abuf is used to bootstrap the effects
chain. ?Did I miss something maybe? :slight_smile:

Growable shared buffer? How did you achieve that? Something like
mmap() /dev/null ?

No, just a realloc. It was for storing the dummy buffer.
Shared == “used by all the chunks” (not by different processes).

Ah, I think you need to read up on realloc()! Sometimes it moves your
buffer to another address, invalidating old pointers!


Sylvain

Ah! That makes so much sense!On Tue, Apr 28, 2009 at 4:47 PM, Sylvain Beucler wrote:

On Tue, Apr 28, 2009 at 04:30:45PM -0400, Donny Viszneki wrote:

On Tue, Apr 28, 2009 at 3:48 PM, Sylvain Beucler wrote:

I also had crashes when using a growable shared buffer (instead of one
buffer per chunk), so I think abuf is used to bootstrap the effects
chain. ?Did I miss something maybe? :slight_smile:

Growable shared buffer? How did you achieve that? Something like
mmap() /dev/null ?

No, just a realloc. It was for storing the dummy buffer.
Shared == “used by all the chunks” (not by different processes).

Ah, I think you need to read up on realloc()! Sometimes it moves your
buffer to another address, invalidating old pointers!

There’s a misunderstanding: I mentioned this old realloc solution to
show that abuf was indeed used. I’m aware that the buffer moves.


http://codebad.com/

[…]

Writing a mixer from scratch means I’ll have to re-implement the
timidity support, which I’m not exactly interested in :wink:
Unless there’re other decent MIDI engines?

FluidSynth…?

http://fluidsynth.resonance.org/trac

Cross platform, LGPL, uses SoundFont 2, has built-in MIDI file
playback, built-in effects etc.On Tuesday 28 April 2009, Sylvain Beucler wrote:


//David Olofson - Programmer, Composer, Open Source Advocate

.------- http://olofson.net - Games, SDL examples -------.
| http://zeespace.net - 2.5D rendering engine |
| http://audiality.org - Music/audio engine |
| http://eel.olofson.net - Real time scripting |
’-- http://www.reologica.se - Rheology instrumentation --’

Oh, and another option might be SDL_sound:

http://icculus.org/SDL_sound/

This may or may not be more appropriate than FluidSynth for
integrating into a mixer; I would THINK FluidSynth could
run “passively”, letting you manage the audio I/O as well, but I’m
not sure.

Either way, SDL_sound supports a bunch of other audio formats as well,
including loads of “module” formats through MikMod and ModPlug. I
don’t know how MIDI playback (as in, the actual synth) is
implemented, though; just looking at the feature list here…On Wednesday 29 April 2009, David Olofson wrote:

On Tuesday 28 April 2009, Sylvain Beucler wrote:
[…]

Writing a mixer from scratch means I’ll have to re-implement the
timidity support, which I’m not exactly interested in :wink:
Unless there’re other decent MIDI engines?

FluidSynth…?

http://fluidsynth.resonance.org/trac

Cross platform, LGPL, uses SoundFont 2, has built-in MIDI file
playback, built-in effects etc.


//David Olofson - Programmer, Composer, Open Source Advocate

.------- http://olofson.net - Games, SDL examples -------.
| http://zeespace.net - 2.5D rendering engine |
| http://audiality.org - Music/audio engine |
| http://eel.olofson.net - Real time scripting |
’-- http://www.reologica.se - Rheology instrumentation --’

Hi,

Do you know how well it behaves with the rest of the sound system
(since I guess it won’t do the sfx or Ogg bgm :))?

Also I think it requires running as a deamon in background, doesn’t
it? That’s how I need to run it when I’m using Rosegarden.On Wed, Apr 29, 2009 at 01:29:24AM +0200, David Olofson wrote:

On Tuesday 28 April 2009, Sylvain Beucler wrote:
[…]

Writing a mixer from scratch means I’ll have to re-implement the
timidity support, which I’m not exactly interested in :wink:
Unless there’re other decent MIDI engines?

FluidSynth…?

http://fluidsynth.resonance.org/trac

Cross platform, LGPL, uses SoundFont 2, has built-in MIDI file
playback, built-in effects etc.


Sylvain

[…]

Writing a mixer from scratch means I’ll have to re-implement the
timidity support, which I’m not exactly interested in :wink:
Unless there’re other decent MIDI engines?

FluidSynth…?

http://fluidsynth.resonance.org/trac

Cross platform, LGPL, uses SoundFont 2, has built-in MIDI file
playback, built-in effects etc.

Hi,

Do you know how well it behaves with the rest of the sound system
(since I guess it won’t do the sfx or Ogg bgm :))?

IIRC, it was originally intended for use in games and the like, so I
would think you can run it “callback style” as well…

Also I think it requires running as a deamon in background, doesn’t
it? That’s how I need to run it when I’m using Rosegarden.

That’s most probably because there’s no synth plugin version of
FluidSynth, and/or Rosegarden doesn’t synth plugins. Although there
are a few synth plugin “standards”, the most common solution still
appears to be to run the synths stand-alone, controlling them via the
ALSA sequencer API.

From a theoretical POV, there shouldn’t be a need for running
FluidSynth as a stand-alone process, but without some sort of plugin
API, Rosegarden would have to “integrate” FluidSynth, explicitly
linking to it and using it as a normal library. The latter is
probably what you want to do in a multimedia sound engine anyway, so
the lack of plugin versions shouldn’t be an issue there.On Wednesday 29 April 2009, Sylvain Beucler wrote:
On Wed, Apr 29, 2009 at 01:29:24AM +0200, David Olofson wrote:

On Tuesday 28 April 2009, Sylvain Beucler wrote:


//David Olofson - Programmer, Composer, Open Source Advocate

.------- http://olofson.net - Games, SDL examples -------.
| http://zeespace.net - 2.5D rendering engine |
| http://audiality.org - Music/audio engine |
| http://eel.olofson.net - Real time scripting |
’-- http://www.reologica.se - Rheology instrumentation --’

SDL_sound reused the timidity code from SDL_mixer. I just tried the
sample bundled ‘playsound’ application, it works fine =)

The only cons is that it only looks at ./timidity.cfg (and not also
/etc/timidify.cfg like SDL_mixer), making me wonder where the heck I
miscompiled something :wink:

I’ll definitely gonna try this one further.
(I haven’t looked at memory usage yet though)On Wed, Apr 29, 2009 at 02:03:44AM +0200, David Olofson wrote:

On Wednesday 29 April 2009, David Olofson wrote:

On Tuesday 28 April 2009, Sylvain Beucler wrote:
[…]

Writing a mixer from scratch means I’ll have to re-implement the
timidity support, which I’m not exactly interested in :wink:
Unless there’re other decent MIDI engines?

FluidSynth…?

http://fluidsynth.resonance.org/trac

Cross platform, LGPL, uses SoundFont 2, has built-in MIDI file
playback, built-in effects etc.

Oh, and another option might be SDL_sound:

http://icculus.org/SDL_sound/

This may or may not be more appropriate than FluidSynth for
integrating into a mixer; I would THINK FluidSynth could
run “passively”, letting you manage the audio I/O as well, but I’m
not sure.

Either way, SDL_sound supports a bunch of other audio formats as well,
including loads of “module” formats through MikMod and ModPlug. I
don’t know how MIDI playback (as in, the actual synth) is
implemented, though; just looking at the feature list here…


Sylvain

Apparently ScummVM can use it, but I don’t really know when the engine
plays a midi and when it plays something else, no it’s not super-easy
to test.

Looking at the source code (scummvm-0.13.1/sound/softsynth/), it seems
there’s an internal midi parser (scummvm-0.13.1/sound/midiparser.h)
whose events are converted to fluidsynth function calls
(MidiDriver_FluidSynth::send).
Ugh, I don’t know the first thing about the MIDI format :slight_smile:

Btw, SDL_mixer can use FluidSynth (by removing */timidity.cfg, running
fluidsynth in background and using SDL_NATIVE_MUSIC_EXT=…), but last
time I tried, it was waiting for the MIDI to end before playing any
other sound. Naturally the game freezes all the time…

Btw, do you have some experience with sound fonts? The only free (as
in freedom) sound fonts I found are these:
http://packages.debian.org/search?keywords=fluid-soundfont
and they are huge: 150MB.On Wed, Apr 29, 2009 at 12:43:20PM +0200, David Olofson wrote:

On Wednesday 29 April 2009, Sylvain Beucler wrote:

On Wed, Apr 29, 2009 at 01:29:24AM +0200, David Olofson wrote:

On Tuesday 28 April 2009, Sylvain Beucler wrote:
[…]

Writing a mixer from scratch means I’ll have to re-implement the
timidity support, which I’m not exactly interested in :wink:
Unless there’re other decent MIDI engines?

FluidSynth…?

http://fluidsynth.resonance.org/trac

Cross platform, LGPL, uses SoundFont 2, has built-in MIDI file
playback, built-in effects etc.

Hi,

Do you know how well it behaves with the rest of the sound system
(since I guess it won’t do the sfx or Ogg bgm :))?

IIRC, it was originally intended for use in games and the like, so I
would think you can run it “callback style” as well…

Also I think it requires running as a deamon in background, doesn’t
it? That’s how I need to run it when I’m using Rosegarden.

That’s most probably because there’s no synth plugin version of
FluidSynth, and/or Rosegarden doesn’t synth plugins. Although there
are a few synth plugin “standards”, the most common solution still
appears to be to run the synths stand-alone, controlling them via the
ALSA sequencer API.

From a theoretical POV, there shouldn’t be a need for running
FluidSynth as a stand-alone process, but without some sort of plugin
API, Rosegarden would have to “integrate” FluidSynth, explicitly
linking to it and using it as a normal library. The latter is
probably what you want to do in a multimedia sound engine anyway, so
the lack of plugin versions shouldn’t be an issue there.


Sylvain

SDL_sound reused the timidity code from SDL_mixer. I just tried the
sample bundled ‘playsound’ application, it works fine =)

The only cons is that it only looks at ./timidity.cfg (and not also
/etc/timidify.cfg like SDL_mixer), making me wonder where the heck I
miscompiled something :wink:

I’ll definitely gonna try this one further.
(I haven’t looked at memory usage yet though)

Hmm, sample rate seems less advanced. The ‘playsound’ program either
didn’t make a change, or added metallic artifacts, plus looking at the
code it seems the conversion doesn’t always keep stereo channels
separate :confused:

On the other hand, the memory usage is minimal, since it reads the WAV
files progressively (one buffer at a time), and converts it to the
output format on the fly.–
Sylvain

What does “sample rate seems less advanced” mean?On Wed, Apr 29, 2009 at 4:57 PM, Sylvain Beucler wrote:

Hmm, sample rate seems less advanced.The ‘playsound’ program either
didn’t make a change, or added metallic artifacts, plus looking at the
code it seems the conversion doesn’t always keep stereo channels
separate :confused:


http://codebad.com/

Well, it means what I wrote just after :slight_smile:
i.e. that feature didn’t work for me.On Wed, Apr 29, 2009 at 05:51:32PM -0400, Donny Viszneki wrote:

On Wed, Apr 29, 2009 at 4:57 PM, Sylvain Beucler <@Sylvain_Beucler> wrote:

Hmm, sample rate seems less advanced.The ‘playsound’ program either
didn’t make a change, or added metallic artifacts, plus looking at the
code it seems the conversion doesn’t always keep stereo channels
separate :confused:

What does “sample rate seems less advanced” mean?


Sylvain