SHOUTcast DSP Plug-in v2.2.3 for Winamp (07/19/2011)

[DrO]

The updated version of the SHOUTcast DSP plug-in has now been released and is available from:

http://www.shoutcast.com/broadcast-tools
(Direct download link -> here)

Note: This updated version of the plug-in will only work on Winamp 5.5 and higher and requires Windows 2000 and higher to work (though the plug-in has only been actively tested on Windows 2000 / XP / Window 7). Additionally, this is a 32-bit dll like Winamp though should run fine on a 64-bit version of Windows.


Summary

This is a recommended update for anyone using the DSP plug-in as it resolves a number of stability issues with the prior 2.x and 1.9x versions and also adds support for SHOUTcast 2 along with a number of other improvements to the experience of using the plug-in with a number of bug fixes as well.


Changes

Changes from v2.2.2

• Fixed title updates to remove characters the v2 DNAS will abort a connection on
• Fixed DSP not starting connections if Winamp is starting minimised
• Fixed the AAC encoder not being re-loaded if closing the dialog and re-opening without re-loading the DSP
• Fixed some rare issues preventing the dialog from loading correctly

Changes from v2.2.1

• Added support for Winamp 5.62's new AAC encoder dll (Winamp now uses Fraunhofer's AAC library instead of Coding Technologies)
• Changed the genre to be chosen from a menu (in supported situations) so only allow supported values
• Changed MP3 default settings to be 96 kbps Stereo (meant to have been this for a while but wasn't working)
• Changed default genre to be 'Misc' on clean installs or on loading and not matching the supported genre list
• Changed the version string so it's more like the v1 tools (and pending DNAS / Transcoder updates)
• Changed 'Description' to 'Name' on the Yellow Pages tab
• Fixed the vu input meters to not show a level if there is currently no audio input instead of keeping the last value
• Fixed issue with loading of the config dialog not showing the tabs correctly in some situations
• Fixed sending a manual title update in v2 mode also incorrectly sending inappropriate cached title data
• Miscellaneous code tidyups, optimisations, removal of unwanted code

Changes from v2.2.0

• Fixed crash on some machines when the playlist editor is empty
• Fixed some minor localisation issues with some of the error messages
• Fixed the installer not setting the DSP as the default DSP for some non-standard installs
• Changed message when loading in an invalid configuration to mention DSP stackers

Changes from v2.1.3

• Added new 'Artwork' tab which allows for configuration of how and what artwork will be sent for SHOUTcast 2 streams to a compatible SHOUTcast 2 DNAS)
• Added support of the IPC_GETNEXTLISTPOS api in Winamp 5.61+ to better determine the next song to be played even if shuffle is enabled
• Added explict blocking of trying to load the plug-in not in Winamp to resolve loading issues and crashes due to lacking api support required
• Added to the logs tab the option to log the next tracks to be played from the DSP in plain txt or in xml format
• Added sending of icypub data as per SHOUTcast 2 protocol specifications (only needed for the SHOUTcast 2 DNAS)
• Added 'lookahead' ini only option for determining how many next tracks from the playback queue (if available) to report (default is 3)
• Changed all of the SHOUTcast 2 packet generation to fix a number of issues like large / invalid packets, being unable to connect, unstable connections
• Changed all of the title gathering to no long poll Winamp but instead query it directly (reduces cpu usage and inproves reliability of metadata gathering)
• Changed all of the plug-in UI to use unicode where possible to improve localisation support
• Changed some of the UI elements to make certain information or errors more obvious (like the 'Cipher Response' message when using the wrong SHOUTcast mode)
• Changed the 'Logging' tab to 'Logs' due to the wider range of options it now provides
• Changed next track logging to be a per-configuration feature instead of being applied globally (as in the previous DSP release)
• Changed to send the full title in the metadata <extension> block for the first (current) title so it follows the SHOUTcast 2 specs
• Changed the 'Send Update' button to not be enabled unless there is a title to send as well as disabling the next title option as applicable
• Changed YellowPages tab to disable options not applicable to SHOUTcast 2 mode and when running as a public server (where the details relating to 'streamauthhash' for the DNAS are used instead)
• Changed to send a default stream id if one is not specified in SHOUTcast 2 mode to improve DJ connection issues (which can fail if not specified)
• Fixed some metadata conversions leading to crashes
• Fixed internal utf8 conversions to prevent malformed SHOUTcast 2 metadata being generated which would cause the SHOUTcast 2 DNAS to block the connection
• Fixed some of the entered stream configuration options to not accept invalid input and revert to safe defaults as applicable if this happens
• Fixed some issues with logging initialisation leading to random lockups in some rare cases
• Fixed memory corruption using SHOUTcast 2 mode preventing 'Connection 1' being used in rare cases (mainly affected Windows 2000 / XP systems)
• Fixed metadata not being sent if the connection to the DNAS is lost and a connection then comes back or is manually started
• Fixed clean up of resources if unloading whilst Winamp is still running to prevent a potential crash on close or UI corruption when the plug-in is loaded again
• Fixed when Winamp is not playing or is paused outputting blank stream data at a higher rate compared to playing leading to higher bandwidth usage then should be happening
• Fixed the Summary page listview flickering on update
• Fixed rare crash when Winamp is not playing and certain playlist configurations are in use when trying to find the next track title
• Fixed to not reset the music levels if not using the soundcard input on closing
• Fixed to not reset the Winamp level if not using the soundcard input on startup but will instead apply it on changing to soundcard input
• Fixed playback queue lookup issues on older 5.5x clients when api_queue is not present or not correctly loaded when queried
• Fixed the 'Send Update' option to not send cached information from Winamp's title and to not crash in rare situations
• Fixed rare lockup issue when using the soundcard input due to the input device taking longer to reset than expected
• Fixed refresh capture device not setting to a valid selection if the number of devices changed
• Updated help link for the plug-in to go to the new page at http://wiki.winamp.com/wiki/Source_DSP_Plug-in
• Updated installer to allow the plug-in to be set as the default DSP as well as run Winamp after completion (with the checked states remembered for next time)
• Miscellaneous code tidyups, optimisations, removal of unwanted code and other build related changes to make this more portable at a later date

