AudioLevel

[dgrace]

Ok back from vacation. I got the math working better to convert from linear scale FFT numbers to log scale frequency bands. The previous versions were a bit of a kludge, it was just using the raw FFT numbers for the low bands and then sort of smearing them across the high bands with some magic constants I pulled out of my ass.

You can now specify FreqMin and FreqMax to determine the overall bandwidth you want displayed (defaults are 20 and 20000). You'll have to play with these to see what you like - I tend to run mine at 40/16000 with a 1024pt FFT at 48khz. I removed the FFTGain and BandGain params as they should no longer be needed. (you can always scale things back in Rainmeter with a Calc if you need to)

If you want the raw FFT data you can still get it, just use FFTIdx instead of BandIdx in the child measures. For an FFTSize of N, you get (N/2)+1 frequency bins back, so you can use FFTIdx=0 up to FFTIdx=(N/2). (for further reading: http://en.wikipedia.org/wiki/Discrete_Fourier_transform)

Enjoy!

dave

[pisac]

http://youtu.be/Egwt5tUghAo

[drakulaboy]

that would be awesome

[youtube]sjvXceWdwDI[/youtube]

[youtube]XdMTIdxa3dk[/youtube]

[Brian]

@dgrace:
We have updated our plugin SDK, so you may want to update your plugin to the latest. There isn't a whole lot of changes, but you might want to check out the new logging functions which will log which skin and measure the error came from. Also, the new SDK requires Rainmeter 3.0.2.2161 or higher to run, so make sure to add that to your .rmskin if you decide to go that way.


Also, I have been playing around with your plugin and have noticed some strange behavior. I have 4 skins using your plugin (Your skin, jsmorley's skin, killall-q's skin, and my own). When I first turn on something with sound, Rainmeter's CPU usage is fine, running around 1% (or me). However, when I stop the sound, Rainmeter's CPU usage increases roughly 3% per skin (so a total of 12%, for me anyway). Normally I wouldn't worry will so many skins running at very small update rates, but since the CPU usage is fine when there is sound playing, I think there might be something wrong in your plugin. Maybe you are polling for sound too quickly or something along those lines. Rainmeter seems to run fine, just an increased CPU usage when not playing sound (but only after sound was played).

-Brian

[Dank420]

...and i cant seem to make vlc Buzz anymore , BEUATIOUS, No Buzz!!!!
Edit: as soon as i post i got buzz... can still happen but way less frequent

[dgrace]

@dgrace:
We have updated our plugin SDK, so you may want to update your plugin to the latest. There isn't a whole lot of changes, but you might want to check out the new logging functions which will log which skin and measure the error came from. Also, the new SDK requires Rainmeter 3.0.2.2161 or higher to run, so make sure to add that to your .rmskin if you decide to go that way.


Also, I have been playing around with your plugin and have noticed some strange behavior. I have 4 skins using your plugin (Your skin, jsmorley's skin, killall-q's skin, and my own). When I first turn on something with sound, Rainmeter's CPU usage is fine, running around 1% (or me). However, when I stop the sound, Rainmeter's CPU usage increases roughly 3% per skin (so a total of 12%, for me anyway). Normally I wouldn't worry will so many skins running at very small update rates, but since the CPU usage is fine when there is sound playing, I think there might be something wrong in your plugin. Maybe you are polling for sound too quickly or something along those lines. Rainmeter seems to run fine, just an increased CPU usage when not playing sound (but only after sound was played).

-Brian

Ok thanks Brian - I'll grab the latest SDK and rebuild it. Also will try to repro the cpu issue. When you say "stop the sound" you mean you shut down a sound application? or just press stop in the application? or close the device? Let me know.

Also a request on logging: could the Log function be written to take varargs, so I could use it like printf? Something like this (except would need to use WCHAR strings):

Code: Select all

static const char* _Log (const char* fmt, va_list args)
{
	static char s_buf[1024];

	// compose string
	vsnprintf(s_buf, sizeof(s_buf), fmt, args);
	// output
	printf("RainMeter Log: %s", s_buf);

	return s_buf;
}

static const char* Log (Uint32 level, const char* fmt, ...)
{
	if(s_options.verbose >= (int)level) {
		// Compose string
		va_list vlist;
		va_start(vlist, fmt);
		const char* str = _Log(fmt, vlist);
		va_end(vlist);
		return str;
	}
	return NULL;
}

dave

[Brian]

Also will try to repro the cpu issue. When you say "stop the sound" you mean you shut down a sound application? or just press stop in the application? or close the device? Let me know.

It happens when I press stop in the application (winamp) and also when I shut it down as well. Also, the CPU spike isn't immediate, it happens over the course of 10 seconds or so, but does remain constant after that.

Also a request on logging: could the Log function be written to take varargs, so I could use it like printf? Something like this (except would need to use WCHAR strings):

This is exactly what the new log functions do. We added two new logging functions.
RmLog(void* rm, int level, LPCWSTR message) which is an overload of the regular RmLog function. This takes an extra parameter rm that you can save from either the Initialize or Reload functions. This is to allow for the About dialog to know "where" the message came from (ie. "Source" column).
RmLogF(void* rm, int level, LPCWSTR message, ...) just like above, only it takes extra parameters like printf.

-Brian

[dgrace]

It happens when I press stop in the application (winamp) and also when I shut it down as well. Also, the CPU spike isn't immediate, it happens over the course of 10 seconds or so, but does remain constant after that.

Does the CPU spike go away when you refresh the Rainmeter widgets? I'm assuming so but would be good to confirm. I don't seem to be seeing the same thing on my system but I'll try running more instances.

This is exactly what the new log functions do.

Great minds, and all that. Cheers! That'll definitely help to make the logs more useful.

dave

[Brian]

Does the CPU spike go away when you refresh the Rainmeter widgets? I'm assuming so but would be good to confirm. I don't seem to be seeing the same thing on my system but I'll try running more instances.

Yes it does. If I refresh all the skins, my CPU hovers around 1% usage. When I start playing music, my CPU still hovers around 1%. As soon as I stop the music either by using the stop button or by closing my music app, the CPU usage slowly rises until it hits around 12%-13%. It usually takes about 8-12 seconds to fully get that high, but it doesn't go any higher. As soon I hit play, CPU usage goes back down to around 1%.

Some of the problem could be skin design, but it still feels like the plugin is chugging away looking for audio when none is available.

-Brian

[dgrace]

Yes it does. If I refresh all the skins, my CPU hovers around 1% usage. When I start playing music, my CPU still hovers around 1%. As soon as I stop the music either by using the stop button or by closing my music app, the CPU usage slowly rises until it hits around 12%-13%. It usually takes about 8-12 seconds to fully get that high, but it doesn't go any higher. As soon I hit play, CPU usage goes back down to around 1%.

Some of the problem could be skin design, but it still feels like the plugin is chugging away looking for audio when none is available.

-Brian

Your system sounds a lot better than mine. I copied my skin to 4 different dirs and loaded them up, I hit close to 35% cpu right there.

The plugin will request the current buffer at whatever interval the skin update is set to (my skin uses 0), but if the buffer isn't ready yet it should just return back out. I'm curious how the skin Update setting affects what you're seeing. I don't get any notifications about audio apps opening/closing/stopping etc., I just request the post-mix buffer contents and then process them if they're available. So I'm not quite sure what I could do differently... I guess I could try to decouple the skin update from the buffer update but that's going to involve spawning/managing new threads, and add a layer of latency between the audio and the display. Was hoping to avoid it.

In general, we never want to really have more than one of these AudioLevel parent instances around - a loopback client on the core audio service is a fairly expensive thing.

dave