Topic: XMPlay SID plugin

[HED]

I'm running vanilla windows98 and xmp-sid.dll can work on w98! You have to download & copy msvcp71.dll and msvcr71.dll in your windows/system path

[raina]

Yes, haven't we been over this like 17 times?

[lingenfr]

It is probably hard to search for and many people will not read through 11 pages of messages. I suggest that the author update the first message with all of the key information. I have seen other folks here do that and it seems to work pretty well.

[Fraggie]

Done.

[aLoner]

Hi, I just wanted to say that XMPlay somehow mysteriously quits after playing some sids and when I restart it I must play them over again 'cause XMPlay doesn't save current position in the playlist by quiting. I'm using XP with SP2 and don't know what to do, maybe you can help?
Anyway, thanks for such a great plugin.

[Knurek]

Hi, I just wanted to say that XMPlay somehow mysteriously quits after playing some sids and when I restart it I must play them over again 'cause XMPlay doesn't save current position in the playlist by quiting. I'm using XP with SP2 and don't know what to do, maybe you can help?
Anyway, thanks for such a great plugin.

Switch to mono mode or disable funky surround option. Had the same problem, this helped in my case.
And yeah, auto saving the position every n tracks would be nice...

[aLoner]

Thanks, pal.
BTW, you can save playing position by checking in the Options and Stuff/Miscellaneous/Save play pos on closing. Have a nice day and play

[Tsorovan]

It won't save on crashing; I think that's his point.

[Fraggie]

News in version 24c:

• follows libsidplay2 update (speed bugfix)
• now displays playing parameters (model and speed) in General window if different than correct ones
  

[Lumina83]

Found a bug in this latest version: The plugin now fails to autodetect NTSC SIDs and plays them at PAL speed unless you forcibly select NTSC clock speed in the plugin's options.

[Knurek]

Found a bug in this latest version: The plugin now fails to autodetect NTSC SIDs and plays them at PAL speed unless you forcibly select NTSC clock speed in the plugin's options.

Confirmed with C64Music\Hatlelid_Kris\Test_Drive_2_The_Duel.sid (both RSID and PSID versions).

[Fraggie]

Fixed.

[carboxy]

im running windows 98se and xmplay 3.3, copied the sid plugin into the main folder containing xmplay.exe but it doesnt appear in the plugin list and xmplay refuses to play .sid files

any ideas ?

[raina]

Note: You need MSVCR71.DLL and MSVCP71.DLL files for this plugin to work!

You have these?

[Tero Niemi]

First: a big Thank You for Fraggie for this wonderful plugin. Anyone who still tries to get a program to work in Win98 deserves a medal!

