For those that may or may not know, APEG has been my little side-project-baby-thing for quite a while. When I last worked on it several moths ago, the code was in shambles. The audio playback was using my proprietary mixer streams since I was having problems using Allegro's audio streams skipping horrendously, I couldn't get the video and audio to sync up no matter what I did, I was experimenting with the new functionality's API, and by the time I set it down, I had the audio code completely disabled.

Much has happened since then, including a complete reinstall of Gentoo Linux. However, I decided yesterday to take a peak at the code and see if I could think of anything. Here's an update of what I've done in the past 12 hours.

• Reenabled the audio

• Fixed the audio streams (NOTE: you must be very fast with the stream buffer after get_audio_stream_buffer, especially under Unix/Linux)

• Got the video and audio sync'd up beautifully

• Implemented audio playback for both the blocking and non-blocking player functions

• Fixed various bugs relating to auidio/video playback

</li>
Not bad for a day's work, IMO.

APEG's audio capabilities include:

• Able to play layer 1, 2, and 3 MPEG-1 streams, with or without video

• 3DNow! and MMX support (run-time detection for both, and MMX can also be forced on at compile time if you so wish)

• 1:1, 2:1, and 4:1 downsampled playback

• Downchanneled playback

</li>
In essence, you could use just this instead of AllegroMP3, although APEG doesn't load MP3s into SAMPLE structs, or provide non-polled streaming (which really shouldn't be provided anyway, IMO). It does, however, support mp1 and mp2 files in addition to mp3s.

However, all is not currently sunny-happy-bright in the kingdom of APEG. There are a few glaring problems, one of which I have never run into before (and I know wasn't there when I last tried it before restarting work). For some reason, when exiting, pthreads will trigger a SIGABRT signal. I have no idea why or exactly where since there's no useable backtrace, even in debug mode. I have a feeling it's somewhat related to all the SIG32 signals I now get in gdb since I reinstalled Gentoo. Other problems are.. 1:1 playback is currently b0rked. I haven't had the opportunity to look into why yet, though 2:1 and 4;1 playback is fine. It's not quite multi-stream safe, yet (opening more than one audio stream will b0rk the program). The audio API isn't completely finished. And I haven't fully cleaned out the code from when it used to be a standalone, mpg123 lib example player.

But other than that, yeah. It's progressing much faster than I anticipated. Once I get the above issues worked out, expect to see a beta release.

Sweet KC... keep up the work on APEG

Small appendature to the above: The 3DNow-enhanced 1:1 decoder is currently b0rked. The normal 1:1 decoder is fine. Unfortunately this means I'll have to dable in the asm to fix (or at least find the cause).. which isn't necesarrilly impossible.. I had to make a small adjustment to the MMX asm. Just don't hold your breath.

Wow! Great work - thanks a lot.

Do you have a download link or a link to the project page?

The only page I have for it is at http://kcat.strangesoft.net/. Not much to look at, and the version there is an older version.

if you need testers, let me know.
i have a fairly robust system to test it with, including creating multi instances of it and playing them all back similtaneously.

Ok, hopefully this will work elsewhere. The only issues there currently are are finalizing the new API parts and the dumb Abort message I get in Linux. Here's a pre-release of APEG 0.9, for your testing pleasure.

http://kcat.strangesoft.net/apeg-src.tar.gz ~4.2MB with a test stream
or:
http://kcat.strangesoft.net/apeg-nostream-src.tar.gz ~82KB without a test stream (obviously useful only if you already have mpeg-1 videos)

The docs haven't really been updated since the last version. Just extract, run fix, then make (append DEBUGMODE=1 to make for a debug build). That'll build the lib and two example players.

What I would like you to be on the lookout for, other than the usual, is skipping, eratic pauses, etc.

using mingw g++ (GCC) 3.2 (mingw special 20020817-1)
winXP, AMD2500+

D:\tmp\APEG_V~1>fix mingw
Configuration script to setup the proper makefile for DJGPP or MinGW.

Configuring for MinGW...
Done! Type 'make' to start compiling.

D:\tmp\APEG_V~1>set DEBUGMODE=1

D:\tmp\APEG_V~1>make
gcc -DDEBUGMODE -MMD -W -Wall -Iinclude -g3 -o obj/mingw/display.o -c src/displa
y.c
In file included from src/display.c:19:
include/mpeg1dec.h:196: parse error before "byte"
include/mpeg1dec.h:196: warning: no semicolon at end of struct or union
include/mpeg1dec.h:196: warning: no semicolon at end of struct or union
include/mpeg1dec.h:203: parse error before '*' token
include/mpeg1dec.h:203: warning: type defaults to `int' in declaration of `pcm_s
ample'
include/mpeg1dec.h:203: warning: data definition has no type or storage class
include/mpeg1dec.h:208: parse error before '}' token
include/mpeg1dec.h:208: warning: type defaults to `int' in declaration of `audio
'
include/mpeg1dec.h:208: warning: data definition has no type or storage class
include/mpeg1dec.h:209: parse error before '}' token
include/mpeg1dec.h:209: warning: type defaults to `int' in declaration of `APEG_
LAYER'
include/mpeg1dec.h:209: warning: data definition has no type or storage class
src/display.c: In function `apeg_initialize_display':
src/display.c:77: `layer' undeclared (first use in this function)

Hmm.. I thought Windows compilers predefined byte. Oh well, here's a fixed file (put it in apeg's include dir, overwriting the old file).