Changes from v2.1.1

• Added passing of metadata from the playing track (if known) to the server so it acts like sc_trans from a client connecting to the stream
• Added an option to not log 'Status X bytes' messages (enabled by default) and improved log file handling
• Added a refresh capture device button to help update the plug-in if connected capture devices have changed
• Changed status info duration to be the time connected rather than a relative date time and allows for more than 24hrs to be displayed e.g. 26:48:57 instead of looping back to 03:48:57
• Changed logging to filter 'Status X bytes' messages to only 1 second (if the option to include them is enabled)
• Changed log files to use CR+LF linebreaks instead of just LF
• Changed logging to remove newlines so each message is a single line to match the status info
• Fixed crash on Vista (and potentially Windows 7) where no capture devices are being present resulting in no default capture device known
• Fixed crash in SC2 mode when a different cipher is set in the plug-in to the server as well as indicating this error in the status info
• Fixed button images in the 'Soundcard Mixer Control' section not appearing on all OSes

Changes from v2.1.0

• Added new 'Logging' tab on the Output tab to log the connection status messages
• Added a mini dropdown next to the 'Lock' button for 'Push to Talk' to allow the mode to be automatically enabled on startup
• Fixed plug-in to not crash when the network connection is lost
• Fixed random plug-in crashes whilst the plug-in is streaming (mainly in SC2 mode)
• Fixed internal plug-in uninstall not always working
• Fixed SC2 title updates to properly work as UTF-8 and to not strip out characters incorrectly
• Fixed next track detection to only be reported if shuffle mode is off and not to act in an undefined manner when on the last playlist item (wraps around to the start of the playlist as needed)
• Fixed title updates to cope with the same title being played but the next song title being different
• Changed SC2 metadata to not output <soon> and <title seq="2"> tags in the xml metadata if they are not known (when shuffle mode is enabled)
• Changed the <TENC/> tag in the xml metadata to include the plug-in version

