SHOUTcast DSP Plug-in v2.3.2 for Winamp (11/06/2012)

[DrO]

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

(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.3.1

• Fixed all reproduceable issues when switching between Winamp and Soundcard mode as well as switching between the different soundcard input modes (should fix all reported crashes when switching between these modes)
• Fixed soundcard input not being initialised correctly in all of the previous v2.3.x releases
• Fixed the 'connect' button getting disabled when switching from the 'summary' to the 'output' tab
• Fixed crash when playlist was cleared and Winamp was in a specific playback state leading to information could not be properly handled
• Updated list of station names not allows for being listed in the Directory
• Updated albumart support to get the raw playing artwork instead of the decoded artwork and having to re-encode to png when using Winamp v5.6+ (still happens on pre-5.6 or if there is an external artwork file due to the Winamp artwork api)

Changes from v2.3.0

• Added logging of the metadata and artwork details obtained from Winamp before sent to the server (if logging it enabled)
• Fixed some connection stability issues when connecting to a remote server (typically happens when in-stream artwork is enabled)
• Fixed large metadata updates (typically in-stream artwork but also could affect title updates) not sending all frames to the server
• Fixed some rare lockups when sending metadata frames to the server
• Fixed the 'kill' action not working or responding as expected in certain scenarios
• Changed the 'Directory' tab to enable Name, Url and Genre options when using v2 mode and the stream is set to be public
• Changed toggling of the in-stream artwork options to refresh the cached artwork copy when re-enabled
• Changed log messages to filter out excessive "Cipher Response Received" messages and changed to show "Unable To Connect To The Server. Try enabling 'SHOUTcast v1 mode'." if stuck at that state
• Removed the "Ignore 'Sent X bytes' status messages" option from the logging tab (should have been removed in v2.3.0)

Changes from v2.2.3

• Added a number of stream configuration details onto the summary view to see what each stream is configured for without having to go to the 'output' tab
• Added clickable buttons on the summary listview to allow for quick control of the streams
• Added toggling of the stream playing state in the summary listview view via the space key
• Added support for saving the encoded stream output to a specified file to allow DJ's to keep a copy of their output
• Added options for toggling between Winamp and Soundcard mode on the summary page
• Added tooltips to the summary listview so any clipped text can be seen
• Added peak level indication since the DSP was started for left and right
• Added visual info on the artwork page if artwork will be sent or not
• Added better checking of entered values to ensure only what is supported can be entered e.g. port range limit from 1-65535
• Added better handling of NAK errors from the DNAS in v1 and v2 mode as well as required updates from v2 protocol changes e.g. for 'Bit Rate Error' and 'Stream Moved' responses
• Added 'red' tab text to indicate the tab which has missing or invalid information which prevents a connection from starting
• Added some details of the connection in the logs to make it easier to see the details
• Added handling to remember custom titles between Winamp instances
• Changed all of the known genres to support all changes made to the official genre list at the time of release including the adding of new genres (Decades -> 00s, Folk -> Old Time, International -> German) and changing some (Jewish to Hebrew or removing any dashes)
• Changed some of the output sub-tab names to make things more consistent
• Changed 'user id' to be able to accept the DJ name when used in v1 mode so it will automatically convert it to the 'name : password' format as used with v1 Transcoder DJ connections
• Changed the title options to be on their own page with some layout changes
• Changed a failed connection to now wait up to a second before trying again to prevent hammering the server
• Changed '[xx:xx:xx] Sent xxx bytes' to now scale from bytes to KiB to MiB to GiB
• Changed in-stream metadata (titles and artwork) to be included in the v2 stream bytes sent total shown
• Changed paused / stopped silence filling to keep the output bitrate the same as playing now without the prior hacks
• Changed the 'online documentation' link to open a local copy if available
• Changed the GUID for the plug-in's language file to now be {88380E65-4068-49BA-8EA4-3F2AF12D0A4F} due to the large number of resource changes from the previous releases
• Changed user-agent for v1 title updates to match with the v2 metadata's TENC field version (is now "SHOUTcast Source DSP x.x.xx Title Update (Mozilla)")
• Changed to use Lame 3.99.5 (lame_enc.dll) or the most current version shipped with Winamp (makes it easier to update without a custom built lamedll.dll as previously used)
• Changed the 'connect' button to show 'set password' or 'change name' or 'set encoder' or 'set server' when disabled to make it clearer why it's not enabled e.g. if 'unnamed server' or nothing is set for the station name or password fields
• Changed default page to be the output page instead of summary on new installs
• Changed encoder default to be AAC+ if possible (so it's one less thing to do on loading) and fixed MP3 to default to 96kbps stereo on clean installs
• Changed how the dialog is loaded to resolve a part close / crash seen in a few rare cases
• Changed the waveInReset(..) change from 2.1.3 back to the pre-2.1.3 behaviour to see if it resolves some of the crash issues reported since the change
• Fixed a small audio loss / silence injection when a stream starts or when a title update happens
• Fixed the title cache update to only send an update if there is an actual change (filters out quirks with streaming from another stream)
• Fixed 'invalid password' scenarios not being correctly reported
• Fixed stream artwork not being correctly updated after being set to an invalid / empty file
• Fixed unusually large cipherkeys causing a crash when attempting to connect to the server
• Fixed v2 mode doubling up the sent bytes total in some specific scenarios
• Fixed memory leak when processing the playing album art due to not always removing the original image
• Fixed a disconnect-connect or re-connect scenario incorrectly trying to re-send the stream artwork when not present / not enabled
• Fixed metadata packet creation some times going over the 16384 byte limit (16371 byte payload limit)
• Fixed artwork cleared updates being sent when not applicable
• Fixed playing state not being correctly detected if Winamp was already playing when the DSP is loaded
• Fixed issue causing sparodic injection of invalid data into the output buffer for encoding
• Fixed artwork not being correctly sent after a disconnect in some scenarios
• Fixed random crash when updating the next playing song information
• Fixed excessive updating of the controls on the output page
• Fixed MP3 encoder not showing all encoding options when in Winamp mode under some incorrectly inherited settings
• Fixed v1 metadata updates potentially causing a one handle leak for each title update
• Fixed manual titles not being sent in all cases
• Fixed next titles being sent even if option is unchecked
• Removed dsp_sc_enc.ini usage with all temporary encoder settings now stored in dsp_sc.ini
• Removed default values for userid and password to force a valid value to be entered
• Miscellaneous code tidyups, optimisations, removal of unwanted code, resource changes and other related changes to improve useability of the plug-in

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 other than it is intended for there to be some attempt at a fix in v2.4.0

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 / Windows 8 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 which also affects the 'Push To Talk' (PTT) feature. This is being investigated though is not clear if there will be a solution for this.

Soundcard Input Gives No Stream Audio - Streaming using the 'soundcard input' does not work correctly in all v2.3.x builds. This is being investigated and a fix will come in the next few weeks. If using this mode is all you use then you will have to install the older v2.2.3 release until the issue is resolved. This is fixed for the next public release due out the week commencing 5th November 2012.


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 previous v2.x releases.


Discussion about the previous version of the server including changelogs can be found in the following threads

• Source DSP v2.0.0 to v2.2.3

-daz

[MrSinatra]

cool, massive development of the DSP.

i read the post, but does any of it apply to being able to feed the DSP metadata info provided by an external source for a soundcard in feed? (like a txt file?)

[DrO]

nope, there has not been anything done towards that as need to find the time and also sort out the best way to handle the file (from how it's specified, etc as i think was covered in the previous release thread).

-daz

[MrSinatra]

Originally Posted by DrO

nope, there has not been anything done towards that as need to find the time and also sort out the best way to handle the file (from how it's specified, etc as i think was covered in the previous release thread).

-daz

np, just didn't know if i was unaware of any terminology. clearly this is a worthy release, heavy on bug crushing but not without useful new features.

[DrO]

we shall see with time if this release resolves things as it should
and now to start updating the wiki versions of the documentation *joy*

-daz

[thinktink]

Nailed it!

[DrO]

v2.3.1 will be coming early next week to resolve some further stability issues in v2 mode with in-stream artwork (or large metadata) updates being sent not working as expected or causing the connection to drop.

-daz

[MrSinatra]

hey DrO,

i had an idea, and it may very well be a terrible idea, so i leave that to you, but i thought it might be useful for troubleshooting.

could a second status tab be added to the dsp, whose funtion would be to merely display the metadata currently being sent? so like the actual title, artist, AA, album name, and artwork, along with the specs of the artwork, namely resolution and filesize?

something like that would at the very least show that the data is reaching the DSP, and if something isn't working, its AFTER the DSP. (like, for normal users trying to troubleshoot). for you, it would show you what exact art might be causing a problem.

i think it would just be "cool" besides!

just floating it out there, i know you got a full plate. (maybe thinktink would want to do it?? eh eh, nudge nudge)

[DrO]

the DSP already shows if it's sending artwork or not and the effective file size of the artwork on the artwork tab (ignoring the bug in it not sending all of the frames).

i might consider adding logging of metadata updates to the log but i'm not sure it's really appropriate with the rest of the ui when Winamp is already showing or can be setup to show all of that.

-daz

[DJ_MELERIX]

I've updated to 2.3.0, and I noticed it have several issues.

for example I can't stream anymore with this version, when I click in "connect" button, it start sending bytes but really really slow.

other important issues are with the GUI, sometimes borders and boxes for texts are not visible, or disappear randomly.

or for example when you try to configure AAC encoding options, the config window is empty.

sadly I had to return to 2.2.3.

[DrO]

it is already mentioned a few posts up that there is a connection stability issue when using v2 mode.

Winamp version?
OS?
what protocol version?
Using a language pack?
any actually useful information about your setup (as per the first post) ?

-daz

[DJ_MELERIX]

Winamp version: Winamp 5.63
OS: Windows XP Professional SP3 (updated)
Protocol version: Shoutcast v2
Languaje pack: Winamp 5.63 in Spanish

My Setup...
CPU: AMD Sempron 2400+ Socket A (1.667ghz).
Video: Nvidia Geforce FX5200 AGPX 8x 256MB DDR 128bits.
Sound: Sound Blaster Audigy SE PCI.
Ram: 1.5GB DDR.

[DrO]

try Winamp under the English language pack for the UI issue to see if that persists

as for the slow sending of bytes, if it's only for the first few seconds (your description is not clear) then that is expected when in v2 mode when it's doing all of the handshaking needed and the previous version did the same thing.

-daz

[DJ_MELERIX]

confirmed, with English language the GUI is ok, and encoding options window is working fine again.

about "slow sending of bytes" seems the issue is something with the config, because now a made a clean install of the plugin, deleting the old config and now is ok.

so may be is some incompatibility that only happens when the config from 2.2.3 still exist.

[DrO]

do you still have a copy of the config file which exhibited the issue? if so can you pm me the contents of the file please.

-daz

[retrax57]

Hello Dro.
I thinks confirmed, with English language the GUI is very good, and encoding options window is working fine again .
-----------------
Have fun with friv

[DJ_MELERIX]

Originally Posted by DrO

do you still have a copy of the config file which exhibited the issue? if so can you pm me the contents of the file please.

-daz

here are the configs

this one cause the issue: http://pastebin.com/q5sT8gms

this one works fine: http://pastebin.com/TtMFULzV

also other issue I noticed is the following:

[DrO]

from a quick look at the configs, the main difference i see is the original is set to capture the soundcard input and the new one isn't. if it was set to soundcard input, then if not much audio is coming through then the sent bytes count would increase slowly.


with the screenshot, that is expected (though i think i need to change that behaviour) as when the listing is public and using the v2 mode (default) then the settings you enter are effectively ignored since the DNAS will use what is set from the authhash.

however with a bit more thought, if the v2 DNAS is going to automatically use the details from the source (be it in v1 or v2 mode), it makes more sense to allow those to be edited (even if they then end up being ignored) so i'll change that in the 2.3.1 that'll be coming out hopefully later today (probably should have made that change in 2.3.0 but didn't for some reason).

and 'unnamed server' (along with a number of other names) is not allowed as it's too generic a title which is why the DSP requires it to be changed before it'll allow a connection - too many people just leave things at the default values or pick something which is far too generic to allow the station to be found.

-daz

[DrO]

the direct link in the first post has now been updated for v2.3.1 (main site will be updated later).

-daz

[MrSinatra]

hey DrO,

some comments for you to use however you like. this thing is so much better since a year or two ago, its nice to see it develop.

i installed it on my laptop to test it, no server. when it started it was "behind" winamp, and i had to un-max winamp and move it to see it. not sure what u can do about that.

is there a way to log ONLY the artwork that ISN'T sent to server b/c its too big?

also, i think its unrealistic to think most artwork is that small. is the limit ~50KB or so? can't the dsp downsize if necessary?

does the "branding" artwork get sent if the now playing art is too big or missing?

the mp3 encoder says 3.99 not 3.99.5, could this be specified?

could skype be added? msn?

also, getting back to my earlier post, i think i misunderstand you. where in the DSP do you see the currently playing art or metadata? i think it might be a cool addition to say the "input" tab. i know you think its redundant since its in the winamp player, but this is an instant visual way to see what the dsp says its getting (in real time) and what should be seen / heard on server. and winamp could be in windowshade mode, lite, have title updates disabled, etc... also, it might be an idea to allow the dsp to remain visible even when winamp is minimized, altho i think both states behavior should be allowed by pref, (and maybe an always on top option?)

still playing with it...

[DrO]

Originally Posted by MrSinatra

i installed it on my laptop to test it, no server. when it started it was "behind" winamp, and i had to un-max winamp and move it to see it. not sure what u can do about that.

that's down to the loading order of things. the DSP's window is already on a part delay before it shows to resolve other issues. not having it placed where it overlaps the Winamp windows is all i can suggest.

Originally Posted by MrSinatra

is there a way to log ONLY the artwork that ISN'T sent to server b/c its too big?

not without adding complexity to things and i don't think that's appropriate. sorry but it's going to be an all or nothing.

Originally Posted by MrSinatra

also, i think its unrealistic to think most artwork is that small. is the limit ~50KB or so? can't the dsp downsize if necessary?

the limit is 523872 bytes (aka 32 raw Ultravox 2.1 metadata frames which allow up to 16371 bytes) for the image data (however it is encoded or not) and it's getting the artwork from Winamp so it's down to how it's a) stored in the files and b) if Winamp is able to provide it.

Originally Posted by MrSinatra

does the "branding" artwork get sent if the now playing art is too big or missing?

it gets sent if enabled (and if it's within the size limit mentioned) irrespective of the playing being enabled to send and / or being able to be sent.

Originally Posted by MrSinatra

the mp3 encoder says 3.99 not 3.99.5, could this be specified?

lame_enc.dll doesn't provide that information. it's the same thing as you'll see on the CD ripping pages in Winamp.

Originally Posted by MrSinatra

could skype be added? msn?

if you mean like the AIM, IRC, ICQ legacy fields then no. the 'DJ / User ID' can be re-purposed for such things (though it requires a newer DNAS to be accessible outside of being used for sc_trans DJ connections) but none of those options are used by the Directory anymore so are deemed as legacy options.

Originally Posted by MrSinatra

also, getting back to my earlier post, i think i misunderstand you. where in the DSP do you see the currently playing art or metadata?

http://wiki.winamp.com/wiki/Image:Ou...v2_enabled.png which shows one of the possible output messages to see what is / isn't happening with the artwork.

Originally Posted by MrSinatra

i think it might be a cool addition to say the "input" tab. i know you think its redundant since its in the winamp player, but this is an instant visual way to see what the dsp says its getting and what should be seen / heard on server. and winamp could be in windowshade mode, lite, have title updates disabled, etc...

the Input tab is already fully used and metadata doesn't belong on there. i see what you're asking and why you're asking but at the moment, i just don't believe it warrants the work to add something like that in especially when it's not something that would fit in with the rest of things and with it being able to vary over each connection, it would have to somehow be cobbled onto the output tab which would just over-clutter the UI. i have made a note of it incase i can think of a clean way to do it without making it look horrible, but i'm not currently convinced of the benefit.

Originally Posted by MrSinatra

also, it might be an idea to allow the dsp to remain visible even when winamp is minimized, altho i think both states behavior should be allowed by pref.

may look into it but i can see it being a problem as the DSP's window is an associated child of Winamp and minimising Winamp will generally do the same for all of it's child windows.

-daz

[MrSinatra]

wow, i did not do good on that post!

i'll try to reply to just the bits necessary:

Originally Posted by DrO

not without adding complexity to things and i don't think that's appropriate. sorry but it's going to be an all or nothing.

i'm not an expert on logs... will it report failures due to size in the log, and can it be sorted, like if the log is xml or something?

Originally Posted by DrO

the limit is 523872 bytes (aka 32 raw Ultravox 2.1 metadata frames which allow up to 16371 bytes) for the image data (however it is encoded or not) and it's getting the artwork from Winamp so it's down to how it's a) stored in the files and b) if Winamp is able to provide it.

i don't follow that answer at all, but attached is a file windows explorer reports as 38.9KB

when i play it in winamp, the DSP says:

playing artwork: 498.59KiB

the DSP also says the limit is: 511KiB

so basically a small file is reported as approaching the limit. is this accurate?

this is problematic as i think a lot of people will have art that crosses this line.

i can't tell if the limit is supposed to be 500KB or 50KB or what?

also, if everything is converted to png, why not resize too when necessary?

Originally Posted by DrO

it gets sent if enabled (and if it's within the size limit mentioned) irrespective of the playing being enabled to send and / or being able to be sent.

so its always sent, and if the "now playing" art is missing or too big, its there... is that correct?

Originally Posted by DrO

http://wiki.winamp.com/wiki/Image:Ou...v2_enabled.png which shows one of the possible output messages to see what is / isn't happening with the artwork.

i'm not sure if we misunderstand each other, or if i'm doing something wrong, but i see art options there, no actual artwork when i play stuff?

Originally Posted by DrO

the Input tab is already fully used and metadata doesn't belong on there.

the input tab is mostly empty? (the summary tab is full) if the input from the audio belongs there, why not the input of metadata / art? its ok with me if you think it doesn't, i'm just asking?

Originally Posted by DrO

i see what you're asking and why you're asking but at the moment, i just don't believe it warrants the work to add something like that in especially when it's not something that would fit in with the rest of things and with it being able to vary over each connection, it would have to somehow be cobbled onto the output tab which would just over-clutter the UI. i have made a note of it incase i can think of a clean way to do it without making it look horrible, but i'm not currently convinced of the benefit.

i don't think it has to be on the output. its an interesting point though, in that you could make the case that metadata/art for diagnostic purposes need to be seen on both an input and output tab, to be sure its making it all the way thru the dsp. however, i can feel your exasperation and agree thats overkill. to me, just adding to the input tab would be enough, and the user could just assume at that point it was then reaching the output of the dsp, and could go to logging if there was a need to check output.

Originally Posted by DrO

may look into it but i can see it being a problem as the DSP's window is an associated child of Winamp and minimising Winamp will generally do the same for all of it's child windows.

maybe a toggle for the dsp "always on top"?

i hope this back n forth is useful to you.

[DrO]

Originally Posted by MrSinatra

i'm not an expert on logs... will it report failures due to size in the log, and can it be sorted, like if the log is xml or something?

it just shows either the size or a cleared message if the artwork is over size / not available - i'll have to change that in a later release to distinguish between the two. the log is just a sequential text file of what was shown in the status area (ignoring the sent bytes messages) and some additional aspects about the connection. so it's not xml but it'd be easy enough to do a search of the log to find things. though the logging is not meant to be left enabled all of the time ans is just really for diagnostic issues (which was more important in the earlier 2.x builds when things weren't too stable).

Originally Posted by MrSinatra

i don't follow that answer at all, but attached is a file windows explorer reports as 38.9KB

when i play it in winamp, the DSP says:

playing artwork: 498.59KiB

the DSP also says the limit is: 511KiB

so basically a small file is reported as approaching the limit. is this accurate?

this is problematic as i think a lot of people will have art that crosses this line.

it is accurate with how the playing artwork has been provided to the DSP. the issue is between the raw image and the decoded image and due to how things work at the moment the playing artwork is not always going to match with the size of the raw artwork (either in the file or the tag) since the DSP gets provided with the fully loaded version of the image (i.e. the actual bits once the file has been processed so it can then be displayed - think of it as a bitmap file).

however the DSP then has to tell Winamp to re-encode things back to png and unfortunately that doesn't make for a 1:1 especially when the input is a jpeg, which is why in your example it is so close to the limit (as jpeg -> png doesn't work too well). and as there is no way for the DSP to know the original format of the artwork, png was choosen as the default since in most of the test cases it was appropriate.


whereas setting that same file as the branding image will generally show it is ~40KiB as that uses a different method to get the image since it's doing it external of the Winamp artwork api and so it can just get the raw image data without having to re-encode it back as has to happen with the playing artwork.

i bet that isn't going to make much sense or more questions of why not get the raw artwork and it's basically the Winamp api doesn't allow for that since it was only really intended for getting and displaying (like in the library views).

Originally Posted by MrSinatra

i can't tell if the limit is supposed to be 500KB or 50KB or what?

the limit is ~511KiB and it's of the actual data the DSP gets be it from the external artwork file or from Winamp's artwork API (and any conversion which may have to be done). it's not the final decoded artwork (so the raw bits like with a bitmap). and that limit is a fundamental limit in the v2 protocol. as mentioned above, the confusion is that branding and playing are obtained in different ways.

Originally Posted by MrSinatra

also, if everything is converted to png, why not resize too when necessary?

the DSP is just using what Winamp is providing it after the steps already mentioned. i can see this seemingly being confusing but it's how things are / were when i first started to add the feature in.

though it seems i probably need to re-review the handling and i've a feeling i'm going to have to end up changing some of the behaviour in Winamp or see if there is an existing API which i'm not aware off that will allow to just get the raw artwork data as well as the type so sending playing artwork as png can be removed (like is done with the stream artwork). though as nothing is able to use the artwork, i'm probably going to have to do at least one more DSP update anyway to resolve any final issues between it and any revisions that may still be needed in the v2 DNAS with the artwork support.

Originally Posted by MrSinatra

so its always sent, and if the "now playing" art is missing or too big, its there... is that correct?

if it can be sent then it will be and one not being present or over size does not affect another.

Originally Posted by MrSinatra

i'm not sure if we misunderstand each other, or if i'm doing something wrong, but i see art options there, no actual artwork when i play stuff?

confusion on both sides it seems. there is no display of the actual artwork, all that is shown is what is on that page as a text only indicator.

Originally Posted by MrSinatra

the input tab is mostly empty? (the summary tab is full) if the input from the audio belongs there, why not the input of metadata / art? its ok with me if you think it doesn't, i'm just asking?

i don't think it has to be on the output. its an interesting point though, in that you could make the case that metadata/art for diagnostic purposes need to be seen on both an input and output tab, to be sure its making it all the way thru the dsp. however, i can feel your exasperation and agree thats overkill. to me, just adding to the input tab would be enough, and the user could just assume at that point it was then reaching the output of the dsp, and could go to logging if there was a need to check output.

after having a think on my walk, it suppose it does make sense (if it were to be implemented) to have it as a inner panel like is done with the soundcard options on the input tab like the attached mockup - i assume that is what you're meaning?

-daz

[DrO]

looks like there was an addition to the album art API around the Winamp 5.6 release that i wasn't aware off which may allow for getting the raw playing artwork without me having to implement anything new - just need to test it out to see if it's appropriate...

-daz

[MrSinatra]

DrO,

i very much appreciate the serious consideration and the indepth replies. i think if i were to keep "following up" i would only be taxing progress. the sense i have is that you are going to do what you can, which is all i ask, and it seems like the best thing for me to do now, is wait to see what all revisions you make on this going forward in the next dsp and how it looks in winamp once the client can actually display the art.

i really like the mockup for the input tab, thats basically what i was asking for on that score. i think thats useful for instant visual troubleshooting, as well as checking lag and so on. also, unless the dsp is somehow borked, i think its safe to say re: the metadata and art, that if it is there, it reflects both the input and the output of the dsp.

Originally Posted by DrO

looks like there was an addition to the album art API around the Winamp 5.6 release that i wasn't aware off which may allow for getting the raw artwork without me having to implement anything new - just need to test it out to see if it's appropriate.

that sounds positive. i am hoping for a ceiling of ~150KB or so for jpegs, or at least 100KB. i am kind of surprised png was seen as the obvious default, since windows and winamp always used jpg for folder art, as does WMP, EAC, and just about everything i've ever used.

i'll be curious to see if you find out anything interesting about the artwork api outside of the dsp issues.

[DrO]

Originally Posted by MrSinatra

i really like the mockup for the input tab, thats basically what i was asking for on that score. i think thats useful for instant visual troubleshooting, as well as checking lag and so on. also, unless the dsp is somehow borked, i think its safe to say re: the metadata and art, that if it is there, it reflects both the input and the output of the dsp.

will see what happens in coming releases.

Originally Posted by MrSinatra

that sounds positive. i am hoping for a ceiling of ~150KB or so for jpegs, or at least 100KB.

just had a quick try and the newer part of the api i've found works ok if the artwork is in-tag, if it's an external file e.g. folder.jpg then the existing behaviour is going to have to be used unless i make some changes to Winamp (which then would only be present with newer Winamp's).

Originally Posted by MrSinatra

i am kind of surprised png was seen as the obvious default, since windows and winamp always used jpg for folder art, as does WMP, EAC, and just about everything i've ever used.

as for why png over jpg, because re-processing a jpg leads to further loss of the visual data (just like transcoding an mp3 again) and i didn't think that was appropriate to do along with the only native image writers in all supported Winamp versions being png, bmp and jpg, out of the 3 png was the lesser evil of them.

-daz

[MrSinatra]

Originally Posted by DrO

just had a quick try and the newer part of the api i've found works ok if the artwork is in-tag, if it's an external file e.g. folder.jpg then the existing behaviour is going to have to be used unless i make some changes to Winamp (which then would only be present with newer Winamp's).

i hope you can/will do that, b/c i will never embed art for lots of reasons.

seems odd that the existing handling of in-tag/external file would be so different?

Originally Posted by DrO

as for why png over jpg, because re-processing a jpg leads to further loss of the visual data (just like transcoding an mp3 again) and i didn't think that was appropriate to do along with the only native image writers in all supported Winamp versions being png, bmp and jpg, out of the 3 png was the lesser evil of them.

not sure i understand this, but hopefully the first part above, if all implemented, renders it moot to me.

it is important to the discussion imo, that winamp doesn't itself embed.

[DrO]

Originally Posted by MrSinatra

seems odd that the existing handling of in-tag/external file would be so different?

[edited post]
would help if i was properly awake, i didn't see the code correctly and it does get the raw data from the external artwork files once it's tried to get it from the file's tag. just means i need to finish going through to make sure that it won't crash / do anything weird though i won't release an updated DSP with these changes until i've seen how things go with the 2.3.1 release.

-daz

[MrSinatra]

i'm just glad you're pounding away at it. i'm sure you'll get it all straight.

assuming the api will work as you hope it to, what is ~ the max filesize jpg you think one could successfully feed the dsp? (i'm talking filesize as reported by windows explorer?)

[DrO]

Originally Posted by MrSinatra

what is ~ the max filesize jpg you think one could successfully feed the dsp? (i'm talking filesize as reported by windows explorer?)

the artwork handling in the DSP doesn't care about the level of encoding of the format, it is purely based on the size of the data to be transmitted from it to the server.

so whether you have a jpeg re-encoded to png or the raw jpeg file from the file's tag or from an external file, 523872 bytes is always going to be the maximum size allowed for any artwork sent.

so for your external artwork files, what is reported for Explorer is what the DSP would eventually be using as the size of the artwork to be sent.

-daz

[MrSinatra]

Originally Posted by DrO

the artwork handling in the DSP doesn't care about the level of encoding of the format, it is purely based on the size of the data to be transmitted from it to the server.

so whether you have a jpeg re-encoded to png or the raw jpeg file from the file's tag or from an external file, 523872 bytes is always going to be the maximum size allowed for any artwork sent.

so for your external artwork files, what is reported for Explorer is what the DSP would eventually be using as the size of the artwork to be sent.

-daz

ok, and 523872 bytes = 523KB, right? b/c that would be more than enough for most people's art i'd imagine, certainly would be good enough for me.

[DrO]

something like that, depends if you're using 1000 or 1024 as the factor. the DSP uses 1024 hence 523872 bytes = 511.59KiB (though 523KB is correct is using a 1000 factor).

-daz

[A-tone]

"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 other than it is intended for there to be some attempt at a fix in v2.4.0"

I just upgraded my SHOUTcast DSP Plug-in to v2.3.1 and upgraded the server to v2 on my Windows 7 system. Now, I don't have any sound, although the other data appears to be coming through fine. Is the above quote the reason why my station has no sound? If so, is there any new info regarding the issue? Otherwise, it appears I need to go back to my legacy server, source and plug-in settings.

[DrO]

Now, I don't have any sound, although the other data appears to be coming through fine.

i have no idea as to why as i don't know what you were using beforehand (though the DNAS has _nothing_ to do with the part you quoted). all i know is on Vista / Windows 7 that trying to use the soundcard with a mic / line-in and have it play over the Winamp input (as was the way it still seems to work on XP and earlier) is the issue.

also you really need to clarify what you mean by the part i've quoted as either i'm too sleepy or it's just not making sense what you mean by 'other data'.


to my knowledge, capturing from the soundcard on the selected device should be working though maybe you need to re-select the options on the page as there was some incorrect linking of the soundcard handling to Winamp only handling which was changed between 2.2x and 2.3x and that might be causing things not not appear to work, etc.

-daz

[NewTechMatt]

I seem to be having an issue with the ability to send audio via the DSP from my soundcard input.

When the winamp input is selected, the byte count being sent to the server is correct, however when selecting the soundcard input, even with audio being captured via the level meters, I'm only sending approx 1/5th the data at the same bitrate.

Users who are listening to the stream constantly buffer, because my DSP isn't sending data to the server fast enough.

I've confirmed this via 3 different machines running patched windows 7 installations.

Any idea what's causing this? I can screen cap a movie if required.

Thanks,
Matt

[DrO]

2 other people have reported issues with the soundcard mode and with you, it now seems like there is a real problem. alas there's little i can do about it at the moment so all i can suggest is if soundcard input is how you use the Source DSP then you'd need to revert to v2.2.3 until a fix for the v2.3.x comes out (will likely be a few weeks before a fix is out).

-daz

[DJ_MELERIX]

btw, how we can set different "stereo types" for AAC Encoder now ?

I don't see options to set for example: Mono, Stereo, Parametric Stereo, Dual Stereo and others.

[DJ_MELERIX]

Originally Posted by NewTechMatt

I seem to be having an issue with the ability to send audio via the DSP from my soundcard input.

When the winamp input is selected, the byte count being sent to the server is correct, however when selecting the soundcard input, even with audio being captured via the level meters, I'm only sending approx 1/5th the data at the same bitrate.

Users who are listening to the stream constantly buffer, because my DSP isn't sending data to the server fast enough.

I've confirmed this via 3 different machines running patched windows 7 installations.

Any idea what's causing this? I can screen cap a movie if required.

Thanks,
Matt

I noticed same issue (I reported it few posts above), and doesn't matter if you are capturing audio from Sound Card or directly from Winamp, it only happens when you are using a old config file, for example a config file from v2.2.3.

this is how I solved it:

1 - close Shoutcast DPS.
2 - close Winamp.
3 - go inside Windows "program data" folder (where winamp settings are stored).
4 - then go inside "Plugins" folder and delete the old config "dsp_sc.ini".
5 - start Winamp again, open ShoutCast DPS and configure it again.

after that, all should be working properly

[DrO]

Originally Posted by DJ_MELERIX

btw, how we can set different "stereo types" for AAC Encoder now ?

I don't see options to set for example: Mono, Stereo, Parametric Stereo, Dual Stereo and others.

you can only set the options provided. the encoder will vary the mono/stereo based on the bitrate and encoding profile.

-daz

[canadave]

Hi, please bear with me if this is not the correct place to ask this question.

I've just installed the DSP 2.3.1 plugin along with the latest version of Winamp, on my community radio station's Windows XP pc. We have 24/7 on-air audio coming into the PC, which we want to broadcast via our Shoutcast host.

Now, I got the DSP plugin configured to connect to a legacy v1 host (which apparently our Shoutcast host is, because I couldn't get it to work without the legacy v1 checkbox checked--it just said something like "Cipher response received" and never started broadcasting), and when I clicked the Connect button, everything seemed to work fine--I can see data bytes being sent, and if I check the Centova Cast control panel on my host, the "Source Connected?" status has gone from "No" to "Yes". All well and good.

However (and here's the weird part)....as soon as I close the configuration window, having figured "job well done", the stream disconnects! If I go right back into the configuration of the plugin, it reconnects, the "stream uptime" resets to 0:00:00 in the Summary in the configuration window, and the stream starts again....until I exit the configuration window again, at which point again it disconnects.

Surely, I don't have to leave the plugin configuration window open in order to be able to use Winamp to stream my radio station's audio? :0

Any ideas what might be happening here? I'm pretty tech savvy, but this is my initial foray into internet radio broadcasting, so please be gentle

cheers,
Dave