bluap

OK. I've installed the files you mention. I'm using a client freshly built form the latest CVS updates an the game data from the current release. Is this correct or should I be using the new (test) game data too? I'm using Linux (debian testing/unstable). Anyway, the update appears to have broken my sound. There are no sound related errors in the error_log or in the client text output. 1) I can toggle sound on/off and that might be working (need to have some weather!). However, I cannot toggle music on/off. This option is always off and will not change. If I modify my el.ini file to enable music, the option is still switched off in the GUI when I start the client. When the client exits, it also resets the music option to 0. 2) When I exit the client, it hangs for several seconds before closing. This has happened in the past when sound could not be shut down properly. Prior to the latest change, ttlanhil's changes to enable proper switching on/off of sound and music have worked fine. I'll be happy to be told I'm doing something wrong. I'm also happy to help debug the problem if I can.

I often start the client with sound disabled and want it enabled, and visa versa. What would be nice would be for the change to immediately take effect, without restarting the client. I've been hacking my copy of the client built from CVS and have this almost working. Would such a patch be accepted? Is someone in particular responsible for the sound code, sound.c mainly? I note there is a code freeze coming in a day or so. I am unlikely to be able to submit a patch before that unfortunately.

Did I really offer to do this patch myself Anyhow, I've nothing further to offer apart from my moral support. The changes appear to be working fine on Linux now. I certainly haven't seen problems switching on/off in any combination with the latest code. I'll keep watching the tread and help if I can...

I have a nice clean cvs build and it all looks great. Thank you again for working on this.

Great, that works really nicely thank you. I have noticed a couple of details that I didn't notice before. 1) If music is switched off when you start, you can switch it on and it works fine. However the on state is not saved in the config file. I think this is because there is a call to turn_music_off() in start_rendering() of main.c just before saving the configuration options. I moved the config save above the switch and the option is saved ok. 2) If you compile with -DNEW_WEATHER there is a compiler error in init_sound() of sound.c at the end when rain_sound is cleared. May be this should be #ifndef NEW_WEATHER protected? In my config window, the options look to be labelled correctly - both say enabled. Once again, thanks.

I had to make all the changes I mentioned (including the commenting out of lines 909 910 and 911 from sound.c as described). I've been using this version since and had no other problems. Thanks again for doing this change.

Any news on the status of this patch?

I've been experimenting with your latest version of the patch (as of 2006-05-12 23:12). I still have the lock up problems and second time I free the dev, the mutex assert crash. However if comment out lines 909 910 and 911 from sound.c (the calls to alcGetCurrentContext() alcGetContextsDevice() and alcMakeContextCurrent() in the destroy_sound() function) the patch works almost perfectly. Excessive on/off toggling works with no hangs or crashes. This tallies with my original patch - having to replace the high level alut functions with alc versions and reusing the original context made in the ini_sound() calls. I'm not sure if you need the alutExit() either, it does not appear to make a difference. Above I said "almost perfectly". This is because if I grab the device outside the client I have problems. The code correctly handles the case when the dev is not available - giving a warning. If I free the dev and try again, it grabs it and sounds and music appear to work as normal. If I then turn sound and music off, the client crashes in the call to alcDestroyContext() at line 912 in destroy_sound() with the same mutex asset problem. I have fixed this in my own way by modifying init_sound(). I moved the alcMakeContextCurrent() and SDL_CreateMutex() calls after the status check. If the status check failed, I set inited = 0 and return from the function - in addition to what you currently do. Its appears to work OK. So, I have a version of the client that works exactly as I wanted, I think we are nearly there....

