Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[Matt]

nevcairiel, as long as I have your attention here, it might be interesting to watch a conversion in the debugger using debug copies of LAV.

It looks like the bottleneck for conversion is the speed at which our buffers get filled.  Basically, we can keep our buffers (which feed the DSP / encoders) basically empty.

The CPU usage isn't particularly high, making me wonder if you're yielding (Sleep(...), etc.) somewhere?  We could tell LAV when we're in an accelerated mode if it helps.

Thanks.

[Hendrik]

Are we talking about including video transcoding, or only audio, discarding video?

If including video, there may be an internal setting inside LAV Video thats badly tweaked for transcoding right now (already adjusted for the next version)
If no video, i don't see where it would Sleep.

The only place it ever sleeps is when the queues are overflowing in LAV Splitter, for example when you try to consume audio faster than video, it won't give you any more audio until you also used more of the video, to protect you from excessive memory usage from all the video that is waiting in memory.
However, if you just don't connect anything to the video pin, it'll be silently discarded and you should receive audio at I/O speed.

[Matt]

This is audio only, so nothing should be connected to the video side of the splitter.

It's not slow, but it's also not pushing my computer as hard as I thought it might.  I was just wondering if there's anything simple either of us could do to speed it up.

I'm going to spend a little time looking at our side as well, and I'll let you know if I learn anything.

[Hendrik]

Of course its single-threaded, so unless you multi-thread in your converter, its going to be limited to one core of your CPU.
I did try just now to convert audio, and i get around ~22-25% CPU usage, considering single-threaded on this system would be 12.5%, i think its a good result.