1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219 220 221 222 223 224 225 226 227 228 229 230 231 232 233 234 235 236 237 238 239 240 241 242 243 244 245 246 247 248 249 250 251 252 253 254 255 256 257 258 259 260 261 262 263 264 265 266 267 268 269 270 271 272 273 274 275 276 277 278 279 280 281 282 283 284 285 286
|
/* _______ ____ __ ___ ___
* \ _ \ \ / \ / \ \ / / ' ' '
* | | \ \ | | || | \/ | . .
* | | | | | | || ||\ /| |
* | | | | | | || || \/ | | ' ' '
* | | | | | | || || | | . .
* | |_/ / \ \__// || | |
* /_______/ynamic \____/niversal /__\ /____\usic /| . . ibliotheque
* / \
* / . \
* faq.txt - Frequently Asked Questions. / / \ \
* | < / \_
* This file covers some of the common problems | \/ /\ /
* and misconceptions people have with DUMB. If \_ / > /
* your problem is not covered here, please | \ / /
* contact me and I'll do my best to help. | ' /
* \__/
*/
*****************************************************************************
* I get a lot of strange warnings and errors when I compile my projects *
* with this release of DUMB. They work with older versions! What happened? *
*****************************************************************************
Some parts of DUMB's API have been deprecated. See docs/deprec.txt for
full details, including an explanation as to why your compiler warnings
and errors are so unfriendly, and information on how to fix each warning
or error.
*****************************************************************************
* When I try to compile DUMB with Allegro, it complains that it cannot find *
* 'internal/alconfig.h'! What's wrong? *
*****************************************************************************
In Allegro 4.0.1, and quite likely some other versions of Allegro, the
msvcmake batch file does not install Allegro properly. I believe this was
fixed in Allegro 4.0.2, but don't take my word for it. Some include files
are neglected, including alconfig.h. The fix is quite easy; you need to
copy all of Allegro's include files to your compiler's directory. The
following should do this for you (alter it accordingly depending on where
MSVC and Allegro are installed):
cd\progra~1\msvc\include
xcopy/s \allegro\include\*.*
You can safely tell it to overwrite all files.
*****************************************************************************
* When I build a project that uses DUMB, I get an error that it doesn't *
* find -laldmbd! What's wrong? *
*****************************************************************************
See the notes for DUMB v0.8 in release.txt; the existence of libaldmbd.a
in DUMB v0.7 was due to a mistake in the makefiles. It should be
libaldmd.a, in order to maintain DOS compatibility. All subsequent
releases get it right, but you will have to change your project files to
allow for the change. If this is someone else's project, please let them
know that it needs changing.
*****************************************************************************
* When I build a project that uses DUMB, I get some linker errors about *
* _free, _malloc, etc. already being defined in LIBC.lib! What's wrong? *
*****************************************************************************
MSVC offers three different implementations of the standard libraries.
When you link statically with a library, you have to use the same
implementation that the library uses. You need the multithreaded DLL
implementation, which you can select by passing /MD when you compile (not
when you link). See howto.txt for details.
*****************************************************************************
* I created an IT file with Impulse Tracker, but DUMB won't play it! Why? *
*****************************************************************************
You probably created some patterns but didn't give any information on the
order in which they should be played. Impulse Tracker will also fail to
play your music if you press F5. Press F11 and you will have an
opportunity to create an order list, required for playback.
*****************************************************************************
* I created an IT file with ModPlug Tracker and I have it fading out at the *
* end. Why won't it loop when I play it with DUMB? *
*****************************************************************************
It loops at zero volume. This is what Impulse Tracker itself does. Fix the
IT file by setting the global volume explicitly (Vxx in the effects
column), either at the start, or right at the end before looping. Also see
the next two questions.
*****************************************************************************
* My module plays too loud and distorts badly with DUMB! What can I do? *
*****************************************************************************
This problem is most often caused by ModPlug Tracker, which has a complete
lack of regard for the playback volume of the original tracker. See the
next question for DUMB's official position with regard to ModPlug Tracker.
If you wrote your module with ModPlug Tracker, please try loading it with
the original tracker and see if it distorts there too. If it does, reduce
the volume. If not, then it's a problem with DUMB; please let me know.
If for whatever reason you cannot modify the module file itself, you can
make it sound better by reducing the volume passed to al_start_duh(). Try
halving or quartering the value; search for a level at which the
distortion goes away.
*****************************************************************************
* I created a music module with ModPlug Tracker, and DUMB doesn't play it *
* right! *
*****************************************************************************
ModPlug Tracker differs from the original trackers in several ways, which
means modules written in one will not always play correctly or even load
in the other. DUMB's first loyalty is to the original trackers, which are
listed in readme.txt. This means it will have to differ from ModPlug
Tracker in several ways. For more information, please see
docs/modplug.txt.
If you find DUMB plays your module differently from the original tracker
for the format you are using, then please contact me.
*****************************************************************************
* My program crashes as soon as I try to load anything with DUMB! *
*****************************************************************************
Please take my advice and use the debugging build of DUMB, not the
optimised build. Then you'll probably find it aborts instead of crashing.
In this case you probably forgot to register a DUMBFILE system; this is
necessary for loading stand-alone files, though not for loading Allegro
datafiles with embedded music. Follow the instructions in docs/howto.txt
carefully and you shouldn't have this problem.
The system is designed this way to make sure you can exclude code you are
not using. If DUMB set you up for standard file access by default, then
the standard library code for accessing files would get pulled in even if
you never used it. This is especially important for dedicated systems that
have limited standard libraries.
If DUMB crashes with a specific music module, please let me know.
*****************************************************************************
* I want to use the stdio file access functions to load stand-alone music *
* files, but I also want to load datafiles containing music files. The docs *
* say I shouldn't call both dumb_register_stdfiles() and *
* dumb_register_packfiles(). What shall I do? *
*****************************************************************************
When you register a DUMBFILE system, it only applies to files opened with
dumbfile_open(), i.e. separate files. When a file is embedded in a
datafile, dumbfile_open_ex() is used to read it, enabling it to use
PACKFILEs regardless of which DUMBFILE system is registered. In short, you
do not need to call dumb_register_packfiles() in order to load datafiles
with embedded music. See the section on "Sequential File Input" in
docs/dumb.txt if you're interested in how all this works.
*****************************************************************************
* I want to read a specific object in a datafile using Allegro's *
* "demo.dat#MY_MUSIC" syntax. Why won't it work? *
*****************************************************************************
Did you call dumb_register_packfiles(), or did you call
dumb_register_stdfiles()? It will only work if you use the former.
*****************************************************************************
* My program runs, but no music plays! What am I doing wrong? *
*****************************************************************************
There are a number of possible causes for this. The most likely reason is
that you aren't calling al_poll_duh(); see docs/howto.txt for further
information.
Other possible causes are as follows:
- The speakers are turned down (duh);
- The volume of some system mixer is turned down;
- Another program is using the sound card (not a problem for most modern
systems);
- You didn't initialise Allegro's sound system; see install_sound() in
Allegro's docs;
- Allegro's drivers don't work on your system and chosen platform.
In order to narrow down the cause, consider the following:
- Do you get any other sound from your program?
- Do other Allegro+DUMB programs generate sound?
- Do other Allegro programs generate sound?
- Do other non-Allegro programs generate sound?
- Does your program fail only on a specific platform (e.g. DOS but not
Windows)?
This problem is highly system-specific; please try hard to solve it by
yourself before contacting me. However, if you think this problem could
affect other people, please let me know what the problem is and how you
fixed it, if you did. Be as specific as possible.
*****************************************************************************
* The music stutters! What can I do? *
*****************************************************************************
If you have an older computer, it may not be able to cope with the load.
Try reducing quality options; look up dumb_resampling_quality and
dumb_it_max_to_mix in docs/dumb.txt, and consider changing the frequency
you pass to al_start_duh().
Stuttering may not be caused by excessive load. To find out, try
increasing the buffer size passed to al_start_duh(). Beware of making it
too big though; older systems will freeze periodically if it's too big,
because they render larger chunks less frequently. The timing of callbacks
will also be less accurate, if you are using those.
If you're using the 'dumbplay' example, you can control these parameters
by editing dumb.ini.
*****************************************************************************
* Why does DUMB use so much processor time compared with other players? *
*****************************************************************************
It doesn't! It is now on a par with the ModPlug rendering engine (tested
using ModPlugXMMS with reverb, surround and other such effects disabled).
Previous releases were less than optimal, but DUMB's resampling algorithm
was - and still is - one of a kind. Take a look at the code. Come on, I
dare ya.
All that said, you can reduce the amount of processor time DUMB uses by
reducing the quality.
By default, DUMB uses the most expensive resampling quality option. I've
found on an AthlonXP 1800+ and on a Pentium 233 that it typically uses
about twice as much processor time as the least expensive option.
Try setting dumb_resampling_quality to DUMB_RQ_ALIASING or DUMB_RQ_LINEAR.
See dumb.txt for more information. If you're using the example programs,
you can control this variable by editing dumb.ini.
DUMB uses 32-bit ints for mixing. Some players use 16-bit ints, and are
therefore marginally faster (not much!) and lower quality. So you can't
expect DUMB to beat these players. Furthermore, DUMB is currently written
entirely in C. GCC does an impressive job on the C code, but that's not to
say some custom-written assembly language couldn't beat it ...
*****************************************************************************
* Why does DUMB generate so much background noise? *
*****************************************************************************
You're probably using the DOS build on a system with bad Sound Blaster
compatibility (most Windows XP systems fall in this category). This would
mean DUMB could only access an 8-bit driver. The Windows build will almost
certainly give better results. Your DOS binary will still give good
results on systems with better compatibility (like my Windows 98 system).
*****************************************************************************
* I e-mailed you and you replied with "RTFM"! What does that mean? *
*****************************************************************************
It means Read The Manual. I would only say this to someone who has clearly
not even tried reading the documentation. So if you are reading this FAQ
entry, you have too much time on your hands!
*****************************************************************************
* What happened to DUMB's IRC channel? *
*****************************************************************************
It has been discontinued. It wasn't used very much, and it only really
works if I'm there at the same time as someone wants to chat. For most
problems, e-mail is much more effective. However, if you would like to
chat about something, please do e-mail me and we'll arrange it.
Ben Davis
entheh@users.sf.net
|