Basing on player example, i managed to write a program using this
library that works(using SDL, like in example).

What I want to achieve is playing one music at the time, but sometimes
in NES format and sometimes in GameBoy format. I have done it this
way:

(code starts here)

Music_Emu* emulator;
/* some SDL Audio stuff here */
gme_open_file("1.nsf",&emulator,sample_rate);
emulator->start_track(0);
SDL_PauseAudio( false );

/* NES music playing now, a main loop etc */

/* now i want to change music to Gameboy music*/
SDL_PauseAudio( true );
SDL_LockAudio();
SDL_UnlockAudio();

gme_delete(emulator); // delete NES Emulator
gme_open_file("2.gbs",&emulator,sample_rate); // create GB emulator
emulator->start_track(0);

SDL_PauseAudio( false );
/* now GB music is playing, hurray */
(code ends here)

It works, but is this a good way to do it? I mean, i know it works,
but it seems just bad to me. Deleting the whole emulator just to
change the song isn't very elegant.
So is there any other way to achieve this? Or do you think that this
method is just fine?

This is fine; playing a GBS requires a different emulator, so there's
no other way than deleting. It's not like this is an expensive
operation. It just involves some memory deallocation (and reallocation
when creating the new emulator). That's a fast operation.

I'm wondering though whether the audio locking is done at the right
place. Wouldn't you lock audio for the duration of the delete-open-
start-track operation, and unlock only once everything is ready to
continue playing? Otherwise it might run in the middle when things are
inconsistent. I see the pause, but I'm not familiar enough with SDL to
know whether that is enough.

Basically, the questions to ask about any issue like this: first, does
it do the right thing? Then, is it fast enough? Does it require an
unreasonable amount of memory? Is it easy to integrate into the
program? If all of these are met, worrying about micro efficiency or
whatever is a distraction.

On Dec 28, 3:58 pm, Winhelp <winh...@tlen.pl> wrote:

Thank you for reply.

Well, i'm not familiar with SDL Audio at all, this part was taken
straight from the example player.
It's sound_stop() function from Music_Player.cpp.

static void sound_stop()
{
        SDL_PauseAudio( true );

        // be sure audio thread is not active
        SDL_LockAudio();
        SDL_UnlockAudio();

And start_track() looks like this:

blargg_err_t Music_Player::start_track( int track )
{
        if ( emu_ )
        {
                // Sound must not be running when operating on emulator
                sound_stop();
                RETURN_ERR( emu_->start_track( track ) );

                /* calculating track length part */

                paused = false;
                sound_start();
        }
        return 0;

sound_start() is just SDL_PauseAudio( false ).

I'm not sure that in my case i should do the same, but i dont
understand yet how does it work, i just modified the example.

I tried unlocking audio just before SDL_PauseAudio(false) and there is
no sound at all.

Now it works - it looks like bad things happen when you try to lock
already locked audio - and i did something like that.
Something like this works:

void sound_stop()
{
 SDL_PauseAudio( true );
 SDL_LockAudio();

void sound_start()
{
 SDL_UnlockAudio();
 SDL_PauseAudio(false);

So is this thing from example an error? I agree that this looks more
logical than locking audio just to unlock it in next line.

On 1/3/12, Winhelp <winh...@tlen.pl> wrote:

I'm thinking I went the simpler route in the example because the above
seems to require special treatment of the first time you start sound,
and the last time you end. When first starting, presumably the audio
isn't locked, so the unlock call seems in error (though SDL probably
ignores that). And when last using audio and you've stopped it and
then locked it, it seems plausible that this might prevent closing of
audio, since there's still a lock being held. So for the example I
must have figured out that just locking and then unlocking is enough
to ensure that the callback doesn't fire anymore after pausing (that
is, the only way it could be still running is if you happened to pause
when the callback was active in another thread on a
multiprocessor/core machine).

If we really wanted to do things the most correct way, we might write a wrapper:

bool sound_started;

void sound_init()
{
    SDL_OpenAudio( ... );
    sound_started = false;

void sound_start()
{
    if ( !sound_started )
    {
        SDL_UnlockAudio();
        SDL_PauseAudio( false );
        sound_started = true;
    }

void sound_stop()
{
    if ( sound_started )
    {
        SDL_PauseAudio( true );
        SDL_LockAudio();
        sound_started = false;
    }

void sound_close()
{
    sound_stop();
    SDL_UnlockAudio();
    SDL_CloseAudio();

This simpler wrapper ensures that all the right calls occur without
burdening user code with the details; it can call start/stop multiple
times in a row without deadlock etc. Whether it's necessary depends on
SDL's implementation; their documentation is unfortunately vague about
semantics. I'm a big fan of small wrappers like this to separate the
API details and simplify what I have to think about in the main code.