@Raziel

Memory usage of each process requires patching lots of system functions.

Memory usage of a specific program is trivial if you can modify the source code. For example in C++ you can overload new/delete operators and you can redefine malloc/free and wrap everything else.

@joerg

I wish Exec would provide proper APIs to query CPU/stack/memory usage per task. I suppose most CPU meters are somewhat hacky. My second wish is that OS itself would provide some basic monitoring tools :)

Thanks for checking the sources. If somebody finds your top clone source code, it will interesting to read.

I took a screenshot of both top and tequila running at the same time: http://capehill.kapsi.fi/top/top_tequila.png

It seems that they mostly agree about performance, but top is more sophisticated, it is able to detect more tasks in general use.

@joerg

Kernel 54.20 didn't show task names (top, tequila). Kernel 54.46 seems to display those on both program. Nice.

@joerg

Here is a version from 2008:

http://capehill.kapsi.fi/top/

@nbache

Could you see also task names? Didn't ExecBase struct change recently, IIRC task lists are private now.

Joerg has sent this tool on beta list (Aug 1st 2008).

I can send this to Joerg and he can release it, or I can upload it somewhere with a license, if needed.

@SinanSam460

basic_string sources are in gcc:include/c++. You might be able to generate a stack trace by inserting asm("trap"); inside M_create before throw. I suppose the file is basic_string.tcc.

You should then rebuild your binary with debug flags, like -gstabs. You can build a helloworld app first, add trap there and test what you get.

EDIT: changed debug flag.

@Raziel

The shader you sent me doesn't validate. It's using "#version 300 es" and "texture2D". It should be using just "texture" in later version as far as I know. texture2D can be used with #version 150, for example.

I don't know who provides HAS_TEXTURE definition but if it should be provided by the application, one way to fix it is to add #define HAS_TEXTURE in the beginning, then it should compile.

#if defined(GL_ES)
#if !defined(HAS_ROUND)
#define round(x) (sign(x) * floor(abs(x) + .5))
#endif
#if !defined(HAS_TEXTURE)
#define texture texture2D
#endif
...

@Raziel

It doesn't probably work that way because if OGLES2 context is created before you start glSnoop, it cannot patch the functions and logging fails.

Luckily sashimi output redirected to a file should be pretty usable.

@Raziel

Please try this:

1) shell #1: sashimi > yourlog.txt
2) shell #2: glsnoop (no filters needed)
3) shell #3: scummmvm
4) quit in reverse order

@Raziel

No need to set any filter but a complete log is needed. I didn't see a single call to glCompileShader in the given log. Actually I cannot see any gl* calls. How did you run glSnoop?

@geennaam

It seems that click issue happens with AHI-only test program so SDL2 is excluded. It also happens on EMU10K sound card so your driver is excluded :) Tried 32K and 64K buffers.

Do you have some working surround example program?

@SinanSam460

Endian or buffer size?

@Raziel

2048 samples or bytes? 2048 samples in 16-bit stereo would be 8 kilobytes.

By sample buffer I meant what testsurround program wants (1024 samples by default).

I don't want to multiply sample count inside SDL because it will increase latency and in some action game it becomes noticable when sounds get delayed.

I'm guessing you have seen (heard?) audio buffer underruns on some configs under some load? This would produce gaps in the audio stream because audio callback is not running fast enough to fill the buffer in real-time. This is something audio task priority might have some impact.

Now regarding the surround clicking in SDL2 test program: root cause is still open. I just checked it doesn't happen on Linux Pulseaudio at least. It could be an AHI issue too.

@geennaam

Increasing sample buffer reduces clicking. AHI test sound doesn't give me clicks when I try to use 7.1 mode.

@Raziel

Yep, hopefully there will be some nice apps :)

@SinanSam460

https://github.com/ChrisNonyminus/fall ... /src/audio_engine.cc#L129

It seems engine is expecting audio data in LE format. In case data is converted to BE, you could try to use AUDIO_S16SYS instead of AUDIO_S16, which will mean AUDIO_S16MSB on AmigaOS. https://github.com/AmigaPorts/SDL-2.0/ ... /include/SDL_audio.h#L130

You can also try to double the sample count here https://github.com/ChrisNonyminus/fall ... /src/audio_engine.cc#L131

@FlynnTheAvatar

Did you try to query bitmap attributes after its creation? Maybe that shows some difference.

@geennaam

New surround version: http://capehill.kapsi.fi/sdl2/SDL2_32bit_sound_test_remap.lha

It seems that SDL should do the format conversions automatically when needed so application can use almost any format.

@geennaam

I tried to test 32-bit audio a little bit, and it works nicely in stereo mode. But in 7.1 mode there is some kind of extra noise on FL/FR. I don't have surround speakers so cannot verify 7.1 mode properly.

Test programs here: http://capehill.kapsi.fi/sdl2/SDL2_32bit_sound_test.lha

@geennaam

Thanks for the ideas, conversion sounds doable. SDL supports also unsigned and float buffers, so they could be converted as well.