D:\Documents and Settings\Steve Terry\Desktop\apeg\apeg>gcc -v
Reading specs from D:/Dev-cpp/mingw32/bin/../lib/gcc-lib/mingw32/3.2/specs
Configured with: ../gcc/configure --with-gcc --with-gnu-ld --with-gnu-as --host=
mingw32 --target=mingw32 --prefix=/mingw --enable-threads --disable-nls --enable
-languages=f77,c++,objc,ada --disable-win32-registry --disable-shared
Thread model: win32
gcc version 3.2 (mingw special 20020817-1)

[snip]
gcc -DDEBUGMODE -MMD -W -Wall -Iinclude -g3 -o obj/mingw/vbrhead.o -c src/audio/
vbrhead.c
gcc -o obj/mingw/dct36_3dnow.o -c src/audio/dct36_3dnow.s
src/audio/dct36_3dnow.s: Assembler messages:
src/audio/dct36_3dnow.s:30: Warning: .type pseudo-op used outside of .def/.endef
ignored.
src/audio/dct36_3dnow.s:30: Warning: rest of line ignored; first ignored charact
er is `d'
gcc -o obj/mingw/dct64_3dnow.o -c src/audio/dct64_3dnow.s
src/audio/dct64_3dnow.s: Assembler messages:
src/audio/dct64_3dnow.s:13: Warning: .type pseudo-op used outside of .def/.endef
ignored.
src/audio/dct64_3dnow.s:13: Warning: rest of line ignored; first ignored charact
er is `d'
gcc -o obj/mingw/dct64_MMX.o -c src/audio/dct64_MMX.s
gcc -o obj/mingw/dct64_i486-a.o -c src/audio/dct64_i486-a.s
src/audio/dct64_i486-a.s: Assembler messages:
src/audio/dct64_i486-a.s:8: Warning: .type pseudo-op used outside of .def/.endef
ignored.
src/audio/dct64_i486-a.s:8: Warning: rest of line ignored; first ignored charact
er is `d'
gcc -o obj/mingw/decode_3dnow.o -c src/audio/decode_3dnow.s
src/audio/decode_3dnow.s: Assembler messages:
src/audio/decode_3dnow.s:30: Error: unknown pseudo-op: `.local'
src/audio/decode_3dnow.s:31: Warning: rest of line ignored; first ignored charac
ter is `,'
src/audio/decode_3dnow.s:34: Warning: .type pseudo-op used outside of .def/.ende
f ignored.
src/audio/decode_3dnow.s:34: Warning: rest of line ignored; first ignored charac
ter is `b'
src/audio/decode_3dnow.s:35: Warning: .size pseudo-op used outside of .def/.ende
f ignored.
src/audio/decode_3dnow.s:35: Warning: rest of line ignored; first ignored charac
ter is `b'
src/audio/decode_3dnow.s:40: Warning: .type pseudo-op used outside of .def/.ende
f ignored.
src/audio/decode_3dnow.s:40: Warning: rest of line ignored; first ignored charac
ter is `s'
make: *** [obj/mingw/decode_3dnow.o] Error 1

