Input Plugin Api Information / Discussion

[Xencito]

Follow to Winamp Input Plugin Api Details link

--------------------------------------------------------------------

Hi
I just love Winamp I was writting an input plugin and everything worked out great until I decided that winamp should be responsible for formatting titles in the playlist. I went on and did some researching and found that I could implement the undocumented winampGetExtendedFileInfoW(...). I quickly ran into some problems using this function:

How should I respond to "type" tag?
How should I respond to "length" tag (how should numeric data be formatted, a hex string etc.)?
And so on...

I guess my real question is whether there is an API somewhere, which I haven't been able to find (I did manage to find an outdated version by Michael Facquet in some zip file in this forum I think, which by the way did not help me all that much).

And why-oh-why is this function not a part of the Winamp SDK, this should not take long to document and make a simple test example. But until then, would anyone please be kind enough to at least give me a hint on how numeric data shoud be "encoded" into the buffer?

Thank you
and "Hello World" from Denmark!

[DrO]

as i don't have the time to properly document the exported functions i'd suggest either looking at the source code of the 64th Note plug-in or the Wavpack plug-in for how things are done. the 64th Note only has the initial ansi implementation but may be easier to follow for some of the questions you've asked whereas the Wavpack plug-in includes a few other things as well which allow for decoding of audio for the ripper component and a few other things though it's a bit more over the place (is planned to have that plug-in worked on at some point to improve it along with some localisation updates, etc).

and hopefully someone (most likely me) will get around to sorting out a properly documented example at some point (when i've finished the other projects i'm currently working on).

-daz

[Xencito]

Thank you very much for your (very quick) reply, I'll will have a look at your suggestions.

I appreciate the fact that other projects also requires time and working hours, but this is a pretty critical function, for all input plugin developers, so it is beyond me why this has not been documented a lot sooner. It has been around since version 5 I guess, which was released a long time ago (2003 or something similar?)...

I'm just curious as to why it hasn't been documented, is it considered experimental (still)?

I'm willing to lend a hand writing some documentation for the particular winampGet/winampSet/and so forth functions, because I believe good documentation/API allows even more developers to become involved in a product, making it even better and interesting for the community => good times for the millions of users.

And again thank you.

Regards
Xencito...

[DrO]

Originally Posted by Xencito

I'm just curious as to why it hasn't been documented, is it considered experimental (still)?

you'd have to ask the old development team why it was never properly documented and why it had to be reverse engineered of sorts.

Originally Posted by Xencito

but this is a pretty critical function, for all input plugin developers

my experience with most Winamp input plug-in authors is that they're not too bothered as it means targeting 5.x when they just want to do the minimum which leaves things at a 2.x level (and so excludes the additional api support) and means they're not then doing weird hacks to support more things than XMPlay & other apps able of loading input plug-ins allow.

i agree fully that it's something which should have been documented properly (hence the mass of additions made to some of the sdk files since i've had a chance to work on them) but it's like everything with Winamp, there's just not enough time/resources to do things.

initial documentation of things should be done by the end of the week (i suppose an advantage of me being out of work at the moment).

-daz

[DrO]

Winamp Input Plugin Api Details

I've uploaded an initial documentation for input plug-ins at http://nunzioweb.com/daz//input_plugin_api (this is essentially a 1.0 documentation release so will be subject to change like not all being text files but i'm pushed for time at the moment).

Any issues / things missing / needing more clarification then please do say and i'll answer / update things as required.

-daz

[thinktink]

What are CreateAudioDecoder and DeleteAudioDecoder for? I found them in in_mp3.dll.

I also found burn_doBurn, GetDS, and GetWave in in_wm.dll.

[DrO]

they're just internally used exports for use between some aspects of the different plug-ins. not something that falls under the general input plug-in exports.

-daz

[thinktink]

Ah, ok. Does it have anything to do with passing streaming metadata to Winamp? I'm trying to hook all the plugins and when I do it doesn't display any of the metadata for the playing stream in the playlist. I was wondering if maybe those had anything to do with it.

[DrO]

not that i'm aware of though stream metadata is a bit of a quirky area and ipc_updtitle (or something like) sent by the plug-in itself is the usual trigger for streaming title updates so maybe that isn't getting actioned correctly due to how you're hooking the plug-ins? only thing i can think off as i don't remember seeing such an issue with how i've hooked the input plug-ins in the past.

-daz

[thinktink]

I know in_mp3 is getting the data and is attempting to tell Winamp to refresh the title with the above mentioned IPC message because I've watched the messages to the main Winamp window with an external message hooker/viewer. It just seems like either Winamp isn't responding correctly or in_mp3 isn't giving the actual stream data. I still can't figure it out. I've solved it with a hack though by updating IPC_HOOK_TITLES with the input plugin's GetFileInfo() function manually. Unfortunately that means subclassing Winamp's main window which I usually try to avoid doing with any plugin.

The way I'm "hooking" the input plugins is by enumerating all DLLs in the plugins folder, loading them, getting the plugin's header, overriding the header's IsOurFile function with my own that always returns FALSE, and then returning TRUE for my IsOurFile if any of the other plugin's original function returns TRUE. I also either emulate or pass-through to the original plugin the winamp[Set|Get|Write|Add|Unified]Extended functions. When Winamp calls for a file my plugin doesn't/can't handle directly (like streaming audio or video files) I just pass through all the calls to Play/Pause/Unpause/SetVolume/SetPan/etc.. to the appropriate plugin with my plugin just acting as a middle-man. For the life of me I can't think of why the streaming metadata wasn't being displayed since I didn't override anything else but IsOurFile. All the other header functions remain unmodified. Even without overriding IsOurFile and just returning true (and passing through all the function calls) for other files the metadata wasn't displayed.

