Is it possible to disable this floating window with buffer status? I couldn't find the switch..

How about I make a Columns UI extension out of the window? I'll work on that soonish.

Sounds good to me

how about a combo-toolbar-visualization:

mode 1: the usual spectrum
mode 2: vu-meter
mode 3: buffer-status

One could just switch the mode by single-clicking on the vis.

Yes, i'm a screenspace-whore ;)

- Lyx

Good idea, but I don't use Columns UI So, everything I need is to be able to switch off this window And the best thing is to be able to switch it on/off via keyboard shortcut. And, it would be even better if the window would remember it's position.

Uploaded v1.3.

• Buffer status pop-up is now configurable.
• Added menu items (for hotkeys) to enable, disable, or toggle the pop-up status dialog.
• Added ui_extension for Columns UI alpha 4, under the General category. You can create multiple instances freely, not that there's any point.

Thanks, Kode54 I'm happy now

Thank you, Kode54!
Now the buffer status window even remembers it's position after reboot...
One small ting though (it's always just "one small thing", isn't it? )
With the last version the buffer status window minimized with the main UI. Now it's sometimes it does, sometimes it doesn't. It would be nice with some consistency, maybe even an option (?).

Uploaded v1.31.

• Status window only pops up if the main window is visible.
• Status window always forwards focus to the main window.
• Status window sets/kills auto-hide timer on activation, so it will hide itself if you stopped streaming while the main window was minimized.

Perfect!

Uploaded v1.32.

• Adjusted pop-up window posting slightly, again. This may or may not use less processor time than the last version. The usage on my Athlon64 3200+ is not measurable.
• Buffer thread now runs at the same priority level as the calling thread.

There have been a few users who experienced stuttering with my PTypes/PHTTP based reader. Since the first version I released with this alternate HTTP reader and buffering mechanism was v1.2, it would appear the problem has been since my first release.

The problem may be that the buffer thread was being started at the normal priority, which would be a lower relative level than the playback thread. I have corrected this, but I will make it configurable if anyone needs it.

I surmise that possible sound stuttering issues may have been caused by bus and/or CPU usage spikes, possibly from IDE devices operating in PIO mode, or simply a spoony motherboard chipset. Regardless of this change, please check your IDE devices' DMA settings if you were having problems with stuttering whenever another process triggered a lot of random drive access.