Aften 0.0.8 is out

[jruggle]

I just commited a fix for this. I haven't checked the issue with mono input, though.

Thanks for the fix!

The segfault issue does still exist with mono input when more than 1 thread and standard zero-padding are used. Here is some gdb output.

(gdb) run sine.wav sine.ac3
Starting program: /media/hdc5/src-jbr/aften/aften-svn/build/aften sine.wav sine.ac3
[Thread debugging using libthread_db enabled]
[New Thread -1210579264 (LWP 7592)]

Aften: A/52 audio encoder
Version SVN-r569
(c) 2006-2007 Justin Ruggles, Prakash Punnoor, et al.

input format: WAVE Signed 16-bit little-endian 44100 Hz mono
[New Thread -1210938480 (LWP 7595)]
[New Thread -1219331184 (LWP 7596)]
output format: 44100 Hz mono (1/0)

SIMD usage: MMX SSE SSE2 SSE3
Threads: 2




Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -1219331184 (LWP 7596)]
0x00000000 in ?? ()
(gdb) bt
#0 0x00000000 in ?? ()
#1 0x08055dc1 in encode_frame (tctx=0xb7d545ac, frame_buffer=0xb7d7ec24 "")
at /home/justin/src-jbr/aften/aften-svn/libaften/a52enc.c:1234
#2 0x08057d15 in threaded_encode (vtctx=0xb7d545ac)
at /home/justin/src-jbr/aften/aften-svn/libaften/a52enc.c:1460
#3 0xb7ec831b in start_thread () from /lib/tls/i686/cmov/libpthread.so.0
#4 0xb7e5057e in clone () from /lib/tls/i686/cmov/libc.so.6
(gdb)

[DarkAvenger]

Thanks for your reply. Wouldn't it make sense to add code to "aften_encode_close" to make sure that it doesn't stall? IMHO an API should never stall. It may fail. If all else fails it might even crash. But it should never stall IMHO. Because I (as an libAften user) can handle failing APIs, I can even handle crashing APIs, but once an API stalls every hope of a graceful error handling is lost. Maybe you could just add two encode_frame(NULL) calls in the beginning of aften_encode_close if necessary?

I also was thinking about this, but I have to look closer whether it can be done properly (esp thinking of portability). On the other hand I think it is not the worst if the dev gets to know that he is doing something wrong. As missed samples won't be noticed immediately, but a hang does.

[DarkAvenger]

The segfault issue does still exist with mono input when more than 1 thread and standard zero-padding are used. Here is some gdb output.


I at least can't reproduce it when I use raw input. Could you mail me the sample (perhaps flac compressed)?

According to your backtrace it seems to die in the mdct. Does it work if you disable SIMD?

[Edit]OK, I found the cause and fixed it. nr and fs were 0 w/o aften having written anything to disk. Thus it exits the loop though the encoder isn't stopped yet/hasn't been flushed.

[madshi]

I also was thinking about this, but I have to look closer whether it can be done properly (esp thinking of portability). On the other hand I think it is not the worst if the dev gets to know that he is doing something wrong. As missed samples won't be noticed immediately, but a hang does.
Please try to find a way to get rid of the hang(s). I've just tried to make my Delphi libFlac implementation hang free - and it's a *major* pain in the ass. I'm not joking. The problem is that there are certain conditions where I simply want to abort the encoding. And I don't really know how to do that properly. If I don't call encode_frame often enough aften_encode_close hangs. If I call encode_frame too often, encode_frame hangs. So I don't really know a safe and never failing way to abort encoding and clean aften up without risking a hang. Except by using "-threads 1". In that case there don't seem to be any hangs. So in the end that means that multi thread encoding is currently in no fit state for me to use safely.

Thanks.

[DarkAvenger]

Please try to find a way to get rid of the hang(s). I've just tried to make my Delphi libFlac implementation hang free - and it's a *major* pain in the ass. I'm not joking. The problem is that there are certain conditions where I simply want to abort the encoding. And I don't really know how to do that properly.

Aborting is simple: Just do
while (encode_frame(..., NULL));
after that you can call the close function.

Just to be precise: Hangs can be avoided. It is a result of false usage - not a bug in aften. Of course, I know that this way the API is not entirely intuitive...

