Messages

What fix? I didn't do anything yet...

Oh, is that right?  Well, I'd reviewed the past ~3m of patches and I swore I saw you commit audio fixes (including a thread locking fix from monkey_05_06).  There were too many for me to review in detail, and I see now that his patch was a deadlock fix.  Apologies for my sloppy review and assumptions made.

Anyway, the fact that the problem has been perturbed out of existence certainly makes it feel like a threading race condition.  Probably it will come back.

But we too got a report about what seems to be memory corruption (possibly a deleted object accessed from other thread).
I am currently in a process of refactoring sound channels and sound clip objects in the engine code. After this is done, I will try to change the way threading works. I am afraid the way it was done originally made things more complicated.

I recommend to just disable threading in games where it causes problems, - for now. Should be:

Code: text

[sound]
threaded=0 // or remove the line completely

in acsetup.cfg.

For the projects I'm working with, we're already packaging a config file with the sound section empty, so the audio thread would not be run.

I think I will take a whack at this after I finish the build/packaging VM for Linux builds.  Maybe I'll have better luck than refactoring the audio API

One group I'm working with (which has, indeed, consumed nearly all of my time for engine fiddling) is going to need a Mac port pretty soon.  I'll be going with the Humble branch for their release, but it will be so good to have that stuff in the main branch someday.

Our other option is to have detailed build instructions for lots of different platforms, and WadjetEye can just provide the game data files. BYOE style.

Not for a commercial game - that would be fine for freeware. People already do that by buying the PC version and compiling the Linux runtime for their platform.

Janet, I'm working on a VM "appliance" that could be used to produce builds for the two architectures, with scripts to produce packaging (one "tar.gz" archive, one Mojosetup installer).  Some hand-massaging would be necessary of course as it would be producing generic builds, and Mojosetup installers need some customization (game name & file names, images, etc).  When it nears readiness, I'll share it with everyone.

I'm hoping that can ease the build and packaging woes somewhat!  I've several groups that are keenly interested in that.  Maybe I'll have better fortune at that than in working on the audio backend (as I'd intended before).

Incidentally CW, I think that your threading fix actually solved the audio corruption issue we were seeing on 32-bit Linux! I spent so many weeks debugging the Linux audio server (PulseAudio) and had no idea that multithreaded audio could be problematic for the ports. Unfortunately now, a tester has reported a different audio issue on 64-bit Linux, Fedora 20

Hopefully I made everything clear, in case you have any questions then I'll always be available for further testing. You can find the youtube video below.

https://www.youtube.com/watch?v=WMlQ1aNDun0

Yeah, that was super clear, and this is really great information, TFeldt!  Thanks for the video.  We've had other testers intermittently report input lag as well.

Looks like http://code.google.com/p/aseprite/issues/detail?id=283 to me, so maybe a known-issue with A4 at present (or at least with the way we're using it and polling inputs).

Those plugins are due to Janet's iOS build.  Recall that they used the snowrain plugin for Gemini Rue and moved that to a module.

I thought the ags_shell issue was dealt-with, though... we should simply not load it, and then URL's become not click-able.  I've been meaning to build a Linux version since it would be trivial to shell out to a browser ("sensible-browser", or "$BROWSER" or whatever), but it takes a back seat to the audio corruption bug.  (Yes, I'm still working on it, but haven't fixed it yet, so nothing to report.)

Once we get Gemini Rue solid for release (including audio and our ags-setup util) we can ask Janet to strip out those libraries from The Shivah, and take a look at wadjetutil, not sure what that is.  Until then, I can't imagine bothering her.

