Release Planet Hively

[Magic Sam]

Hi all

I have compiled Planet Hively on the Pandora, a music disk from Iris and Up Rough, released in 2007:

http://www.pouet.net/prod.php?which=49931

https://github.com/pete-gordon/planet-hively

Grab it on the repo while it's hot !

http://repo.openpandora.org/?page=detail&app=planethively-magicsam

New in build 1:

- Planet Hively (last git commit from January 12, 2016)
- Compiled with @ptitSeb 's latest Code::Blocks
- Source code is inside the package

Cheers, Magic Sam
[doublepost=1493907781,1493890770][/doublepost]Hi again,

While I'm at it, I gave Hively Tracker a go this afternoon:

http://www.hivelytracker.co.uk/

https://github.com/pete-gordon/hivelytracker

The SDL port compiles correctly, but it segfaults when playing a MOD file.

I need to investigate further...

Cheers, Magic Sam

 

[levi]

Thanks, this works fine on my GHz machine and is a novel interface to a music disc, with some cool sounds. Sounds like I'd like to have a play with the tracker that made this music, but take your time in getting that working.

 

[Magic Sam]

Hi all

Sorry for the delay...

I recompiled Hively Tracker with @ptitSeb 's latest beta Code::Blocks and debugging symbols, then ran it with gdb:

Thread 1 "hivelytracker" received signal SIGSEGV, Segmentation fault.
0x400d3054 in SDL_UpperBlit ()
from /mnt/utmp/codeblocks/usr/lib/libSDL-1.2.so.0
(gdb) bt
#0 0x400d3054 in SDL_UpperBlit ()
from /mnt/utmp/codeblocks/usr/lib/libSDL-1.2.so.0
#1 0x0001384c in bm_to_bm (src=0xca928 <about_bm>, sx=-4, sy=-4,
dest=0x61f4c <mainbm>, dx=236, dy=176, w=328, h=248) at ../gui.c:683
#2 0x0004cfd4 in about_handler (gotsigs=0) at ../about.c:506
#3 0x00012c14 in main (argc=1, argv=0xbeffe884) at ht.c:126

Do you guys understand what's going wrong ?

Cheers, Magic Sam

 

[levi]

My vote goes towards that being a buffer overrun. You're passing in a source of destination pointer in gui.c which presumably point the the start of defined buffers, and if the destination one isn't big enough it'll do this. Or the pointers could be simply invalid, pointing to a read-only part of the memory map or something.

Why this happens on Pandora and not on other platforms would need more investigation though. Maybe it's to do with the way the GPU works by writing back to the framebuffer in main memory, rather than maintaining its own framebuffer, but that's just a guess. Do you know what platforms it is successfully running on already?

 

[Magic Sam]

Hi @levi

Thanks for having a look !

Regarding the existing ports:

http://www.hivelytracker.co.uk/downl.php

Hively Player has already been ported to several platforms on x86 and PPC, but it looks like the Pandora version would be the first running on ARM...

Cheers, Magic Sam

 

[Farox]

Hi all

Sorry for the delay...

I recompiled Hively Tracker with @ptitSeb 's latest beta Code::Blocks and debugging symbols, then ran it with gdb:


Do you guys understand what's going wrong ?

Cheers, Magic Sam

I don't know if its related to this but searching on the net i found this https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=184437
Don't have time now to test, but if you could ...try loading a mod file (instead of a lively tracker mod) with only 4 channels did segafults or not the tracker, if segafult maybe its related to a SDL_mixer bug.

 

[M-HT]

Hi all

Sorry for the delay...

I recompiled Hively Tracker with @ptitSeb 's latest beta Code::Blocks and debugging symbols, then ran it with gdb:


Do you guys understand what's going wrong ?

Cheers, Magic Sam

It crashes in SDL bundled in codeblocks, does it also crash with the system SDL ?

 

[Magic Sam]

Hi all

@Farox : thanks for the hint, I'll have a look at it ASAP !

@M-HT : yes, it does crash with both codeblocks and stock SDL.

Cheers, Magic Sam

 

[ptitSeb]

Hi all

@Farox : thanks for the hint, I'll have a look at it ASAP !

@M-HT : yes, it does crash with both codeblocks and stock SDL.

Cheers, Magic Sam

The issue is "just" that SDL cannot get a buffer as small as the traker wants. And no check is done to see if the wanted buffer is exactly obtained.
To fix, simply change line 75 of replay.c
from

#define OUTPUT_LEN ((FREQ/50)*2) /* Linux can't cope with buffer being too small, so we sacrifice GUI responsiveness... */

to

#define OUTPUT_LEN ((FREQ/50)*4) /* Linux can't cope with buffer being too small, so we sacrifice GUI responsiveness... */

And it will not crash anymore. But there maybe so other place to adjust this *2 to *4, I'm not sure (and I haven't checked)

 

[Magic Sam]

Hi all

@ptitSeb : you are, as always, right ! Thanks a lot The sound quality is weird though, compared to, say, Hively Tracker 1.6 running on MorphOS. It sounds like the tune is played a bit too fast...

I need to investigate some more before pushing a PND to the Repo.

Cheers, Magic Sam

 

[ptitSeb]

Hi all

@ptitSeb : you are, as always, right ! Thanks a lot The sound quality is weird though, compared to, say, Hively Tracker 1.6 running on MorphOS. It sounds like the tune is played a bit too fast...

I need to investigate some more before pushing a PND to the Repo.

Cheers, Magic Sam

Yeah, I guess the difference between the buffer size between wanted / granted make things a bit wrong. I tried a few trick to compensate, but none were successfull in term of audio quality (but I may have made a mistake somewhere, I didn't kept the experiments anyway)