[madshi]

Aborting is simple: Just do
while (encode_frame(..., NULL));
Even this loop can result in problems. Try this in multi thread situation:

aften_encode_init(...);
aften_encode_frame(..., 1536 real samples);
while (encode_frame(..., NULL));
aften_encode_close(FContext);
I'm still getting a crash or a hang that way on my PC. Your loop solves the problem only if there are at least two aften_encode_frame calls with real samples before your loop.

Hangs can be avoided. It is a result of false usage - not a bug in aften.
aften.exe is quite simple, it's just one encoding loop and that's it. It's easy to use libAften "properly" in such a situation. But think about more complicated situations. E.g. think about a DirectShow filter. The whole encoding process is then done event based. You never know in which moment the DirectShow filter might be disconnected, aborted or destroyed. As a result you might not know exactly in which state the encoder is in that very moment.

destructor TAftenDirectShowFilter.Destroy;
begin
// what do I need to put in here?
// it needs to always work, no matter in which state the encoder is
// it also needs to work for both single and multi threading
// it also needs to work for all other combinations of options
end;

[wisodev]

@madshi

I had the same problem as you with aften termination and the trick that DarkAvenger suggested works without any problems for EncWAVtoAC3. Please check the EncWAVtoAC3 source code (http://thefrontend.svn.sourceforge.net/viewvc/thefrontend/EncWAVtoAC3/src/EncWorkThread.cpp?revision=141&view=markup) (lines 553 to 564).

[DarkAvenger]

aften_encode_init(...);
aften_encode_frame(..., 1536 real samples);
while (encode_frame(..., NULL));
aften_encode_close(FContext);
I'm still getting a crash or a hang that way on my PC. Your loop solves the problem only if there are at least two aften_encode_frame calls with real samples before your loop.


Actually I knew about this situation, but I thought you'd know the answer how to prevent it as I just wanted to give the basic idea. In fact it is the same fix I commited a few hours ago, to make it robust.



aften_encode_init(...);
got_fs_once = 0;
fs = aften_encode_frame(..., 1536 real samples);
if (fs)
got_fs_once = 1;
while (fs || !got_fs) {
fs = encode_frame(..., NULL)
if (fs)
got_fs_once = 1;
}
aften_encode_close(FContext);

The best idea is usually to use aften.c as example code and throw away stuff (while thinking hard what the code to be thrown away really does) until one gets what one wants, instead of implementing from scratch. That way you'll usually start with working code and transform it to one's needs, instead of trying to convert code into a working state.

@wisodev

No madshi is right. My example was too simple and not right for all situations (as I only noticed the flaw today). The above pseudo code should show how to make it generic. You may want to update your code.


The problem of what I see with making the API more robust (ie make it possible to call close in between) would be a lot of additional overhead in the encode path (locking-wise). Therefore I prefer a performant API, with as little locking as necessary- even if it means "slightly" more complicated use... But yes, then it should be better documented and I think I should really find the time to write an API_Usage.txt...

[madshi]

Actually I knew about this situation, but I thought you'd know the answer how to prevent it as I just wanted to give the basic idea. In fact it is the same fix I commited a few hours ago, to make it robust

[...]

The best idea is usually to use aften.c as example code and throw away (while really thinking hard what the code to be thrown away does) stuff untill one gets what one wants, instead of implementing form scratch. That way you'll usually start with working code and transform it to one's needs.
That's exactly what I did. But you missed my point about aften.c working synchronously (one big linear encoding loop), opposed to my needs of event based programming, which is quite a big difference.

How would you code the destructor of an Aften DirectShow filter? I think one solution would be to feed Aften with two dummy frames of real (zero) samples, just to be safe. And then using your "while" loop from your previous comment. Or do you have a better idea?

But you gotta admit that you make it quite hard to use Aften "properly"? :p

[DarkAvenger]

It doesn't matter whether you work in a loop or event based. You just have to take a look at the same set of state variables (in aften they are nr, fs and frame_cnt) and behave according to them. It is not rocket science, after all...

Regarding dtor: Look at my pseudo code. There fs and got_fs_once are your state variables.

Feeding Aften with dummy frames could lead to other potential problems with sync if you don't do it properly (look at the padding issue). I hope by now you understood that feeding *two* frames won't help you. It is not a constant. It depends on the number of threads.

At last, I added a text file with some notes about using the API.

[madshi]

I think I got it now. Thanks for your help!

[madshi]

I'm sorry to say but there's another hang issue with "aften_encode_close" which is not properly handled by aften.c yet. Try this:

aften_encode_init(...);
aften_encode_close(...);
It will hang in multi thread situation. This doesn't happen in aften.exe, but only because aften.exe doesn't clean up properly in error situations. Replace all those "return 1" calls with "goto end:" and aften.exe will hang, too, whenever there's any kind of error condition.

[DarkAvenger]

Right, this one is evil. :) And yes, this pattern should be allowed. I probably won't be able to fix it before the week-end, as I am busy with work. But thx for pointing this out.