Changes from v2.0.2

• Added a separate capture device fader timeout option
• Added copies of the plug-in documentation as an installer option
• Added help and documentation links to the 'About' tab
• Changed on Vista / Windows 7 to only show actually connected capture devices (requires a restart of the plug-in if connecting a new device whilst the plug-in is active (*))
• Changed the 'Open Mixer' button to open to the recording devices dialog on Vista / Windows 7
• Changed wording of the legacy mode checkbox to be clearer (hopefully) and added an info panel below to deal with the 'Cipher response message'
• Changed capture device level to not alter the device's level unless Push to Talk is active
• Changed the resolution on the faders from 500ms to 100ms (will re-map old settings)
• Changed opening of help links in the plug-in to follow Winamp's style of handling
• Fixed major issue in the plug-in leading to breaking of Winamp (and 3rd party plug-in's) COM usage
• Fixed running of the plug-in not starting auto-connect connections when 'Input' or 'About' were the opened tab
• Fixed capture device level not being correctly handled leading to spiking in on transitions (affected at least Windows 2000 / XP where it is all known to work)
• Fixed capture devices source selection not being remembered
• Fixed capture device and source levels not being set back to the non-Push to Talk level if Push to Talk is active when the plug-in is closed
• Fixed a few localisation issues with missing items on Windows 2000 / XP
• Fixed capture deviceRemoved tooltip from the microphone slider on the line-in page
• Fixed some issues with the installer and uninstaller
• Miscellaneous code changes to make some things easier to manage

(*) There are other changes being made to the plug-ins handling of the Input devices over the next few versions so this behaviour will change again

Changes from v2.0.0

• Fixed SHOUTcast 1 connection errors to a remote connection
• Fixed authorisation error checking for Ultravox 2 & 2.1
• More changes to the output manager to avoid out of sync states
• Fixed timing issue which caused out of sequence Ultravox audio data frames in some scenarios
• Fixed some localisation and tabbing order issues on the config pages
• Removed unwanted encoder option on the Output -> Connection tab
• Added a SHOUTcast 1 mode only information prompt on how to enter the password for DJ connections

Changes from v1.9.1

• Added SHOUTcast 2 (Ultravox 2.1) support for the generated stream data
• Cleanup and general fixes to the streaming support in the plug-in
• Fixed settings not being saved on Vista / Windows 7
• Fixed a number of lock-ups in the plug-in (should be more stable now)
• Fixed plug-in to not stall if Winamp is not playing
• Fixed a number of UI issues (tabs not showing in all cases, controls not in the correct tabbing order, theming issues, notification icon handling)
• Config window now remembers its last position between use
• Improved Lame encoder quality
• Attempted to resolve standard AAC (LC-AAC) not working (additionally this is reported as audio/aacp so it will work with the YP)
• Uses the current enc_aacplus.dll (AAC / AAC+ encoder) from the Winamp install used instead of bundling an old version from Winamp 5.1)
• Fixed SHOUTcast 1 issue with titles containing "[" & "]"
• Changes made to improve selection of the 'microphone' device allowing for more control over the capture device used
• Added localisation support to the plug-in (including supporting localised encoder plug-ins when showing their configurations)
• Some other minor changes including those from the 1.9.2 beta

Reporting Issues

If you do come across an issue with the plug-in, then please do post in this thread with as much information as possible about what you're doing at the time, the system you are using and anything else which will make it easier to understand what is or isn't going on with your install.


Important Notes

1) There are still a few issues regarding the soundcard control features on Vista / Windows 7 due to changes made in these OSes in the way it handles sound and how it can be obtained. This is being investigated though there is no eta on when a resolution will be found.

2) By default on new installs of the plug-in, it will enable support for using the newer SHOUTcast 2 features. However, if you're using an older version of the DNAS (or an alternative which is not compatible with the SHOUTcast 2 protocol) then you will need to check the 'Use SHOUTcast v1 mode (for legacy servers)' on the Output Page -> Connection Tab.