Ok, you've got native MIDI support on 14:0, so I don't think you need TiMidity (but that doesn't really matter too much).  Either way, it should be working.

Is it only 5 Days, or is it not working on other games as well?

BTW... please don't interpret my analysis & probing here as any kind of judgement against you.  This very well may be a bug!  I simply need to be certain, and as long as you're helping me, I prefer to gather as much information as I can.

Is your MIDI port also zero?  What's in your acsetup.cfg?

[aplaymidi -l]

How does the midi setup work in the linux version?
How do I tell AGS which alsa port to use? I run timidity which works fine in everything else but I can't seem to get any midi signals from AGS at all.

Yep;  what BigMC said.  Though, this is so poorly documented (between AGS & Allegro) that I'm glad you asked.  I'll go ahead and reply at length, so we may link to the post itself, in the future.

Calin, you need a couple of things.

First, you need to verify that you have MIDI supported (i.e., that either your sound driver supports MIDI directly, as most do, or through Timidity or similar).  Run aplaymidi -l (that's "l" for "list") to display ALSA ports which support MIDI.  The output might look like:

Code: text

  Port    Client name                      Port name
  14:0    Midi Through                     Midi Through Port-0

Note the port number (zero in this case).

Next, you need to verify that MIDI works at all (through a MIDI player unrelated to AGS, or similar).  At this point, you can be certain that you'll be able to play any AGS game with MIDI sound (modulo bugs of course).

To set up a specific game, first you'll need to put a patches.dat file in it's data directory (you can choose one from here).  I believe it must be named patches.dat for the Allegro library to find it.  I'm mostly using this one.

Lastly, you must set up the acsetup.cfg in the data directory, to properly index your MIDI port:

Code: INI

[sound]
digiid=1
midiid=0

You may not even have a "sound" section in the config file, but you'll need to add it. The parameter midiid is set to your port number from the aplaymidi listing.  For me, digiid needed to be set to 1, for MIDI port 0.  I'll go figure out why, and update this post with the reasoning.

I made few optimizations in "develop" branch, mostly simplifying new class hierarchies and inlining functions. They did not increase perfomance really much, but were enough to fix desynchronization between animation and sound/music during cutscenes in particular games. I think it would be possible to partially merge (or cherry-pick) that to master.
(merging whole develop branch right before the release would be risky, because it has significant change in internal data structures).

I agree with your merge strategy;  would that be something you'd like me to cherry-pick and test, or would you prefer to?

Keep in mind, these performance issues were not reported on the Windows version.  Improving performance over-all is, of course, fantastic, but this particular issue may very well be a Linux thing (or an Allegro on Linux thing, or a "way the Linux AGS port uses Allegro" thing).  Or it may simply not exist;  I haven't attempted to verify those reports yet.

We want to keep everything that he (Edward) does open source so that everyone can benefit (including us!) I want to make sure what we do is compatible with the community's plans for AGS.

Awesome, I thought so.  You folks are the best 

Wadjet Eye has now got a programmer (not me) working on porting the Mac and Linux AGS engine so that we can commercially release Gemini Rue on those platforms. I know that the Linux build is in pretty good shape, but what needs doing at the moment apart from the crackly audio issues?

Congratulations on the great new addition to your team!!  The programmer, of course 

Ah.  Sorry I've been unable to resolve these issues quickly enough for you.

There, is, as mentioned the audio corruption issue.  It has only been reported on systems with the PulseAudio audio server (present on most installs);  however, those not using it do need to have audio settings configured properly in the config file ("acsetup.cfg").  If these settings are not present (DIGIMID index), then beyond sound not working, we also have seen instances of the engine crashing to the command line.  Solving it directly is, of course, desirable, but having functional audio is a very nice workaround, in that the user has audio and no crashing.  The previous closed AGS version, 2.72, had quite a nice GUI setup utility written by Tom Vandepoele (Electroshokker) which did do this, as well as other config settings, such as full-screen or windowed mode.  I've asked for, and received, permission from he and CJ to have access to, port, and publish, those sources with the current AGS sources, and under the same license.  It would permit a user to properly configure DIGIMID in the config file!  I'm waiting on he (or CJ) to provide these sources.

So, long story short, if audio is not properly initialized, there can be crashes (bug).  It can be bewildering for new users to adjust the (partially undocumented) config files by hand.  The setup GUI works-around the first and solves the second.

Next, some testers have reported performance issues.  I've not spent any time profiling, as I considered the audio corruption a higher priority.

Lastly, I began work on an installer (using Mojosetup) and got it sort of working for 64-bit Linux, but not for 32-bit.  I also dropped installer work for the same reason.

I'm curious;  how will you have your programmer work on the engine, in terms of availability of sources?  Will fixes and improvements be worked on in the open (for example, in coordination with CW and JJS using the public Github), or retained internally to Wadjet Eye?  I'm working with other teams to do this same work (on a volunteer basis), and it would be ludicrous to run separate parallel development, though I fully understand the commercial need to not wait on volunteers

Galaxy Note is an Android phone/tablet... maybe they need the Android porting thread instead?

Cheeseness;  thank you for the valuable input!  I'm working on all of this, and will report back when I have more information.

For what it's worth I run AGS on Fedora 17 and Fedora 18 both 64 bit, three different machines, and haven't had any audio crackling. Some users HAVE reported it though, I suspect a driver issue incompatibility with AGS/Allegro

Great!  Thanks for testing it.  I really want a good level of confidence in that new build I posted.

Since it's so intermittent, and Cheese has stated that he observes it in F17, and you do not, I'm thinking that it's a race-condition of some sort, perturbed by the usual suspects (CPU speed & other concurrent userspace activity).  That would be consistent with our other test reports (who either experience it, or never do, on Ubuntu 12.04LTS as well).

The issue I've been encountering can best be described as crackly audio (I'll see if I can get a recording of an example during the week).

I got around to uploading to YouTube my instances of it:

http://youtu.be/NrdhuNOOuO8
http://youtu.be/9Y7r5Xxh0X8

I had previously encountered sped up audio, but I haven't seen that for a while (and can't recall what I did to trigger it). I've had similar crackly audio issues with a number of titles in Wine which normally go away with a pulseaudio -k, and of course in the Gemini Rue beta.