Second: (there's always the second thing...) A question: Why does the memory usage vary so much from SID to SID?

Here's a plain vanilla newest XMPlay (well, skin added) with SID plugin beta 24c: http://cc.joensuu.fi/~tniemi/XMplaySIDmem.png

(Operating system: WinXP Home Edition sp1 (Finnish))

A seemingly random +35Mb memory usage sounds bit crazy, doesn't it? Both SID files are under 5kb, so where does the memory go? In the Vista land?

I tested same SIDs with the latest Sidplay2/W and it does not have this kind of "memory usage feature" so libsidplay2 cannot be the culprit. It must be some XMPlay specific code.

Thank you in advance!

[Tero Niemi]

More about the same memory issue... It's a bit messier than I though. Consider this:

XMPlaySID1.jpg - XMPlay started, memory usage 2.5Mb
XMPlaySID2.jpg - XMPlay starts playing SID, memory usage 70Mb!!!
XMPlaySID3.jpg - XMPlay minimized while still playing, memory usage drops to 1.3Mb
XMPlaySID4.jpg - XMPlay restored, memory usage stays low at 2Mb
XMPlaySID5.jpg - XMPlay switches to next SID, memory usage 56Mb!!!

It doesn't help keeping the player minimized. Each time SID changes the player hogs about 30-65 Mb of memory. The same hogging happens even when the last SID is played and the playing stops. The memory stays allocated.

(This kind of memory hogging does not occur when playing fex. MP3:s -- or at least the effect is so small (~.5Mb) that it does not show.)

Strange....  Hopefully this can be fixed. (Pretty please?)

[Torkell]

The same hogging happens even when the last SID is played and the playing stops. The memory stays allocated.

You may find that if you set XMPlay to unload the last track (right-click on the playlist loop button, tick Unload Final Track) then the memory will be deallocated after the last SID finishes playing.

No idea about the rest - it's probably to do with how the plugin handles SIDs. IIRC the in_usf/in_gsf plugins also hog memory as they emulate a N64 and a GBA respectively.

[raina]

Maybe it has something to do with having the fast seeking enabled in the plug-in config. I don't know how it works but maybe the file is rendered and indexed to memory and that's what's hogging the it. Is the amount of memory relative to the SLDB length of the SID file?

[Tero Niemi]

(By the way, Delta.sid #10 crashes XMPlay!!! That is critical, I cannot listen the #12!!!)

Maybe it has something to do with having the fast seeking enabled in the plug-in config. I don't know how it works but maybe the file is rendered and indexed to memory and that's what hogging the it. Is the amount of memory relative to the SLDB length of the SID file?

Wonderful theory! (And thanks for a XMPlay skin that does not suck!)

Unluckily the facts don't agree with your theory...
Here's a bit more detailed report of memory usages of two SIDs.

Sid               Cold       Next       Min/res
-----------------------------------------------
Mysteriously.sid  69240 Kb   57312 Kb   1756 Kb
Delta.sid         41988 Kb   23420 Kb   1688 Kb

First number is when XMPlay is started up by playing the SID (cold start). Second tells the usage when SID is played next on the playlist. Third tells the memory when XMPlay is minimized and restored while playing. All these numbers remain relatively same.

Here's the configuration used:
http://cc.joensuu.fi/~tniemi/XMPlaySIDconfig.png
XMPlay and SID plugin are freshly downloaded, no other plugins are installed.

Here is the details about the two SIDs used. Both are downloaded from the latest HVSC.

Title       Tom Hoffer (MAC2) - Mysteriously
File        Mysteriously.sid
Path        C:\Music\sid\HVSC\VARIOUS\M-R\MAC2
Size        3477 bytes
Format      PlaySID one-file format (PSID)
SID model   MOS-6581
Clock speed VBI (PAL)
Addresses   load: $1000, init: $1000, play: $1003
MD5         b16666703fe3d267cbe4c9f8f501e90a
Lengths     1. 3:04 (3:03) - looped
Length      3:04
Output      44100 hz - 16 bit - stereo

Title       Rob Hubbard - Delta
File        Delta.sid
Path        C:\Music\sid\HVSC\Hubbard_Rob
Size        5246 bytes
Format      PlaySID one-file format (PSID)
SID model   MOS-6581
Clock speed VBI (PAL)
Addresses   load: $bc00, init: $c357, play: $bde4
MD5         4123010d167b14a84f824fc28d832979
Songs       8 (13)
Startsong   7 (12)
Lengths     1 (1). 11:23 (11:22) - looped
            2 (4). 0:11 (0:11)
            3 (5). 0:11 (0:11)
            4 (9). 0:11 (0:11)
            5 (10). 0:13 (0:13)
            6 (11). 0:16 (0:16)
            7 (12). 1:18 (1:17) - looped
            8 (13). 1:18 (1:17) - looped
Length      11:23
Output      44100 hz - 16 bit - stereo

I see no logic here. None at all.

[Tero Niemi]

You may find that if you set XMPlay to unload the last track (right-click on the playlist loop button, tick Unload Final Track) then the memory will be deallocated after the last SID finishes playing.

That did work! Thanks!

No idea about the rest - it's probably to do with how the plugin handles SIDs. IIRC the in_usf/in_gsf plugins also hog memory as they emulate a N64 and a GBA respectively.

The strange part is that if you minimize the player and restore it the memory usage drops to less than 5%! The SID keeps playing perfectly, seeking and everything works finely, it just uses less memory. I can even seek around the 15 minutes long Hubbard song with no effect.

Have you tested the in_usf/in_gsf plugins for similar minimize/maximize behavior? If that happens, the problem is not on the plugin itself but on the player!

[Tero Niemi]

One more:

Sid               Cold       Next        Min/res
------------------------------------------------
Axel_F.sid        34640 Kb   3540 Kb!!!  1768 Kb

And the SID info:

Title       Graham Marsh (BOGG) - Axel F
File        Axel_F.sid
Path        C:\Music\sid\HVSC\BOGG
Size        5361 bytes
Format      PlaySID one-file format (PSID)
SID model   MOS-6581
Clock speed CIA 1 Timer A (PAL)
Addresses   load: $412f, init: $414a, play: $0
MD5         29889eb41df417c31f3a1870475beaad
Lengths     1. 5:10 (5:10)
Length      5:10
Output      44100 hz - 16 bit - stereo

(By the way, the "Length" field in SID General Info view is probably buggy. It doesn't calcucate the total length of subsongs. See the Delta.sid info fex.)

[Fraggie]

The responsibility for huge memory usage lies in SLDB and STIL handling. SLDB uses much memory for speed's sake (for 32000 files it will be around 20 MB). I guess I should try to optimize it a bit... However I think I see a memory leak in STIL loading. I'll check it later on when I find the most recent sources. The minimizing issue is probably because of Windows memory handling (maybe it's paging memory or something) or peculiarity of the Task Manager itself. The plugin obviously can have no idea if XMPlay is minimized or not.

(By the way, Delta.sid #10 crashes XMPlay!!! That is critical, I cannot listen the #12!!!)

It doesn't happen here. But I see some strange things going on in the STIL view. Try disabling STIL and check if XMPlay still crashes.

(By the way, the "Length" field in SID General Info view is probably buggy. It doesn't calcucate the total length of subsongs. See the Delta.sid info fex.)

It's by XMPlay design. It shows length of currently playing subsong. If you want total length then see the playlist.

[Torkell]

Ah, I remember now. What's going on with window minimising is that when you minimise a window, Windows goes through and prunes the working set (the memory that's being actively used by the program) down. Hence why 50MB turns into 15MB. It's normal, and happens with most stuff (minimised cmd.exe windows can appear to use 0MB of memory). If you use something else, like sysinternal's process explorer or the performance monitor in windows you can see just what's going on with the memory usage.

[Tero Niemi]

(Lenght field) It's by XMPlay design. It shows length of currently playing subsong. If you want total length then see the playlist.

Oops, sorry about that. I did not know.

(By the way, Delta.sid #10 crashes XMPlay!!! That is critical, I cannot listen the #12!!!)

It doesn't happen here. But I see some strange things going on in the STIL view. Try disabling STIL and check if XMPlay still crashes.

Yay! Delta does not crash when STIL is switched off! (To be honest I was a bit worried for a while.)

It seems that most of the memory problems are STIL-related. Here's updated numbers with different configurations:

Memory usage with no STIL & yes SLDB:
Sid                 Cold       Next      Min/Max
------------------------------------------------
Mysteriously.sid   34328 Kb   21600 Kb   2388 Kb
Delta.sid          34212 Kb    7948 Kb   2124 Kb
Axel_F.sid         34220 Kb    3276 Kb   2460 Kb


Memory usage with no STIL & no SLDB:
Sid                 Cold       Next      Min/Max
------------------------------------------------
Mysteriously.sid    3560 Kb    2648 Kb   2336 Kb
Delta.sid           3418 Kb    2500 Kb   2584 Kb
Axel_F.sid          3448 Kb    2528 Kb   2616 Kb

Again:
Cold - XMPlay is started with SID
Next - SID is played as next song on the playlist
Min/Max - XMPlay is minimized/maximized while playing

By the way, LaLa has made an already debugged & portable STIL class for free use:
http://www.transbyte.org/SID/STILView.html
Smart kid, good programmer. Why not consider using it?

The only thing that doesn't fit the STIL pattern is the (appropriately named) Mysteriously.sid. Why does it use 20Mb (3 min song, no STIL & yes SLDB), when Delta.sid uses only 8Mb (15 minutes monstrosity, no STIL & yes SLDB). I have no Windows developement tools, so I am unable to dig deeper on this...

Anyhow -- Thank you for your quick and thoughtful answers. You are doing a good job.

[Tero Niemi]

SLDB uses much memory for speed's sake (for 32000 files it will be around 20 MB).

A bit offtopic, but what algorithm are you using? A MD5 hashtable or search tree? If I understand correctly a judy array (http://judy.sourceforge.net/) would be perfect for this kind of job. That would probably lower the memory need and more than double the speed if you are using a hashtable.