3) This version includes artwork support but requires a newer version of the SHOUTcast DNAS v2 in order to be able to use it. This will be released shortly once a number of other aspects have been completed with the DNAS's development.


Issues

Cipher response received message - If this happens then you most likely are connecting in SHOUTcast 2 mode to a SHOUTcast 1 setup and so need check the 'Use SHOUTcast v1 mode (for legacy servers)' on the Output Page -> Connection Tab. The plug-in will give you a number of hints if this is what you need to do.

Soundcard Mixer Control - On Vista / Windows 7 there are issues with the use of the features with the selected device to act as the 'microphone' where it basically will not work in an expected manner. This is being investigated though is not clear if there will be a solution for this.


Thanks

Big thanks goes to kind people who've helped out from trying new test builds to providing access to systems experiencing weird issues as well as those who reported issues with the DSP whilst trying to resolve the issues with connection stability and other things from the v2.1.3 release.


-daz

[DrO]

For anyone who has used the v2 DSP then they really should consider upgrading to this version as it fixes the known connection and stability issues which have been reported (and been able to be reproduced) so should be a far nicer experience (especially if you've been hanging onto the v1.9.x builds of the DSP due to the stability issues).

Enjoy!

-daz

[SC_faisal]

Solid!

[DrO]

Updated to v2.2.1 which can be downloaded via the direct link (main site will be updated soonish).

This new releases resolves the crash issue reported by MrSinatra and DigiBC (who's posts have been moved to here).

-daz

[DrO]

Main site download link is now active for the v2.2.1 download

-daz

[MrSinatra]

hey DrO,

question: if i run a headless machine with no sound card, can it stream music via the DSP? i haven't loaded the music onto the machine yet, but when i have the DSP up and try to "play" the llama clip, i get a no directsound output error.

do i need to select the DSP as a device somehow?

[thinktink]

For no soundcard use ZeroPointer as the active output plugin.

[MrSinatra]

you're the man TT, that seems to work! but is there a way to do it without a 3rd party plugin? DrO, is that what you would have done? are there other alternatives?

TT, what are the options for in the null plugin? what do they do?

[thinktink]

The options in the plugin are for playback fine-tuning. If you find your stream running too fast or too slow you can tweak the rates. Otherwise just leave 'em at 0.0 and 0.0 (or whatever the install defaults were) respectively.

As far as the 3rd party plugin issue. The closest would be the (if memory serves) official NULL Output Plugin that came with one of the old SHOUTcast DSP installs. I think ZeroPointer is far superior though.

[MrSinatra]

Originally Posted by thinktink

The options in the plugin are for playback fine-tuning. If you find your stream running too fast or too slow you can tweak the rates. Otherwise just leave 'em at 0.0 and 0.0 (or whatever the install defaults were) respectively.

As far as the 3rd party plugin issue. The closest would be the (if memory serves) official NULL Output Plugin that came with one of the old SHOUTcast DSP installs. I think ZeroPointer is far superior though.

that would explain why i don't recall having this issue before. perhaps they should ask you to turn it into "official."

the first option default is 0.0 for playback, but 0.01 for "end song fudge factor." i just don't get what they do?

my next task is to get this working with the new DNAS, but i don't know if i should try to get that going until i have a permanent static IP, and until the auth hash issues are settled. DrO gave me a lot of good info for it, but it seems like a daunting challenge.

[thinktink]

Yup, I just double checked, 0.0 and 0.01 are the normal defaults.

"Song End Fudge Factor" is mainly for input plugins (as of the time ZeroPointer was first constructed) not always sending the same amount of data to DSP plugins as Output plugins thereby causing some data rate flow irregularities in the SC DSP send. 0.01 is based on an average experience with different MP3 files.

For a more in-depth understanding of the data rate (about to get technical~ish):
For machines with a soundcard that Winamp can play to, the soundcard acts as a timer of sorts to control how fast Winamp plays music (and how fast audio data gets pushed through the DSP (or DSP stack if running)). Without that regulation Winamp would just dump the audio data way too fast for the DNAS or anybody trying to listen to your radio station to handle. With no soundcard that inherent regulation is gone. Winamp has to playback to something. ZeroPointer and other NULL output plugins therefore simulate that playback timing. Because not all system clocks are perfect I added this feature to ZeroPointer, again, out of experience dealing with different machines.

Hope this answers your questions.

[DrO]

i'd go with thinktink's option or basically any null output plug-in which is known to be stable / developed (not sure where the out_null source code even is nowadays).

-daz

[IgorPobi]

Hello !

When set SHOUTcast DSP to Soundcard input, how grab metadata ?
Is possible implement HTTP Event Adaptor ? (like Spacialnet Simplecast).
For example: http://localhost:8181/?artist=myarti...uration=240000

Please see: http://support.spacialaudio.com/wiki..._Event_Adaptor

For now, when DSP set to Soundcard input, no possible to grab metadata ...

Thanks !

[DrO]

there's no metadata available when using the soundcard input mode as that's just how that works i.e. its just acquiring what's being passed to the audio output so will never know where the audio is coming from.

so you'd either need to use something else or use the Winamp capture mode and play what you're trying to capture through that which will send title updates as long as the source is changing the title / provides metadata Winamp is able to obtain.

-daz

[MrSinatra]

hope you don't mind if i jump in here, but i was eventually going to ask about this myself.

as you know, at our station we just simulcast the FM, so no title/artist info on the webcasts.

however, the CD players and computer DJ automation systems will output that info as XML or other similar txt-like info. i understand that some middleware or scripts or something would need to translate that output to a winamp/shoutcast standard, but the problem is that neither the DSP nor the DNAS seems to have an "injection point" for 3rd party metadata.

it would be good if as an option/setting, at some point along the way in some piece of shoutcast, a user could say "look every 3 seconds here at this txt file for artist/album/title updates" or something like that.

possible?

[DrO]

its possible to add in something which would be able to do that though i think i'd have to change some of the ui around to be able to have options for doing that - probably moving the 'track title' part on the YellowPages tab (might even change that to just 'YP' or 'Details' ) to a new titles tab and have the options on there to specify a file to read from, etc.

the main thing is really deciding the best way of specifying the format to use if it was to be done since it'd need to cope with v1 and v2 requirements.

-daz

[MrSinatra]

understood. i realize this is something of a project/large request.

so in your mind, its best to just make it part of the DSP? i wasn't sure which would be better, the DSP or DNAS. i was thinking it might be easier to do in the DNAS, but it might be easier for a user to configure in the DSP, and it might also make more sense to try to "sync" the audio/metadata at the DSP as well.

one other (small but important) issue is the idea that a user option to offset the timing of the sync of the metadata fed to it might be needed, as some stations (like mine) use a delay dump, and so the xmtr is behind the output of the machines by X seconds, (usually 7 to 10).

the way we would arrange it would be something like this:

physical relay switches on the board would toggle which "thing" writes to the output file. so if DJ automation is on, that XML output would be written to disk, translated by middleware to the SC standard, and then FTP'd to the webcasts where the DSP (or DNAS) would read it and inject it as the sync'd metadata to the audio in of the soundcard. the DSP would hopefully have a setting to account for timing, which is probably necessary even without a delay loop. all this would be done automatically, as the machines would detect the changes to disk and act.

would be a very cool feature that radio stations would really appreciate.

[DrO]

well there's already the updinfo command in the DNAS so it can already be sort of done with that (which is basically all a v1 title update is anyway). just from an ease of use then doing it in the DSP is the way to go really plus the source is responsible for the titles rather than the DNAS which is basically just there to hold /relay such info.

as for the delay, i was more thinking if it was to be done to either have the check work on a fixed delay or make it check for the file being altered and have that trigger the read and sending of the metadata (though the DSP's metadata sending is delayed until it has free time to process it so it's never going to be exact - related to the cpu usage tweaks in on song changes in v2.2.x).

i guess an additional delay could be added as an option for a custom input.

might try to find some time later today to mock up a gui page of the options to see if my thinking is on the right path.

-daz

[MrSinatra]

no rush on this DrO, i have very little exp with the DJ auto XML output, and it will take me some time to find/pay someone to write the middleware necessary for it, to conform to whatever winamp standard you specify. (OMT Mediatouch makes the software, but i doubt i'll be able to convince them to do it, so we'll probably look for a 3rd party) Also, amazing as this may sound, we're still getting our network in house in order, which we need to do to get the FTP setup.

however i wanted to go into a bit more detail on the physical airchain. basically, the "board" controls what inputs and signal is sent to the xmtr. even if its computer automation, the board must route that signal. (thats how physical relay switches could then control what XML or whatever info is used to send to the DSP). our station is totally digital, meaning that all the equipment and connections are made digitally; the entire airchain, from the computers to the board/cables to the cd players all the way to the xmtr = digital. the xmtr is about a half mile away and the studio sends its signal by fiber optic cable. at the xmtr, the signal only goes analog again as an output of the orban processor which feeds the actual FM xmtr.

back at the studio, we have a digital delay dump which is always on, always part of the airchain, and thats basically just a loop that purposely delays the signal by 7-10 seconds so that a DJ can "dump" any cursing. users can select the time they want the delay to work for. so what you hear on the FM is actually 7 seconds old.

the webcasts work off of the FM, we tune into it. some people think the webcasts should be fed by a pre-xmtr digital feed, but we like it like this so we can 1. get the benefit of the orban processing, and 2. verify via webcast the FM is actually up and running.

however, this means the delay dump puts the webcasts behind too. so the XML created, if sent to the DSP right then, would be 7-10 seconds too early, if you follow me. i think you understood this already, but i just wanted to illustrate all this to make it plain and b/c i thought you'd find it interesting. as far as syncing goes via shoutcast on output, i figured it wouldn't be exact, but probably close enough for our needs.

something else we haven't talked about is RDS systems, where basically the xmtr outputs text that car stereos and the like can use. we don't have RDS (yet), but many stations do, and if the tuner they used to feed their webcasts supported it, i can imagine a scenario where the tuner writes a file via serial port or something like that, for the webcasts of the RDS info. again, just something to be aware of.

thx for the interest!

[DrO]

Originally Posted by DrO

might try to find some time later today to mock up a gui page of the options to see if my thinking is on the right path.

i've attached a quick mockup of the possible options i can think off for things (which doesn't overly complicate the plug-in as something are just a bit too much for the DSP to be doing i think).

-daz

[MrSinatra]

that looks fantastic!

[DrO]

that's good to know i was thinking on the right lines then i've logged it though cannot say when it'll be done as really after the coming DNAS updates, the Transcoder needs the most attention to bring it up to the newer v2 protocol specs, etc (which the DSP already has been updated to support).

-daz

[MrSinatra]

one small thing...

i notice with 2.2.1 that sometimes the levels get stuck green in the dsp on the summary and input tabs after winamp was stopped. interestingly, the amount they are, is in disagreement between the two tabs.

[DrO]

if there's no input then the levels can do that since they're based on looking at what's going through the buffers (though maybe they should be reset to nothing in that scenario).

the difference between the two views is due to timing differences between one dialog page and the other being able to process what is going on. however i think that can probably be changed to lessen the difference (though is less important than the custom metadata feature to work on ).

-daz

[MrSinatra]

agreed on all counts, just wanted to document it.

[DrO]

actually i've fixed it already for when there's another release (was waiting on something else and it was a quick fix) so the levels will go to -Inf as soon as there's no audio data received.

-daz

[ones]

And something new about new version with title send on txt?

[DrO]

ones: there's nothing been done towards that feature at the moment, what has been talked about / shown in the previous few posts is just a potential proposal for what could (but not necessarily will happen). especially as i've not worked out what's going to be the best way for doing the title input so it will work with v1 or v2 streams as appropriate.

-daz

[ones]

Daz you cannot publicate some "non official version" with that? You doing that or this doing people from shoutcast? I mean someone who do that.

[DrO]

what i posted was a mock-up of what i might create as part of working on the DSP in an official capacity. so basically it's down to me to work out how it'll be done and when i allocate time to work on it (in-between working on the rest of the SHOUTcast tools / site).

-daz

[ones]

Okey we will be waiting for this!

[DrO]

Updated to v2.2.2 which can now be downloaded via the direct link or from the main site.

This new releases is in conjunction with the Winamp 5.62 release due to changes in the AAC encoder library used with this newer Winamp release. It also fixes a few other issues and tweaks the genre handling to ensure valid genres are used (when applicable).

-daz

[MrSinatra]

cool, will install later tonight.

[MrSinatra]

sweet. the FM is on the new stuff.

i don't know if its b/c of what i did or not, but i can now use lite to do AAC streams, which is awesome. i DL'd the full installer, set it to lite, and then made some changes so it went to custom. i made sure it had the mp3 and aac encoder, but maybe that wasn't necessary?

anyway, its cool to be able to do AAC on lite, which i couldn't before!

[DrO]

by default lite doesn't have the aac encoder, running the full installer and making a custom install is the only real way to do it for a lite / custom setup (as you've found).