[madshi]

The sample code in "API.txt" needs to be changed, too, I think. If "read_samples" returns 0, there'll be a hang.

You don't need to hurry about this. I know how to work around it. But my destructor is getting longer and longer. For giggles, here's my latest destructor code, which has now successfully passed all my tests:

destructor TAftenEncoder.Destroy;
var dummySamples : pointer;
i1 : integer;
begin
if FValid then begin
if (not FInitialized) and (FLastResult = -777) then begin
// the encoder has not been fed any real samples yet
// we need to do that, or else "aften_encode_close" will hang
GetMem(dummySamples, FBytesPerFrame);
FLastResult := aften_encode_frame(FContext, FBuf, dummySamples);
FreeMem(dummySamples);
end;

if (not FInitialized) and (FLastResult = 0) then
// encoder has not yet returned any valid AC3 frames
// but it was already fed with real PCM samples
// a call to "aften_encode_close" would hang in this situation
// so we feed the encoder with samples until we receive a valid frame
for i1 := 0 to 15 do begin
FLastResult := aften_encode_frame(FContext, FBuf, nil);
if FLastResult <> 0 then
break;
end;

while FLastResult > 0 do
// the last time the encoder was called we got a valid AC3 frame back
// when encoding is aborted there may still be AC3 frames in the queue
// a call to "aften_encode_close" would hang in this situation
// so we fetch all AC3 frames from the queue until there's nothing left
FLastResult := aften_encode_frame(FContext, FBuf, nil);

// finally we can safely close the encoder down <sigh>
aften_encode_close(FContext);
VirtualFree(FBuf, 0, MEM_RELEASE);
end;
inherited;
end;
I'm still hoping that this complicated shutdown logic will sooner or later be done internally by libAften. It would reduce my Aften related code by 30% and it would also make my code much simpler and easier to understand.

And there's another reason why I'm still not feeling well with all this destructor code: The whole destructing logic might be confused if "aften_encode_frame" keeps on returning error codes. What do I need to do in that case to properly shut aften down? Do I still need to feed the encoder until all threads are busy? Do I still need to empty the queue? If "aften_encode_frame" keeps on returning error codes, I might have to call "aften_encode_close" without ever having filled/freed the encoding queue. In that case I might again have a hang. Now I don't know in which situation exactly "aften_encode_frame" could return error codes. Maybe it will never happen (as long as there are no bugs in my code). But what do I know? Maybe if memory is short (so allocations fail) I'll have no other choice than to run into a hang because I simply can't empty the encoding queue?

[DarkAvenger]

Well, I thought I had implemented it that way that the encoder will shut the threads down, if an error had happened.but looking again, I don't think it works that way... Man, you are cruel. ;)

[Edit] Oh yes, it should work that way: On error in encoding routine, the encoder does shut down all threads, ie. if you get a negative value back from the encoder, you should be able to safely call the close function. You mustn't call the encode function after an error condition.

[madshi]

Well, I thought I had implemented it that way that the encoder will shut the threads down, if an error had happened.but looking again, I don't think it works that way... Man, you are cruel. ;)
Sorry... :D

Oh yes, it should work that way: On error in encoding routine, the encoder does shut down all threads, ie. if you get a negative value back from the encoder, you should be able to safely call the close function. You mustn't call the encode function after an error condition.
Sounds good - thanks! :)

[DarkAvenger]

