JiveLite

[philippe_44]

Sorry for the ignorant question but I was thinking of porting JiveLite to the SqueezeESP32. I have no idea how difficult that would be.

I know there is a need for LUAjit and a few libraries (SDL) but I don’t now how many other deep Linux dependencies might exist.

How big is JIveLite in term of code and data? Will it be unfriendly with eXecute In Place?

Can somebody with a good knowledge of JiveLite give me an opinion?

Thanks

[ralphy]

For piCorePlayer I use the squeezeplay sources to build the libraries.
See this makefile for all the dependencies.
I then compile jivelite against the squeezeplay build using this script to make the pcp extension files. The script copies just the library files required to build jivelite, as none of the decoders are needed.

I'd suggest you consider using the lua-5.1.5 source from squeezeplay instead of luajit for compatibility with applets written for the controller, radio and touch. See my discussion with chill who did this for jivelite on the joggler for details. Most of the issues you'll run into are likely discussed there.

Jivelite needs a filesystem to store settings, in $HOME/.jivelite/userpath by default, otherwise you'll be asked to do an initial setup every time it starts. What's stored is similiar to what you'll find in /etc/squeezeplay/userpath/settings/ on your SB Radio. You could probably modify https://github.com/ralph-irving/jive...ive/Applet.lua and https://github.com/ralph-irving/jive...letManager.lua to use nvram instead.

Jivelite uses around 70M of memory on pcp after a few days of use and a base install occupies about 29MB on disk. Installing just the skin needed for your platform, would reduce the storage requirements.

If you want the VU meter now playing screens you'll need to have squeezelite compiled with the VISEXPORT build option and have the shared memory segment available to jivelite.

[philippe_44]

Thanks for the answer, it really helps

Jivelite uses around 70M of memory on pcp after a few days of use and a base install occupies about 29MB on disk. Installing just the skin needed for your platform, would reduce the storage requirements.

Ouch, that's going to hurt. On such esp32 systems, there is 4 to 8MB of flash and 4MB of SRAM of which 1/2 is almost unusable. It seems that I will need a different approach if I want to give a UI to that device then. I managed to have all squeezelite codecs integrated, but some required a lot of optimization work and the code source size was "manageable" so that I was able to find my way quickly and do modifications (or realize than a different approach was needed, like for SOX).

Some people have demonstrated that running a TFT touchscreen with a decent GUI is doable from esp32 though https://www.youtube.com/watch?v=yuCbGSLXZAE

[mherger]

>> Jivelite uses around 70M of memory on pcp after a few days of use and a
>> base install occupies about 29MB on disk. Installing just the skin
>> needed for your platform, would reduce the storage requirements.
>
> Ouch, that's going to hurt. On such esp32 systems, there is 4 to 8MB of

I'm not saying it should be easy. But aren't large parts of those 29MB
assets for the various skins and screensavers etc.? You could probably
make this JiveUltraLite by removing unnecessary stuff :-)

--

Michael

[philippe_44]

>> Jivelite uses around 70M of memory on pcp after a few days of use and a
>> base install occupies about 29MB on disk. Installing just the skin
>> needed for your platform, would reduce the storage requirements.
>
> Ouch, that's going to hurt. On such esp32 systems, there is 4 to 8MB of

I'm not saying it should be easy. But aren't large parts of those 29MB
assets for the various skins and screensavers etc.? You could probably
make this JiveUltraLite by removing unnecessary stuff :-)

--

Michael

I'm tempted but as it's going to be probably a non-trivial effort, I'll wait a bit to see if there is enough interest generated by the project. I need to figure out how to make it more "visible"

[ralphy]

>> Jivelite uses around 70M of memory on pcp after a few days of use and a
>> base install occupies about 29MB on disk. Installing just the skin
>> needed for your platform, would reduce the storage requirements.
>
> Ouch, that's going to hurt. On such esp32 systems, there is 4 to 8MB of

I'm not saying it should be easy. But aren't large parts of those 29MB
assets for the various skins and screensavers etc.? You could probably
make this JiveUltraLite by removing unnecessary stuff :-)

--

Michael

That's true, 27 of the 29M is in the applets folder and the skins are the majority of that space.

2.1M	QVGAbaseSkin
2.2M	SetupWallpaper
3.8M	HDGridSkin
3.8M	HDSkin
5.1M	WQVGAsmallSkin
6.8M	JogglerSkin

For picoreplayer the jivelite storage footprint is 10.5M as we only include the JogglerSkin in the default extension the other skins as well as the VU meter images are separate extensions.

[philippe_44]

So I've added button management now (except rotary, but I'll do that later) and I'm going to think about dislay now. I'm wondering if I should go LCD or a more simple OLED/text-ish display like SB/Boom ...

[ralphy]

There are a couple options you could use as a starting point.

There's the squeezeslave interactive feature that used lcd daemon and curses to create a text display like the SB1, using lms. Unfortunately, the interactive feature includes IR support as well, which is already a squeezelite feature.



rpress created the squeezelite Rio EMPEG car player feature which uses the boom display vfd dimensions and server side rendering code and button support. aka Vanputer. See post #8 for pictures. Here's the original development thread for details.

[philippe_44]

There are a couple options you could use as a starting point.

There's the squeezeslave interactive feature that used lcd daemon and curses to create a text display like the SB1, using lms. Unfortunately, the interactive feature includes IR support as well, which is already a squeezelite feature.



rpress created the squeezelite Rio EMPEG car player feature which uses the boom display vfd dimensions and server side rendering code and button support. aka Vanputer. See post #8 for pictures. Here's the original development thread for details.

Thanks - I assume that if I want server-based UI, like Boom/SB3 (get the GFREs) I would have to tell in HELO message that the player is a Boom/SB3 class but then I won't benefit from codec/https/other extensions that squeezeplay class provides ... or I'll have to write my own player class that combines both

[ralphy]

Thanks - I assume that if I want server-based UI, like Boom/SB3 (get the GFREs) I would have to tell in HELO message that the player is a Boom/SB3 class but then I won't benefit from codec/https/other extensions that squeezeplay class provides ... or I'll have to write my own player class that combines both

Yes, you're right, it's been such a long time since I've looked at the squeezeslave code.

The squeezeslave SB1 text display support was added to LMS and the Rio/Empeg boom display and button support was accomplished with a patch to LMS that created it's own player type empeg using a device id of 13.