Realtime AC3 encoder soon to be released

I have a realtime AC3 encoder almost ready for release. I only have some functionalities to add and some testing to do. I'll release it in the forums. It takes it's input from ASIO. So you route 6 channels to asio on epilog in the DSP and the encoder takes care of getting the audio, encoding it and outputing it through passthru. I can't test it thoroughly because I don't have an external AC3 decoder and my soundcard does not support passthru (sb live) but it seems to work well. The Kx AC3 decoder icon pops up and there is sound on 6 channels.

I have some questions about the ASIO SDK license. My code currently use part of the SDK.

It says :

Do I really need to sign that paper and send it over in germany?

Can I release the code? Normally, you have to agree to the license before getting the SDK. I want to know if I can include the code if I put a notice that says that you have to read and agree to the license before downloading the source files.

What should I call this program? I'm looking for a good name.

Once it's released, I'll need some people to tell me if it works.

 

I see no reason why you could not release your own source code, just do not redistribute any part of the SDK (people who want to re-compile it, would need to download the SDK themselves, etc).

As for the application itself (i.e. compiled), I am not sure, but it sounds like you may have to send the signed agreement to be able to publish/release it. Your best bet would be to send them an email and ask them about it.

 

>What should I call this program? I'm looking for a good name.

"Boolboolator" or "Attila"... or... - i love abstract names

 

You may even call it "Bob", doesn't matter much for me..

Just release it ..!! :drool:

PS: "Hun" maybe a good name ..

 

I have another question, it's related to AC3 encoding/decoding. Here is a screenshot to go with the question : http://pages.globetrotter.net/samaust/Files/Screenshots/cpu1.png

This is the cpu usage when reading an AC3 file in vlc. kX is decoding it and playing it on the analog output. What is the cause of the peaks. The cpu usage oscillation has a period of about 6s.

The same thing happens when using my AC3 encoder.

It could be vlc or kX that does this. Since it happens both with vlc and my program, maybe it's kX that is the cause. I think that it may be the kX drivers AC3 decoding that does that but I don't know for sure. It should not oscillate that much, at least not that slow. Is it possible that there is a bug in AC/ decoding that went unnoticed in kX. Something like dynamic allocation and deallocation of memory every six seconds by mistake or something else.

In kX, when you activate passthru, does it deactivate the kX AC3 decoding?

Does anyone know a cpu usage monitor tool that can display the cpu usage of a single process (or even a single thread) instead of the sum of all the threads. I want to find out what is using the cpu like that.

EDIT: I found that it's possible to get the cpu usage like I wanted with the performance tool of windows. I have to go in the process category, choose % Processor Time and select all the processes.

 

is it video+audio ac3 file? video decompression may cause this.
try other player.
do the same test without real time ac3 decoding and compare cpu usage graphics. also check which process takes the cpu time.

 

It is only audio AC3. I think that it's really the kX drivers AC3 decoding that is the cause. I can't turn it off. Activating passthru probably deactivate the AC3 decoding but it does not work for me because passthru can't be activated (not supported card).

I made a test to make sure that it was the kX drivers that was the cause. I uninstalled the kX drivers and reinstalled the Creative drivers. I played the same ac3 file in vlc and I used "A/52 over S/PDIF" and the cpu usage stayed at 2% the whole time.

I've made a test file. It's a sine wave. http://pages.globetrotter.net/samaust/Files/sine.ac3
EDIT : It's normal that it does not sound like a nice sine wave because the bitrate is very low.

I'd like someone with a card that can do passthru to try to play this in vlc. After playback starts, you have to choose "A/52 over S/PDIF" in the audio menu. Try both with and without passthru activated in kX mixer and look at the cpu usage (ctrl+shift+esc, under performance). I want to find out if the AC3 decoding of the drivers gets deactivated when passthru is activated and if the cpu usage goes down when the kX drivers are in passthru mode.

 

Tril,
As you know I also have a Live! card, so as far as I know, AC3 pass-thru does not work on my card either (based on what I have read in the forum). Additionally, I do not have a digital receiver/decoder to test it out. But, regardiing your testing procedure, I was playing around a bit, and noticed that when I choose AC3 pass-thru in kX mixer, the "A/52 over S/PDIF" option is not available in VLC.

 

I must say this all sounds fantastic! I have Audigy 2 Platinum Ex and an external ac3 decoder, so if you still need someone to test this, I guess I can do it. Email me to (removed my email 'cause I'm scared of spammers) if I can help.

 

I have good news. I asked Wejgomi to test it for me and he said that it works perfectly.

I still have some small things to add (copyright notices, one more switch to give more control, maybe some other small things) and then I'll release it.

I currently use waveout. Would directsound be better?