Am I to understand, then, that restarting Pulse no longer eliminates the current incarnation of your audio corruption?

Runs nicely on my F17 install. 0.5 sec worth of crackly sound when starting the title I'm packaging, but it comes right every time. It also seems to recover happily from switching focus after a second or so of crackly audio.

On my Wheezy VM, I get crackly audio no matter what I try (the same issues I'd been experiencing with my own build). I don't have a proper install to test on at the moment though.

This is good info, thanks.  It's probably fairly instructive that the glitch traverses distros, but follows Pulseaudio.  I can reproduce this at will on my test setup.  All that's left is the hard part (figuring out how to properly debug the problem).

Hey, Cheese, what's up? 

I'm packaging an AGS title for Linux for a friend of mine (who'd prefer that the title wasn't publicly announced for Linux prematurely), and I've been encountering audio issues with Pulse (which I've seen mention of in this thread) with my builds. I'd like to resolve these before we start broader testing and would consider an interim workaround if anybody's got any ideas (using padsp to force alsa doesn't help, and I haven't had much luck with any cfg settings either).

It sounds like the resolution for this that's currently being pursued is the Allegro5 port which Crimson Wizard and s_d (?) have been talking about. I have a tiny bit of allegro experience, but I don't feel like I have enough familiarity with how AGS' innards work to try tracking this down, and I don't have enough availability to sink my teeth into the Allegro5 porting effort. I can certainly offer encouragement though

So far I've been using Allegro4.4. I've noticed that some are talking about 4.2 - are there any know issues with 4.4 and AGS that I might have missed?

Ooh, exciting!  Another title!

Regarding the Pulseaudio corruption issue, yes, it is (sort of) known.

What are you running?  What is the nature of your Pulse glitches? The reports are of simultaneously distorted audio and playback speed.  Does that sound familiar?  I have a couple of video clips from GR and The Shivah demo I've been meaning to put up on YouTube for reference.  Everyone who has encountered the corruption bug (who I've been able to get to try it) has successfully reset their audio by restarting Pulse ("pulseaudio -k").  It has been reported that the problem is exacerbated in "windowed" mode by switching window focus out of the game (during gameplay), especially into another program using Pulse (for me, switching to a browser running flash does it almost every time... a fact that I can use to reproduce the problem for debugging/fixing purposes).

We have no reason to think that A5 will do anything to help this whatsoever, as it doesn't seem like an A4/Pulseaudio problem specifically (nobody is reporting this issue on other A4 Linux games).  Personally, I think it is 80% something we're doing, and 20% a Pulseaudio corner-case (which has, by the way, been reported to no longer occur on Ubuntu 12.10, which would be good to verify). A5 is mostly for the Mac port (and a little future-proofing in general).  Ideally, CW & I (and anyone else willing, who can do) would abstract the graphics, audio, and control API's enough to even make Allegro replaceable. Recently, I've had some personal challenges, and frustratingly, my work there has not progressed as I've wanted.  I am committed to working on it, though.

I also read a few pages back that people had been working on config generation scripts (and trying to get ahold of source for a UI?). I had planned to make something quick and dirty using Zenity, but if there's other stuff in the works, I might be able to throw a little time at helping things move forward.

Well, Electroshokker built this:  http://www.adventuregamestudio.co.uk/forums/index.php?topic=37968.msg501047#msg501047

...which apparently worked really well, and properly configured DIGIMID for ALSA (one bug report came from a Slackware user who was Pulse-free... setting up the proper DIGIMID index in the acsetup.cfg fixed his wagon).  I'm fairly content to continue porting forward the util, once code appears.

scottchiefbaker has a simple generator script in-place for the Gemini Rue beta which may be sufficient until we have a GUI.  Perhaps he'll share it with you?

Sorry to go off the ranch for so long, people.  It was because of Stuff & Things.   

No code from Electroshokker yet, but I don't want to push him very hard (he may have Stuff & Things as well).  I'll send another gentle nudge and hope he doesn't become upset.

Second, I've built a new distributable ags+libraries

Great! Was the process documented well enough? Did you make sure to build the 32 bit executable with rpath "lib32"? If you use the debian stuff to build in a chroot, that works by setting the  environment variable DEB_BUILD_OPTIONS=rpath=lib32

Man, BigMC... I totally messed up the RPATH setting!!  Many apologies.  Discovering what I did wrong there led me down a rathole to discover that I'd had some linking funny business all along... namely, I was linking to both A4.2 and A4.4 at the same time (?!).  At any rate I massaged both of my build roots (32 & 64) and believe that all is correct now, according to 1) ldd, 2) objdump, 3) testing.

URL: https://docs.google.com/file/d/0B6N-Dop3H_3IaG0tWF9vM2JtalU/edit

Thusly, I would be ever so grateful if you would give these a test-drive on Wheezy for me (we don't support Squeeze, right?).  I'm running Gentoo (by choice) & Ubuntu (for game dev) and currently have no Debian boxen set up for testing (nor Fedora, but I'm pretty comfortable with scottchiefbaker testing the RH-flavoured distros).

A couple of updates;  first, CJ himself has replied to me, and CC'd Electroshokker (who generously offered to spend some time to dig up his copy of the sources).  So, after he provides those, I'll get it building (for libraries circa glibc version 2.13), and then bring it into a Github pull request, with some instructions, etc.  So, that was really good news 

Second, I've built a new distributable ags+libraries (hopefully for another round of beta in the various communities running these).  Primarily, this contains the Allegro driver change and CW's new version numbering changes (SHA 3175c1a511da7f5cfb0f428d7308e6e933cb1486).  The best place I have to host it freely is on Google Drive.

EDIT:  Link removed.

No, I mean making a new branch in the central repository, like "develop_allegro5" or "feature_allegro5".
...
Also, I learnt one may add contributors to personal repository. We may use that too.

Perfect, sounds great to me.

Thanks, AGA!  I've replied to Electroshokker via PM, and CC'ed you and CJ, as well.  Hopefully we can get me going with this code without bothering anyone else 

I used to see lots of AGS games distribute several data files in addition to (or mostly in exclusion of) the EXE.  So that functionality is (or at least was?) present at one time.  That's not including the vox files (for example), but actual, numerically indexed data files.  I think the code to handle that is still there, in the engine/interpreter code, as well (last I looked).

Perhaps that could be a way to "naturally" split the game assets.  Another contributor, rofl0r, has some nifty tools up on github for slicing and dicing the AGS data files.  They are bugged in a number of ways, but I found the sources kind of helpful in understanding the storage format of the game data files.