Bass amp problem

[ralphy]

I have to decided what's the best way to proceed.

Update the bitbake squeezeplay recipe to use my current squeezeplay sources or backport acc and maybe ogg/flac, and apply the lua random albums menu and lms 8.0 compatibility fixes or just disable the squeezeplay player and use squeezelite.

I'm leaning towards backporting as you do lose the local backup alarm, and navigation sound effects when using squeezelite. Headphone switching still works and I haven't tried the line-in.

[mrw]

My own project, if I get to it, was to simply move the 'baby' onto Squeezeplay 7.8.

It hadn't occurred to me to consider Squeezelite as a way to go. I'm not sufficiently familiar with it.

As far as I can see, the only binary change is to take up ogg/flac, and perhaps some version numbering tweaks. I, personally, could live without wma and spotify, but I would be looking to see if your current aac would drop in place of the private aac. Does the "old spotify applet" have any value now ? I simply don't know.

I can see that there are quite a number of lua script changes that would need to be gone through to check that nothing breaks (upgrade compatibility for example, and perhaps restoration of firmware), but I'm not sufficiently familiar at present.

I have no knowledge of the "lua random albums menu" and "lms 8.0 compatibility fixes" that you refer to, something to look into.
Edit: Now found and understood.

I personally would not wish to lose the local backup alarm, or the sound effects.

[slartibartfast]

My own project, if I get to it, was to simply move the 'baby' onto Squeezeplay 7.8.

It hadn't occurred to me to consider Squeezelite as a way to go. I'm not sufficiently familiar with it.

As far as I can see, the only binary change is to take up ogg/flac, and perhaps some version numbering tweaks. I, personally, could live without wma and spotify, but I would be looking to see if your current aac would drop in place of the private aac. Does the "old spotify applet" have any value now ? I simply don't know.

I can see that there are quite a number of lua script changes that would need to be gone through to check that nothing breaks (upgrade compatibility for example, and perhaps restoration of firmware), but I'm not sufficiently familiar at present.

I have no knowledge of the "lua random albums menu" and "lms 8.0 compatibility fixes" that you refer to, something to look into.

I personally would not wish to lose the local backup alarm, or the sound effects.

Michael has a patch to fix the LMS 8.0 compatibility issue.
https://forums.slimdevices.com/showthread.php?p=963365

Sent from my Pixel 3a using Tapatalk

[mrw]

Michael has a patch to fix the LMS 8.0 compatibility issue.
https://forums.slimdevices.com/showthread.php?p=963365

Excellent, thank you. Looks like a simple fix. Version comparison/tinkerings thereto was already on my watchlist...

[mrw]

I can see that there are quite a number of lua script changes that would need to be gone through to check that nothing breaks (upgrade compatibility for example, and perhaps restoration of firmware), but I'm not sufficiently familiar at present.

Well, I think the thing to do is just to try them all. So I shall.

[mherger]

> I have no knowledge of the "lua random albums menu" and "lms 8.0
> compatibility fixes" that you refer to, something to look into.

As mentioned above the "LMS 8.0 compatibility fixes" are available as a
patch on the Radio 7.7 firmware. As it's basically a back-port of a
change already in the 7.8 branch, you wouldn't have to take care of
that. The fact that it's already in 7.8 is the reason why Touch is not
affected by that problem: most Touch devices probably already run 7.8
firmware, which we never built for the Radio.

--

Michael

[mrw]

As it's basically a back-port of a change already in the 7.8 branch, you wouldn't have to take care of that.

Thank you, I see that now.

most Touch devices probably already run 7.8 firmware, which we never built for the Radio.

I guess native ogg/flac might be good to have on the Radio if that stream format gains significant traction. But perhaps not at the expense of the the other 'private' functionality.

As regards the other changes, after looking at them briefly I wonder how worthwhile many of them would be. Probably some nice bits of UI and Alarm functionality, but some changes in networking and setup that would need to be validated. Although they've been running on Touch and Controller, so should be ok...

[ralphy]

My own project, if I get to it, was to simply move the 'baby' onto Squeezeplay 7.8.

It hadn't occurred to me to consider Squeezelite as a way to go. I'm not sufficiently familiar with it.

As far as I can see, the only binary change is to take up ogg/flac, and perhaps some version numbering tweaks. I, personally, could live without wma and spotify, but I would be looking to see if your current aac would drop in place of the private aac. Does the "old spotify applet" have any value now ? I simply don't know.