I think I need some advice on compilers (or IDE, etc, sorry if I'm not using the correct words). My computer does not support a lot of instructions. Only MMX (+) and 3DNow (+). When I compiled avcodec.dll and the exe, the compilers probably optimized for my computer (that means, not much). At least it will work for everyone. Is there a way to compile on my computer for more recent computers so that it runs faster for them?

I can use Visual Studio 6.0 or Visual Studio .NET 2003 for the exe. I compiled avcodec.dll with MinGW.

It will only take a few more days. I still haven't decided on a name. Other suggestions? 'Bob' is nice but... there must better

 

For a name you could play around with the letters ac from ac3. Start the name with those, like Acolyte... Actually if one uses this ridiculous g4m3r style of writing AC3 allready says Ace, which sounds cool enough

edit: How 'bout Ac3r or Acer... oh but that's taken allready.

 

I think I'll call it redocneXk. It sounds high tech. It does not give any hits with google.


There is one problem with the realtime encoding. The AC3 encoder encodes 1536 samples at a time. That's the frame size. It's a set number of samples for encoding 6 channels at 48000 Hz. I don't remember the reason but it's like that and it can't be changed. That means that you always have a delay of at least 1536 samples (32 ms) when using the program.
It's a bit high but I can't do anything about it.

EDIT : There are motherboards that can do AC3 encoding. Do they create a delay because of the encoding? Are they able to go around that problem?

 

no, an nForce2 board can do hardware ac3 encoding with latencies as low as 0-5ms..

but they can't do any environmental effects like eax, eax2 etc.. so we have more portential then that

 

It would be really weird if the latency was indeed lower than the framesize, cause then it would need the data before it was being played.
So unless someone actually tested it, I would assume that it has the same problem.
As far as I know, only speech codecs are better optimized for latency, but they don't produce a high quality for music.

 

I received an answer from Steinberg. I asked them if it was necessary for me to sign and mail the license agreement. I don't think they mind if I post their answer. Here is their answer :

The answer is clear. I was skeptical when I sent them an email. I thought they would not reply because it happens sometimes with big companies.

At first, I was planning on sharing the code but I think I'll refrain from doing it. I will only share the compiled software.

It uses avcodec.dll from ffmpeg. So anyone can get the source of ffmpeg and recompile avcodec.dll. It's this library that gives AC3 encoding support.

EDIT: That last statement from me is not enterely true. When you compile ffmpeg, it creates a file called avcodec.lib. This file is included in the Visual C++ project. The included headers probably don't change but this file does. The VC++ project needs to be compiled with this file.

 

That is pretty much what I thought they would say, but thanks for sharing the info.

 

I improved the code today. It's now more stable. Before, if i started the program 10 times, it was outputting noise 1 time. Now, it works 10 times out of 10.

I also tested the latency. I compared the signal that goes to asio on prolog to the AC3 decoded by kX. It's around 160 ms.

It takes 32 ms to send to the cpu.

The rest of the time is taken by writting to a circular buffer, reading the circular buffer, copying to a work buffer, encoding (encoded data written to another bufer), copying to another buffer while encapsulating to spdif(because of encapsulation and because the bytes need to be swapped) and using a waveout function that writes to the waveout buffer. Then kX decodes that (I did not use passthru). A latency of 128 ms for all that is not bad.

Would directsound be faster, slower, equal?

 

Probably faster as its optimized for lower latencies? But perhaps not appreciably so, it sounds like you have the audio going through quite a number of stages. I think latencies of 50 or more are going to be quite unusable for most action games unfortunately, there will be other applications for this in any case.

Sounds very promising so far...

 

I have a 1.1 GHz cpu. People with faster cpu will probably get latencies a little lower.

The AC3 3ncoder adds some CRC information. I know that it's used when wrinting AC3 to disk. The program I made drops the CRC information. It's not audio so you don't send it through waveout. I could modify the AC3 encoder so that it does not calculate the CRC information. It would save some cpu cycles.

One other thing I could try is to reduce the number of times the buffer is copied. I though that I could add a function that does AC3 and spdif encapsulation (instead of only encoding) in the AC3 encoding library without having to write to a buffer between the two actions.

I'll probably write a directsound function and test the speed. I'll add a switch to choose between waveout and directsound and I'll put the faster of the two by default. I never wrote one so I'll have to look on msdn or find tutorials about it.

 

When you make some performance comparisons, you shouldn't use taskmanger or other software, that rely on windows counters. I.e. CPU usage reported is always be less than actual (sometimes real is 50-60%, reported ~5-10%). To estimate real digits use software that rely on CPU's internal performance counters.
As I understand, you're using an Athlon/Duron CPU. To estimate real CPU usage, try RightMark CPU Clock Utility (http://cpu.rightmark.org/) and for more thorough testing try to find "K7 Counter" (somewhere at http://7-zip.org).

Also you can try an optimizing compiler, like Intel C Compiler, but this will need additional testing.

Minimize buffer swapping and use directsound, should be faster... 8)