I may have found an easy solution for the closing issue. Perhaps you can clean-up your dtor. Pleaser test. I haven't verified it thoroughly as I am quite tired. Furthmore error handling is missing (the close function should return, whether it was a clean close or not, ie if threads were running). And aften.c still doesn't clean up ressources thoroughly if it bails out early.

[madshi]

Thanks very much! I'll test it as soon as wisodev compiles a new build... :) Don't have Aften set up here for MSVC++ compiling on my PC. Am using libAften with Delphi...

[wisodev]

Thanks very much! I'll test it as soon as wisodev compiles a new build... :) Don't have Aften set up here for MSVC++ compiling on my PC. Am using libAften with Delphi...

Aften R573 Build uploaded:
https://sourceforge.net/project/showfiles.php?group_id=183195&package_id=212610&release_id=547576

[DarkAvenger]

I changed the API a bit to simplify its usage. I plan to move the padding functionality into the lib, as well. It really doesn't belong into aften.c, as lib users have to copy the code to get this feature.

[madshi]

@wisodev, thanks for the new build!

@DarkAvenger, finally got around testing your changes. On a first check everything seemed to work beautifully. Unfortunately on the very last test I got a hang again. Then it was gone. Then it came back. Then I changed the test conditions and libAften crashed during aften_encode_close (it had worked in an earlier test). So it seems to me that the shutdown is not really stable yet. It often works. Then suddenly the same test which worked before hangs or crashes again.

Wouldn't it be the safest solution to just move all the loops and checks that are currently in aften.c to aften_encode_close? Basically what you told me to do my in destructor - couldn't you do all of that in the beginning of aften_encode_close? Of course libAften would then internally need to keep track on whether aften_encode_frame was called often enough with real samples and with NULL and what the last aften_encode_frame had returned etc. But I guess that shouldn't be too hard?

Adding the pad functionality to libAften sounds like a good idea to me. I welcome any change which simplifies the API.

[DarkAvenger]

Could you be more precise of your test so I can reproduce it? Oh, and please try current svn as it contains further fixes.

[madshi]

Could you be more precise of your test so I can reproduce it?
I've tested "everything" and everything worked. Then for whatever reason I tested this again:

(1) init
(2) close

Got a hang this time. Tried it 3 times. Got hangs 3 times. Recompiled. Tried again. Hang gone. :confused:

Then I changed it to this:

(1) init
(2) one encode_frame(real samples) call
(3) close

Got a crash this time in libAften.dll. Tried it 3 times. Got 3 crashes. Recompiled. Still crash.

All of this worked perfectly fine in my first test run. So I guess reproducing it might be tricky. It's probably a timing problem.

(P.S: Might be that I confuse the 2 tests above. Maybe the first one had crashes and the 2nd hangs. Not sure...)

Oh, and please try current svn as it contains further fixes.
Ehm... wisodev? :o

[DarkAvenger]

Oh wait, I think I introduced a new bug. I'll fix it tomorrow. I suggest you wait till then.

BTW, why don't you compile aften yourself? It is not very difficult.

[madshi]

BTW, why don't you compile aften yourself? It is not very difficult.
I hate C++ and I don't have CVS access setup.

[DarkAvenger]

It is C and svn. :P Anyway, you don't have look at the code...using cmake to just compile it doesn't require a lot of skills. ;)

Anyway, I committed a hopefully now really fixed version. The big bug was quite embarassing and perfectly explains your findings: mdct buffers should be freed *after* flushing the encoder...

[wisodev]

@madshi