Sorry for not replying to this earlier but I've been away from home for a few days without Internet access! Thanks again for continuing to work on this. I've removed all my code changes (and make defs) and updated against the latest CVS as of just now, then applied your patch (using "patch < sound_fix.patch" which I hope was correct). Here is what I have found. 1) Starting with both options disabled. My sound dev is free and all is well. 2) If I enable both, the sound dev is grabbed and the music starts. Great, though sometimes I have to change location before the music starts. 3) If however, I turn both options off again, the client hangs for a few seconds (up to about 20) before continuing as normal with the sound dev now free again. When messing with my changes I found this behaviour related to stopping the music thread. 4) Switching both options on again, we are back to state 2. 5) Going for broke, if I switch both options off again, I get the delay for a few seconds then the client crashes with the following debug output to my terminal: mutex 0x8fe08a0 busy el.x86.linux.bin: mutex/posixmutex.c:38: Posix_DestroyMutex: Assertion `0' failed. toggle_music(): turning sound ontoggle_music(): turning music ontoggle_music(): turning sound offtoggle_music(): turning music offtoggle_music(): turning sound ontoggle_music(): turning music ontoggle_music(): turning sound offtoggle_music(): turning music offAborted gdb revels: (gdb) where #0 0xb7a717c7 in raise () from /lib/tls/libc.so.6 #1 0xb7a7306b in abort () from /lib/tls/libc.so.6 #2 0xb7a6a735 in __assert_fail () from /lib/tls/libc.so.6 #3 0xb7d06795 in Posix_DestroyMutex () from /usr/lib/libopenal.so.0 #4 0xb7cef3a8 in _alDestroyMixer () from /usr/lib/libopenal.so.0 #5 0xb7cec808 in _alExit () from /usr/lib/libopenal.so.0 #6 0xb7d06afd in alcDestroyContext () from /usr/lib/libopenal.so.0 #7 0x080adeb5 in destroy_sound () at sound.c:910 #8 0x080ad7af in turn_music_off () at sound.c:745 #9 0x080ad770 in toggle_music (var=0x80d7ae4) at sound.c:734 #10 0x0807483c in onclick_label_handler (widget=0x0, mx=92, my=12, flags=67108864) at elconfig.c:1709 #11 0x080c1018 in widget_handle_click (widget=0xc49fd10, mx=92, my=12, flags=36865) at widgets.c:492 #12 0x08077a6e in click_in_window (win_id=11, x=140, y=557, flags=67108864) at elwindows.c:1270 #13 0x08075818 in click_in_windows (mx=140, my=557, flags=67108864) at elwindows.c:133 #14 0x0807a8c6 in HandleEvent (event=0xbf995864) at events.c:208 #15 0x0809349c in start_rendering () at main.c:98 #16 0x08093745 in main (argc=0, argv=0xbf995934) at main.c:227 In all cases, for consistency, I toggled the sound option before the music option. I also find that the client hands on exit if music or sound are enabled.

Version: latest build from CVS on Linux Thought I'd try to help with bug hunting so I linked against electric fence; a memory access checker for Linux. First issue is load_e3d_list() in init.c. It looks like the codes function is not needed but the function call is still made. It reads a length of memory to allocate from the first line in the file which is not/no longer there, luckily this leads to a zero length allocation and is harmless until someone tries to use the array. Second issue is with assign_cursor() in cursors.c. The loop at line 115 reads past the end of the cursors_mem array by 16 elements. Not sure what this might do but I guess needs checking by an expert. After that, I have currently hit a brick wall as electric fence exits with: ElectricFence Exiting: mprotect() failed: Cannot allocate memory I'm looking into this but was wondering what other checking tools others are using on the client. I was thinking about having a go with valgrind next...

One more issue I'm affraid If you start with music disabled, turning it on does not work. I think its because the music thread exits on startup as music is off and is never started again. I moved the music thread initialisation/closure into the init_sound() and destroy)sound() functions and that worked fine.

config has #no_music = 1 and #no_sound = 1 toggle_sounds() and toggle_music() are both called during initialisation to set there initial values of 1. The call to toggle_sounds() then calls init_sound() which grabs the audio device. I think you need to check if the result of the toggle will be to turn sound off, then don't call init_sound(). Could be very wrong though....

EL can have the device when I've finished with it and want game audio back. I'd love to know how to specify some other device, I've hunted high and low for such an option but can't find it. No sound is produced but it grabs the audio device, so I'm now worse off

Thanks for providing a patch so quickly. However, the patch I've been working on is a bit different. I want to use the audio device for other things once I've switched off game sound. Therefore, my patch frees the audio device when sound is turned off and attempts to grab it as before when turned on. Also, a side effect of your patch is that now, even if you start the client with sound turned off, it still grabs the audio device. I therefore have to start my other audio app before el and grab the device first. Previous to your or my patch, if I was already using the sound device when I started el and sound was enabled, I had all kinds of lag issues. My patch only grabs the sound device when sound is turned on. I'm not trying to compete here, just get the best solution to the issue as I saw it

Version 1.2.0p1 Beta and latest CVS 1.2.0.p6 Beta (Linux tested only) Here's how to reproduce the problem: Set Advanced video -> Perspective to 0.55 (or there abouts). Go to Portland storage and sit by the bookcase. Maximise the distance you can see using up arrow (or mouse), you'll be able to see the inside of other rooms on the map (another bug?). Look around using the rotate left/right. In one of the other rooms, there is a caldron with a fire underneath and stream coming from the top - the client freezes and has to be killed. I have prevented the problem by stopping fire particle effects: In the latest CVS version, particles.c, update_fire_sys() put a return statement at the top of the function (line 1051). Now fires have no particles but the client does not crash. I would love to be able to submit a patch to fix this but I do not know the client code well enough yet. Good luck with the bug hunting those who do...

Vegar was trying to reproduce this problem and could not. Therefore I added a bit more debug. The client does not lock up (although the screen does not update). It is stuck in the SDL event loop below, never reaching the done printf(). Could it be a machine speed related problem, there are more events than can be handled before more are generated? My machine is a 2.4GHz Pentium 4 with an Nvidia GeForce4 Ti 4200 graphics card. Code frgment from main.c start_rendering(): /* Loop until done. */ while( !done ) { SDL_Event event; printf("handle SDL events top\n"); // handle SDL events while( SDL_PollEvent( &event ) ) { done = HandleEvent(&event); } printf("handle SDL events done\n"); //advance the clock cur_time = SDL_GetTicks();