-daz

[DrO]

Updated to v2.2.3 which can now be downloaded via the direct link (main site will follow).

This new release fixes a few bugs which have been reported since the prior release and hopefully will resolve some of the last few issues which are present (excluding what is known).

Now to see if we can have an update for all of the tools in the same week (just missing a Transcoder update...).

-daz

[MrSinatra]

using 2.2.3 on the FM, working great!

feature request:

[mainly] when using the soundcard input, one would like to see what the peak levels were over the last 5 minutes or so at least.

the reason is that in most cases a soundcard will be fed analog, and the gain is knob adjusted [in my case, using a pro quality distribution amp] prior to entering the soundcard, (although this can be done digitally as well, its just a digital attenuation in that case).

regardless of how its done, the point is that for soundcard input, you want to set your equipment to get as close to 0 as possible, without actually reaching it, and peak level history would be useful in getting settings straight. (it actually could be useful with local mp3 files as well, when setting the replay gain pre-amp, so this feature applies there as well)

could a peak level history tab be created showing the highest peak level achieved over a given length of time? say the last 1 minute, 2 minutes, 5 minutes, hour, day, week, month?

thx!

[thinktink]

Originally Posted by MrSinatra

...could a peak level history tab be created showing the highest peak level achieved over a given length of time? say the last 1 minute, 2 minutes, 5 minutes, hour, day, week, month?