Aften R587 Win32 & Win64 binaries are available for download (https://sourceforge.net/project/showfiles.php?group_id=183195&package_id=212610&release_id=548369) :)

[DarkAvenger]

So I moved the padding functionality into libaften (and also fixed aften.c to be able to encode files < 256 samples w/o padding. I didn't test this, though.) Just provide the first 256 samples in AftenContext's new member initial_samples and then no padding with zero samples happens.

[wisodev]

I have released version 0.8 of WAV to AC3 Encoder (http://www.thefrontend.net/EncWAVtoAC3/index.html) (sf.net shell service is offline so website was not updated).

Download

Binary Package: Win32 Unicode (http://prdownloads.sourceforge.net/thefrontend/EncWAVtoAC3-0.8-Win32U-bin.zip?download) | Win32 Ansi (http://prdownloads.sourceforge.net/thefrontend/EncWAVtoAC3-0.8-Win32A-bin.zip?download) | Win64 Unicode (http://prdownloads.sourceforge.net/thefrontend/EncWAVtoAC3-0.8-Win64U-bin.zip?download) | Win64 Ansi (http://prdownloads.sourceforge.net/thefrontend/EncWAVtoAC3-0.8-Win64A-bin.zip?download)
Installer Package: Win32 Unicode (http://prdownloads.sourceforge.net/thefrontend/EncWAVtoAC3-0.8-Win32U-installer.exe?download) | Win32 Ansi (http://prdownloads.sourceforge.net/thefrontend/EncWAVtoAC3-0.8-Win32A-installer.exe?download) | Win64 Unicode (http://prdownloads.sourceforge.net/thefrontend/EncWAVtoAC3-0.8-Win64U-installer.exe?download) | Win64 Ansi (http://prdownloads.sourceforge.net/thefrontend/EncWAVtoAC3-0.8-Win64A-installer.exe?download)
Source Package: Visual C++ 2005 SP1 (http://prdownloads.sourceforge.net/thefrontend/EncWAVtoAC3-0.8-src.zip?download)

Changelog


- Added version check for presets configuration files when loading.
- Added check for non existing files when loading files list.
- Added load/save presets to File menu and removed Load/Save presets buttons from main window.
- Added automatic remove of successfully encoded files from files list.
- Added support in Add file dialog for raw PCM audio files (*.pcm;*.raw;*.bin).
- Added 'Reset current' button to restore all default settings for currently selected preset.
- Added possibility to change value of selected item in options list by using Right Arrow and Left Arrow keys.
- Added ToolTips for options list items.
- Fixed total progress bar reset before encoding next file.
- Fixed crush when generating batch file.
- Fixed bug in parallel file encoding mode: number of threads was set to zero when Auto was selected.
- Changed minimum supported screen resolution to 800x600 pixels.
- Added build information to about dialog.


Screenshots

http://img138.imageshack.us/img138/8197/mainwndbigpl5.th.jpg (http://img138.imageshack.us/my.php?image=mainwndbigpl5.jpg)

http://img138.imageshack.us/img138/6398/workwndbigwz2.th.jpg (http://img138.imageshack.us/my.php?image=workwndbigwz2.jpg)

http://img263.imageshack.us/img263/4343/aboutwndbiguk0.th.jpg (http://img263.imageshack.us/my.php?image=aboutwndbiguk0.jpg)

Thanks,
wisodev

[raquete]

wisodev,what is different between win32 unicode and win32 ansi?
both are working but don't know what is the right one to use.

thanks so much for new version! :)

[Adub]

one is for xp, one is for older versions of microsoft, 95,98,Me etc.

Unicode is for XP.

[raquete]

very clever,thanks so much.

[Elektra999]

Thank you very much for the Aften v0.8

Good work!! :)

[madshi]

@madshi

Aften R587 Win32 & Win64 binaries are available for download (https://sourceforge.net/project/showfiles.php?group_id=183195&package_id=212610&release_id=548369) :)
Sorry for the late reply. Finally got around testing this one. Unfortunately it doesn't work at all for me. If I just replace the old libaften.dll with this new one, every aften_encode_frame returns "-1". Furthermore every aften_encode_frame call writes this text to stdout:

Invalid counter passed to aften_encode_frame.
I've checked "aften-types.h" to see if there's anything which has changed (remember, I'm using my own header translated to Delphi). But I didn't find any changes. With the old libaften.dll my Delphi encoder works fine, with the new one it fails. Doesn't matter if I use it in single or multi threaded mode.

Furthermore, aften_encode_close still stalls. I've done the following 1000x in a loop:

aften_set_defaults;
set custom aften parameters;
aften_encode_init(multithread mode) -> succeeds;
aften_encode_frame(1536 real samples) -> returns "-1";
aften_encode_close;
I'm getting stalls randomly after a number of loop passes.

[wisodev]

Sorry for the late reply. Finally got around testing this one. Unfortunately it doesn't work at all for me. If I just replace the old libaften.dll with this new one, every aften_encode_frame returns "-1". Furthermore every aften_encode_frame call writes this text to stdout:

Invalid counter passed to aften_encode_frame.
I've checked "aften-types.h" to see if there's anything which has changed (remember, I'm using my own header translated to Delphi). But I didn't find any changes. With the old libaften.dll my Delphi encoder works fine, with the new one it fails. Doesn't matter if I use it in single or multi threaded mode.

Furthermore, aften_encode_close still stalls. I've done the following 1000x in a loop:

aften_set_defaults;
set custom aften parameters;
aften_encode_init(multithread mode) -> succeeds;
aften_encode_frame(1536 real samples) -> returns "-1";
aften_encode_close;
I'm getting stalls randomly after a number of loop passes.

aften.h 0.0.8
AFTEN_API int aften_encode_frame(AftenContext *s, unsigned char *frame_buffer,
const void *samples);


aften.h r587
AFTEN_API int aften_encode_frame(AftenContext *s, unsigned char *frame_buffer,
const void *samples, int count);


Did you update you calls to aften_encode_frame? It also fails in EncWAVtoAC3 v0.8 when using with aften r587 but I didn't update my code for now (working on it :)).

[nimrodim]

I have a really noob question and would love to get some help.

I have a 5.1 channel ac3 file which i decompressed and changed the frame rate using Besweet. So now i have 6 files with the expected format of filename-(channel c\fl\fr\lfe\sr\sl).wav

Now how do i encode it back to ac3 with this program...do i have to put all 6 files in the file list or just the center channel file?

Which "Channel mapping order of input audio" do i choose, the wav(default) or ac3?

Do i have to set "Audio coding mode" and "Specify use of LFE channel" manually to what i want?

I would like to mention that i am using a Quad core processor so i have all the MMX, SSE, SSE2, SSE3 options enabled - but which engine would be best for me to use?

Thanks in advance,
Nim

[madshi]

Did you update you calls to aften_encode_frame? It also fails in EncWAVtoAC3 v0.8 when using with aften r587 but I didn't update my code for now (working on it :)).
Oooops, missed that!! I only checked for changes in the structures... :)

What meaning/purpose does that new parameter have? Is it the number of frames or the number of bytes or number of samples or something else? Or is it a first version of DarkAvenger's padding logic change ("AftenContext's new member initial_samples")?

Thanks!

[LigH]

@ nimrodin:

Unfortunately ... as far as I remember, you need to multiplex all six single-channel files into one 6-channel WAV file -- this can be done using the MUX file generator in BeLight using the WAV preset (not AC3!), and BeSweet with WAV-to-WAV "conversion"; if someone already implemented MUX file support into Aften, and I missed that, please excuse.

You will have to set the encoding mode to 3/2 + LFE.

[nimrodim]

@ nimrodin:

Unfortunately ... as far as I remember, you need to multiplex all six single-channel files into one 6-channel WAV file -- this can be done using the MUX file generator in BeLight using the WAV preset (not AC3!), and BeSweet with WAV-to-WAV "conversion"; if someone already implemented MUX file support into Aften, and I missed that, please excuse.

You will have to set the encoding mode to 3/2 + LFE.

Thanks for the reply,
As each channel is about 512mb...wouldn't there be a size limitation for the combined wav?
I could try to use Wav to Wav with the frame rate conversion in BeSweet and then plug the output file into the "WAV to AC3 Encoder".
This would bypass the need to mux the wav.

Is this possible?

[LigH]

The usual 2 GB limit (technically it would be 4 GB - 1 B, but some tools count signed numbers and fail earlier) is indeed an important issue. Therefore I can only recommend that Aften should support MUX files or a similar way to recognise a set of mono WAV files. But I am just not up-to-date if this was already implemented...

The AC3 encoder used in BeSweet has a lower quality than Aften. And Windows would always need to write a file, even if BeSweet was able to output into a pipe. It won't be possible to chain Aften and BeSweet with a pipe.

[madshi]

@nimrodim, why don't you do the whole process in one step with BeHappy? That's what I'm usually doing... BeHappy uses Aften for encoding.

[vlada]

I also realized, that BeHappy is the only really reliable transcoder for AC3/AAC/Ogg Vorbis.

[wisodev]

Oooops, missed that!! I only checked for changes in the structures... :)

What meaning/purpose does that new parameter have? Is it the number of frames or the number of bytes or number of samples or something else? Or is it a first version of DarkAvenger's padding logic change ("AftenContext's new member initial_samples")?

Thanks!

New parameter was added in revision 577 (http://aften.svn.sourceforge.net/viewvc/aften?view=rev&revision=577). The padding was moved into libaften in revision 589 (http://aften.svn.sourceforge.net/viewvc/aften?view=rev&revision=589).

[madshi]

New parameter was added in revision 577 (http://aften.svn.sourceforge.net/viewvc/aften?view=rev&revision=577). The padding was moved into libaften in revision 589 (http://aften.svn.sourceforge.net/viewvc/aften?view=rev&revision=589).
Ah, I see, that makes sense. Thank you.

[DarkAvenger]

@madshi

Yes I explained a few posts earlier that I changed the API to make it a bit easier to use. If you look at the sample you'll see I now need less variables for the same functionality.

I tested your loop and in Linux I don't have a problem with 2000 iterations - though my encode doesn't error out. I also don't know if stack gets messed up in your test, as you haven't changed your code to the new API, yet.

[madshi]

@DarkAvenger, I'm really sorry, but I have the following problems with R587:

(1) It still stalls randomly if I do this:

aften_set_defaults;
set custom aften parameters;
aften_encode_init(multithread mode) -> succeeds;
aften_encode_frame(1536 real samples) -> succeeds;
aften_encode_close;
Try doing this 1000x in a loop. You should be able to reproduce the hang that way.

(2) If I execute the following code in a loop, about one out of 20 times libAften writes the complaint "count mustn't be 0 when passed the first time to aften_encode_frame" to stdout:

aften_set_defaults;
set custom aften parameters;
aften_encode_init(multithread mode) -> succeeds;
aften_encode_frame(1536 real samples) -> succeeds;
while (aften_encode_frame(flush) > 0) do ;
aften_encode_close;

Adding all the security flushing loops etc back in doesn't help with R587. I'm regularly getting hangs either way, as long as I switch to multithreading mode and feed only one frame of real samples to aften.

(3) The documentation about the "count" parameter for the "aften_encode_frame" sais:

must be equal to A52_MAX_CODED_FRAME_SIZE, less than A52_MAX_CODED_FRAME_SIZE for the last frame
Does it really have to be less than A52_MAX_CODED_FRAME_SIZE for the last frame? What if the last frame happens to have exactly A52_MAX_CODED_FRAME_SIZE samples?

Sorry for being a pain in the ass and thanks for your continued work on this!!

[madshi]

Ah, our posts crossed!

Yes I explained a few posts earlier that I changed the API to make it a bit easier to use. If you look at the sample you'll see I now need less variables for the same functionality.
Yes, it's really easier. I like it.

I tested your loop and in Linux I don't have a problem with 2000 iterations
That's strange. It reliably hangs for me. But I'm not using the latest svn (of course).

[DarkAvenger]

Does it really have to be less than A52_MAX_CODED_FRAME_SIZE for the last frame? What if the last frame happens to have exactly A52_MAX_CODED_FRAME_SIZE samples?

Sorry for being a pain in the ass and thanks for your continued work on this!!

Thats is a typo and is corrected in svn. It should be A52_SAMPLES_PER_FRAME. If the last frame happens to have A52_SAMPLES_PER_FRAME, just call aften with 0 afterwords (= flushing). It should work.

I still don't know why you are getting hangs. But I also cannot properly debug on windows, which is especially bad as the locking is different. Well, I won't be having time for the next 2 weeks looking closer into the issue, as I'll be at TechEd for a week.

[madshi]

I still don't know why you are getting hangs. But I also cannot properly debug on windows, which is especially bad as the locking is different. Well, I won't be having time for the next 2 weeks looking closer into the issue, as I'll be at TechEd for a week.
I don't need this urgently. I'm still using a rather old libAften.dll with the old complicated shutdown logic. It works well without hangs. So I can wait...

[DarkAvenger]

I actually foudn a race in the windows code, which I hopefully fixed. When initing the threads, I waited in POSIX code for each thread, before initing the next one. But I didn't do this in Windows code, so maybe this could have had side effects.