I can see that there are quite a number of lua script changes that would need to be gone through to check that nothing breaks (upgrade compatibility for example, and perhaps restoration of firmware), but I'm not sufficiently familiar at present.

I have no knowledge of the "lua random albums menu" and "lms 8.0 compatibility fixes" that you refer to, something to look into.
Edit: Now found and understood.

I personally would not wish to lose the local backup alarm, or the sound effects.

That's why I haven't mentioned the squeezelite alternative as I'd also prefer to keep all changes as close as possible to the current. There are other lua changes needed as well to manage the amp auto power off and you need to disable starting the squeezeplay builtin player.

The spotify applet uses the defunct libspotify so it no longer works and wma decoding can be handled in LMS with bpa's PlayWMA plugin.

First step. I'm going to POC the aac decoder using the current 7.7.3 squeezeplay with no other changes so it can be installed in place of the current firmware jive binary for testing.

Your idea to update squeezeplay to match the touch 7.8.0 version seems the best option.

[ralphy]

I recall that jive_alsa was "bit perfect" (subject to 4 debug hash bytes of no significance), and that libasound.so.2.0.0 was bit perfect (I was trying out a few later versions). I did have to define the original build directory, somewhere in the poky conf file, I think, to get the build tree the same - it is certainly baked into jive_alsa. Makes binary comparison somewhat easier.

Could you provide details on the change(s) the next time you have the aws instance running?

First step. I'm going to POC the aac decoder using the current 7.7.3 squeezeplay with no other changes so it can be installed in place of the current firmware jive binary for testing.

I've built a drop in replacement for the radio /usr/bin/jive 7.7.3r16676 binary with the fdk-acc decoder. The wma decoder and defunct libspotify based Spotify applet private features are missing as discussed. I've been playing my usual aac radio streams as needed and playing through my ~1400 m4a local library files when idle for the last couple days without issue. CPU usage seems on par with the stock jive binary during aac playback. It would be great to have others test as well. The aac decoder code is identical to what was added to the squeezeplay github sources in August 2019 so has had a fair bit of testing already. It's applied as a patch file in the squeezeplay recipe. The random album menu and compatibility patches are also included in the squeezeplay recipe.

The binary is available in the squeezeos folder on sourceforge. The bitbake recipes, sources and patches needed to compile jive are there as well.

I guess native ogg/flac might be good to have on the Radio if that stream format gains significant traction. But perhaps not at the expense of the the other 'private' functionality

I also have a 7.8.0 jive which includes ogg/flac support as well as aac and does work with the 7.7.3 firmware but libFLAC needs to be replaced and libogg installed in /usr/lib from the 7.8 rootfs, otherwise jive crashes when you attempt to play an ogg/flac stream. I have noticed that jive CPU usage was higher in general and wonder if it could be related to not having applied the 7.8.0 lua enhancements. More investigations needed.

Note that for a 7.8.0 firmware build the squeezeplay-compatibility.patch must be removed from my squeezeplay_svn.bb

[mrw]

Could you provide details on the change(s) the next time you have the aws instance running?

Will do. But expect patchy responses as I have some family matters to deal with over the next few weeks.

It would be great to have others test as well.

I'll load it onto one of my Radios. Certainly worth checking.

I also have a 7.8.0 jive which includes ogg/flac support as well as aac and does work with the 7.7.3 firmware but libFLAC needs to be replaced and libogg installed in /usr/lib from the 7.8 rootfs, otherwise jive crashes when you attempt to play an ogg/flac stream. I have noticed that jive CPU usage was higher in general and wonder if it could be related to not having applied the 7.8.0 lua enhancements. More investigations needed.

I have Squeezeplay 7.8.0 running without ogg/flac (i.e. on the 7.7.3 r16676 binaries) on one of my Radios. Needs a 'hack' to Jive.lua to report itself to LMS as 7.8.0 r_whatever because the version is baked into the jive binary, and one or two (I think) of the 7.7.3 -> 7.8.0 patches need this to work. (Update context-menu styles to use icons for playlist control actions. and Task B0020: Player control over UDP). I'd be surprised if the lua enhancements were the cause of higher cpu usage, but I haven't checked. I'll try and look at that.

One point: I think it advisable that you merge the 7.7 tree into 7.8 to catch that last "baby only" patch, if you haven't already. (Baby only - ignore firmware older than SR to SB migration firmware (7.7.3 r16667)). I suspect that it is there to prevent a "converted to LMS Smart Radio" from inadvertently downgrading to an earlier firmware that doesn't recognize the Smart Radio hardware (revision 8 ?).


Should this subject be moved to another thread ?