NEW_SOUND

[bluap]

ok I compiled the client. And the music/sound works again now! Yay!

 

Except with regards to the "turn the music on/off on the fly patch", we're back to this bug: http://www.eternal-lands.com/forum/index.p...ic=24913&st=40#

 

But that bug is better than the no music at all bug so...

Thanks folks, the latest CVS version now works fine for me when compiled without the NEW_SOUND option. I hope that is the same experience as Roja noted. I have not yet retried with NEW_SOUND enabled. (My Internet connection was down all day yesterday along with my TV due to a severed cable). I'll have a go tonight.

[d000hg]

So are we happy that the non-NEW_SOUND build is completely fine, including the surning-sound-and-music-on-and-off changes?

[0ctane]

Thanks folks, the latest CVS version now works fine for me when compiled without the NEW_SOUND option. I hope that is the same experience as Roja noted. I have not yet retried with NEW_SOUND enabled.

Without using NEW_SOUND, the OS X client builds fine. I too have not yet tried with NEW_SOUND.

 

When are we going to have a code freeze before the update? IMHO only bugs should be addressed at this point rather than adding new features.

[d000hg]

Thanks folks, the latest CVS version now works fine for me when compiled without the NEW_SOUND option. I hope that is the same experience as Roja noted. I have not yet retried with NEW_SOUND enabled.

Without using NEW_SOUND, the OS X client builds fine. I too have not yet tried with NEW_SOUND.

 

When are we going to have a code freeze before the update? IMHO only bugs should be addressed at this point rather than adding new features.

That's why the define NEW_SOUND is there! Maintaining the patch for sound changes while everyone kept changing stuff was a pain so it seemed sensible to get it checked in in a 'safe' state.

[bluap]

So are we happy that the non-NEW_SOUND build is completely fine, including the surning-sound-and-music-on-and-off changes?

If built from CVS then yes, for me, the non-NEW_SOUND build is completely fine.

 

I tried patching in your changes posted above with a non-NEW_SOUND build. These also work OK but I get a complete hang on exit. This may be a mutex problem, I have not investiagted it yet. However, I could not apply the patch automatically having already updated to a newer version from CVS so I may have messed up somewhere (I've checked several times though).

 

I still have many problems when built with NEW_SOUND, even with your changes posted above. The sound effects work most of the time but I get quite a bit of lag and have had a complete hang. Most significantly, I cannot get any music to play at all.

 

If you want my opinion, leave sound in CVS unchanged until the update has been done. Just my humble opinion though.

[d000hg]

I tried patching in your changes posted above with a non-NEW_SOUND build. These also work OK but I get a complete hang on exit. This may be a mutex problem, I have not investiagted it yet. However, I could not apply the patch automatically having already updated to a newer version from CVS so I may have messed up somewhere (I've checked several times though).

Um, I think that patch has been applied and checked in, unless I misunderstood Torg? Trying to re-apply it, well I don't know what might happen!

I still have many problems when built with NEW_SOUND, even with your changes posted above. The sound effects work most of the time but I get quite a bit of lag and have had a complete hang. Most significantly, I cannot get any music to play at all.

Thanks for testing. What is your OS please? When did it hang - randomly or when doing something in particular? And does the music on/off check-box function but with no music, or can you simply not turn it on at all?

[Torg]

Um, I think that patch has been applied and checked in, unless I misunderstood Torg? Trying to re-apply it, well I don't know what might happen!

No, that patch was not committed. I made a patch mostly from Bluap's comments as your patch with all the Mutex stuff caused me way too much grief to worry about (I don't have time to play right now).

 

Please let me know of any problems with the client when built without the NEW_SOUND define so that I can fix them before the release.

 

Feel free to test with NEW_SOUND and let d000hq know of bugs so he can fix them, but I won't submit any changes to that code until after the release.

[bluap]

Thanks for testing. What is your OS please? When did it hang - randomly or when doing something in particular? And does the music on/off check-box function but with no music, or can you simply not turn it on at all?

GNU/Linux Debian testing/unstable. libopenal-dev & libopenal0 version 0.2004090900-1.

 

Yes, the CVS version now includes the changes I suggested. This does allow you to toggle the music option on/off. For the non-NEW_SOUND build this works fine, just like before your NEW_SOUND commit.

 

When I applied your additional changes the non-NEW_SOUND build works up until you exit when it hangs. For the NEW_SOUND build, the sound effects work and you can toggle the music option, but no music ever plays. I am not sure what I was going when this build hung sorry. I'll try to collect more information when I have time.

 

 

Please let me know of any problems with the client when built without the NEW_SOUND define so that I can fix them before the release.

The CVS version is looking good, for me at least, without the NEW_SOUND define. My only concern is that the original commit of d000hg's NEW_SOUND changes disabled the LOCK_SOUND_LIST() and UNLOCK_SOUND_LIST() macros in sound.c. This does not appear to be a problem but I can't help wondering why it was disabled and if they should not be restored. May be the original author might be able to help... I'll do some testing with them enabled anyway.

Edited June 29, 2006 by bluap

[d000hg]

I no longer know what the differnce are between my changes and Torg's fix, but I'll get that version and look again!

I don't reemmber commenting out the mutex macros but may well have decided that they weren't required and then forgotten - there's certainly no reason not to re-enable them.

 

You say you're testing on an UNSTABLE version of Linux?

[bluap]

You say you're testing on an UNSTABLE version of Linux?

Debian operate several repositories for packages, stable/testing/unstable/experimental. Testing/unstable is just a bit more cutting edge than stable. Debian is very conservative with new versions of packages, testing/unstable is actually very stable and more like you'd get with any latest version of a particular distro like the latest release of Ubuntu. My system is not unstable by nature or by the versions of packages I'm using.

[m_bee]

True, in fact, 0.2004090900-1 is maybe too "stable" and quite old. Anyway, I doubt is has anything to do with the problem.

 

The elc makefile is not prepared to deal with the new releases of openal, due to the fact that it splitted in openal itself + freealut, and -lalut is needed to be added to linker option in the makefile for it to be able to compile fine. Anyway, there are quite a few 2005... releases and that one that you use is very outdated. I dont know how debian is right now in this regard, since I left debian some time ago in favour of gentoo.

 

To talk about unstable debian is, anyway, like to talk about a slow athlon cpu... It does not exist in a strict manner, even if the distro is labeled that way

[bluap]

True, in fact, 0.2004090900-1 is maybe too "stable" and quite old. Anyway, I doubt is has anything to do with the problem.

I've just checked and that version is the stable Debian version (as from the sound of it you know, stable/testing/unstable can be mixed due to the excellent dependency/package management of Debian). It includes the alut headers and Makefile.linux does not link against alut so I guess its all included in the openal library I'm using. The testing package version for openal is 1:0.0.8-1 so I don't easily have a choice of a 2005 version. But anyway, like you said, I doubt this is the problem.

[m_bee]

Yes, that is what I thought. Anyway, in that regard, the 2005xxx versions would be the same. They also include the alut stuff into the same openal package. It is from numbered versions (first release was 0.0.8 for gentoo, dunno for other distros) when it splitted into openal + freealut. And that, as I say, only creates more trouble, though an very easy to solve one...

 

But, as we both agree, I doubt that is the issue. Other than that linking issue, I did not have any problem in the past with any version of openal. For the rest, the unstable branch of debian should not be a problem, since the client compiled fine and worked fine until that patch was included, did not it? So, the issue is openal, and the patch code.