Alright. Hopefully I got the problems sorted out. At least I got one report of a successful windows build. The archives were updated:

http://kcat.strangesoft.net/apeg-src.tar.gz
or:
http://kcat.strangesoft.net/apeg-nostream-src.tar.gz

Just to reiterate.. it is not complete. Some functionality is not complete, and it is not recommended you use this in your programs (though I won't stop you if you really want to). If this works, it shouldn't be too long before a real release.

Oh yes.. this should work under OSX again too, hopefully.

excellent work, it compiles on winXP now, with mingw 3.2

next problem...

D:\tmp\APEG_V~2\examples>exsimple.exe "Digital Skateboarding - #10 Everyday Skate Videos.mpg"

D:\tmp\APEG_V~2\examples>ren "Digital Skateboarding - #10 Everyday Skate Videos.mpg" d.mpg

D:\tmp\APEG_V~2\examples>exsimple.exe d.mpg

it failed to load my skate mpg, so i renamed it to d.mpg and it worked.
so there is something wrong with using spaces or long filenames.

I think it has to do with the # in the filename. Allegro's packfile routines expect everything before it to be a datafile, and everything after to be a datafile object. I'll try to remember to bring this issue up on AD.

I get an average of 50% frames skipped on windowed and fullscreen playback and the sound is a bit staticy but it's looking good though.

AMD Athlon 1900+
512MB RAM
Nvidia Ti 4400

Update. This uses a different timing technique which seems to keep it better in sync and hopefully those systems that had a lot of frames dropped won't be so bad anymore. The docs have also been updated, though it's still not complete.

http://kcat.strangesoft.net/apeg-src.tar.bz2
or:
http://kcat.strangesoft.net/apeg-nostream-src.tar.bz2

Note they're bz2 format now, so the old gz urls won't work.

I got the following warnings (MinGW v3.2.3):

explay works fine graphically, but sound is still awful, you hear like static.

With MinGW 2.95.3-6, fails here:

gcc -x assembler-with-cpp -DASM_PREFIX\(x\)=_##x -o obj/mingw/dct36_3dnow.o -c s
rc/audio/dct36_3dnow.s
src/audio/dct36_3dnow.s:10: unterminated character constant
src/audio/dct36_3dnow.s:19: unterminated character constant
make: *** [obj/mingw/dct36_3dnow.o] Error 1

Though I would not worry for this one, I guess I have something old there.

If anyone can provide me with a -W switch to shut this warning up, I'd be grateful. There's no risk of 'sequence' being improperly used since the function returns immediately if it longjmp's back there.

Okay, I don't know what's wrong with these. The lines that are producing this warning are:

.long 1  // two of these
.data
intwinbase:

there's no commas at all, even on the lines right after it.

As for the sound static, I don't know.. what if you try downsampling (-downsample 1 or 2 with explay)? If that doesn't fix it, then could you try building with NO_ASM (make sure to make clean before this)?

It seems the preprocessor is behaving differently. Older versions seem to be treating ' as a character constant, even in # comment lines. I'll try and clear this up (I didn't really expect # asm comments to work right with the preprocessor anyway).

About the sound issue, I would wait until someone else tries with their files, most of my files are MPEG-2, these are old ones. Using downsample helps, so it might be static sound present already in the sample.

How you got those lines are the ones triggering the warnings? Oh, and I have no idea how to skip that warning.

(Edited: compiled fine with GCC v3.2.2 under Mandrake, and sound lacks there too, guess it is the stream. Warning with the clobber stuff, but the assembler was fine).

The code around the clobber warning line is this:

int apeg_reset_stream(APEG_STREAM *stream, int sequence)
{
  APEG_LAYER *layer = stream->layer;
  int ret;

  if((ret = setjmp(jmp_buffer)) != 0)
    return ret;

  // If sequence_num is less than 0, reset to the current stream
  if(sequence < 0)
    sequence = stream->sequence;
...

It probably has to do with some optimization GCC is trying, because debug builds don't produce the warning.

And when you say downsampling helps with the static, does that mean it goes away or is just less noticeable? If it goes away, there might be a problem with the 1:1 decoder being selected (do you have 3dnow and mmx? Allegro's tests/test program will say). What about the stream that's in with the examples (if you downloaded that version)?

(EDIT: the code boxes seem to like adding extra line breaks when I use tab characters. )

Any search for the warning gives the same result: reestructurate the code for not using setjmp, or don't use -Wall, like in this message.

Now, downsampling under Linux: 1 lowered the noise, 2 made it disappear. Under Windows, downsampling 1 or 2 makes no sound at all be generated.

(Edited: test.exe reports: CPU family: 1586 / cpuid/ FPU / cmov / SSE / SSE2 / MMX / MMX+ -yep, Intel-).

(Edited 2: And I was referring as to how you knew .long and so were the ones giving warnings).

Okay, that makes little sense. The only difference between the downsampling modes are the decoder functions used and the audio stream's playback frequency. While the noise being lowered makes sense (and thus seems to indicate that it is the stream), it makes no sense to why Windows would lose sound.

Okay.. I disabled the 3dnow stuff and played a few streams.. it all sounds fine. So either you played a bad stream, or APEG's not properly decoding the stream for some resaon.

Because the warning message had line numbers. And if the warnings were from the post-preprocessed assembly source, it would make even less sense since it would put the warning right in the middle of assembly code, where it would cause real problems.

I hate when anyone guesses unix tools because I have sh.exe in my path

Now, compiling with NO_ASM increases notably the noise. And happens with some more mpeg files I had around. -downsample works here, though. They are played well enough with Media Player.

And since there is no , in the assemble clode, I still have my doubts about the lines you guessed...

APEG doesn't. I might've accidently slipped in a command that's needs unix/unix tools.. what is it?

Somewhat makes sense, since the downsampling synth code is C anyway (the dct code is a different story, but I guess that means it's not the dct code if downsampling is just like before).

Also, out of curiousity, which sound driver are you using? The 4.0.3 default? What if you use the AllegMix driver?

Which is why I'm completely baffled by it. Maybe it has something to do with the preprocessor..

Hmm... this is strange... I think it is because my sh.exe is outdated:

About the assembler error:

D:\Compiler\Source\C\apeg\src\audio>cpp decode_3dnow.s > i.s

D:\Compiler\Source\C\apeg\src\audio>as i.s
i.s: Assembler messages:
i.s:38: Warning: rest of line ignored; first ignored character is `,'

Line 38 is .comm buffs.40,4352,32.

(Edited: added the assembler error correctly)

Okay.. fixed the assembly warning messages. My asm reference says that .comm can accept an optional third parameter (for alignment), but apparently, mingw doens't like it. So I'm just doing the alignment with .align.

And I confirmed it.. the static is not due to your stream. There's something funky MinGW is doing that Linux-GCC doesn't, is all that I can guess. I'll look through the code to see if there's anything non-standard it's doing.