That would probably be best done with an external app if one exists. That's alot of data to try to store and maintain for an extended period of time.

[MrSinatra]

i thought computers were good at this kind of logging?

there must be some kind of way to do something like this, thats still useful?

something thats different, but has its use, would be "peak fall offs." some spectrum analyzers do this, (i think even winamp can do it), where only a peak is held for a split second, then falls off, rather than just pure, and hard to follow, real time display. since the dsp has a couple of tabs where the input level is shown, maybe one of them could use the peak fall off method? that would at least help in eyeballing the levels when adjusting the knobs at that moment, although it would not give a history beyond the moment.

EDIT: how about a new tab that did peak fall offs, and all it did was record the highest peak since the DSP was connected to the DNAS, so in that way it didn't have to take time intervals into account? not as good, but plenty useful nonetheless.

[DrO]

i'm really not sure having full peak monitoring (i.e. another tab) in the DSP is really suitable for what the DSP is intended for. as adding in more complex logging over a variable timescale is more of a pro-tool feature i'd have thought.

Winamp does have such a feature and that just keeps a track over a few seconds at most. it also has the advantage of drawing the vu itself instead of re-using a Windows progress bar control for the vu (as the DSP does) which doesn't really allow for such a ui state (not without going the custom drawing route). i'm not sure from development time if implementing a custom control for that would be worth it.

the only obvious option (if this was to be done) would be to show it with the current level either to the side or below like in the attached screenshot (ignoring my lame copy+paste work), just then leaves what timescale to cover it for (just peak since starting is the simplest, though it's not too hard to have it track the levels over a single time period).

-daz