How did you hook the input plugins?

[EDIT /]
Forgot to mention, while testing I discovered that in_mp3 likes to crash (I think) on calls to winampSetExtendedFileInfo(W) if the filename is empty (allocated \0 terminated string with no characters.) No error message or anything is displayed to the user, Winamp just quits unexpectedly.

[DrO]

pretty much the same way though often i'd replace isourfile with my own version but then make that call the original function if i didn't need to be overriden so original behaviour is observed as that function is primarily there for stream handling.

though i can't remember at what stage and if i'm doing LoadLibrary(..) or GetModuleHandle(..) to get the loaded dll instance as the second i think is more what i try to use as LoadLibrary(..) can cause a different instance to be used instead which isn't initialised quite the same i think.

would be easier if i could access my source code for in_zip then i'd be able to confirm what i'm doing (just can't do that right now) as that's probably the nearest equivalent to what you're trying to do.

-daz

[thinktink]

Zomg I'm a f'ing blind boning bone-head. It said it right there in the SDK and I didn't even see it or even to think to check for it while debugging:

#define GETFILEINFO_TITLE_LENGTH 2048

void (*GetFileInfo)(const in_char *file, in_char *title, int *length_in_ms); // if file == NULL, current playing is used

I never checked for NULL file parameter. GAH!!!!! I've finally got it working right without the /class hack.

[DrO]

heh, i think that one's caught me out a few times way way back. at least you're sorted now so that's the main thing

-daz

[thinktink]

Would it be possible to document "hi.mp3"? I think I know what it's for but I would like to be sure.

[thinktink]

Originally Posted by thinktink

...document "hi.mp3"?...

/bump

[sheh]

Are there any docs explaining the more exotic functions, like Vis, DSP, etc.?

The input plugin interface is really a surprise. I expected a simple interface for decoding and metadata, and found out the whole playback plugin chain is controlled by the input plugin. Now I know why various things behave strangely depending on input plugin used.

[thinktink]

Originally Posted by sheh

Are there any docs explaining the more exotic functions, like Vis, DSP, etc.?

The input plugin interface is really a surprise. I expected a simple interface for decoding and metadata, and found out the whole playback plugin chain is controlled by the input plugin. Now I know why various things behave strangely depending on input plugin used.

No separate docs for the other plugin types you mentioned as far as I know. Just look at the comments in the SDK headers and the example plugins included in the SDK.

[thinktink]

[Quandry]

In the documentation "Reading_and_Writing_Extended_Metadata_Information.h" it defines both of the writing function winampSetExtendedFileInfo(W) as both having wchar_t * values but the value parameters for winampGetExtendedFileInfo(W) as char * and wchar_t * respectively.

The following taken from "Reading_and_Writing_Extended_Metadata_Information.h":

code:
extern "C" __declspec(dllexport) int winampGetExtendedFileInfo(const char *fn, const char *data, char *dest, size_t destlen)

extern "C" __declspec(dllexport) int winampGetExtendedFileInfoW(const wchar_t *fn, const char *data, wchar_t *dest, size_t destlen)

extern "C" __declspec(dllexport) int winampSetExtendedFileInfo(const char *fn, const char *data, const wchar_t *val)

extern "C" __declspec(dllexport) int winampSetExtendedFileInfoW(const wchar_t *fn, const char *data, const wchar_t *val)

Is it supposed to be like that or is the documentation wrong on the value parameter for winampSetExtendedFileInfo?

[Benski]

hi.mp3 (or hi.ext) is used to find the input plugin associated with the 'default extension' in the preferences.

the unicode variants of the dllexported metadata functions do in fact take the field name as a char * (ascii string)

[thinktink]

Originally Posted by Benski

hi.mp3 (or hi.ext) is used to find the input plugin associated with the 'default extension' in the preferences.

...

Oh! Dadgumn was I wrong. Thanks.

Originally Posted by Benski

...

the unicode variants of the dllexported metadata functions do in fact take the field name as a char * (ascii string)

Excellent (well, not the documentation part.)

[thinktink]

Originally Posted by Benski

...
the unicode variants of the dllexported metadata functions do in fact take the field name as a char * (ascii string)

Oops, wait a minute, you said "field name." Are you referring to the "data" parameter or the "val" parameter? I was talking about the "val" parameter, "field name" implies the "data" parameter.

[Benski]

ohh. weird. where does it specify that? it should definitely be const char * for winampSetExtendedFileInfo

[thinktink]

Originally Posted by Benski

ohh. weird. where does it specify that? ...

In the documentation "Reading_and_Writing_Extended_Metadata_Information.h", at least the copy I got from the SDK download if memory serves. I'll double check that.

[thinktink]

Originally Posted by thinktink

...the copy I got from the SDK download if memory serves. I'll double check that.

Scratch that, it wasn't from the SDK, I think it was an archive from DrO's website that I downloaded a long time ago linked in a post above. DrO has taken it down so I can't verify my statement because I seem to have misplaced the archive download, how I don't know since I still have the original SDK download right in my Downloads folder.

[thinktink]

Double whoops, I just had a look at the Wayback Machine. It was "Reading_and_Writing_Extended_Metadata_Information.txt", not "Reading_and_Writing_Extended_Metadata_Information.h", I must've renamed the file so that it would pop up and show formatted in my editor. It was also not in an archive, it was just hosted directly as a txt file on his server.

[animetedzone]

look like someone is stack in the real problem.