Official moOde 7.6.0 support thread

[zOr7gA8]

in place update worked fine.
not sure if better sound quality or expectation bias!? maybe a little bit more detailed?!

[Skip Pack]

In-use updated smoothly last night. I plays perfectly. Annual donation sent!

WRT the 64bit option: is there any progress at the OS level to bring this to full release status?

Thanks

[Tim Curtis]

I think its still WIP with the RaspiOS devs.

[TheOldPresbyope]

@Skip Pack


What Tim said.

There are persistent rumors that the 64-bit Raspberry PI OS (e.g., combination of 64-bit kernel and 64-bit userland) is about to be released but, in one form or another, such rumors have been swirling for months.

Meanwhile you can follow issues related to it in the RPF's special "[R]epository for containing issues on the 64 bit operating system (as distinct from the 32 bit one)".

I'm curious, though, to know what your expectations are for the 64 bit OS. What aspect of moOde do you think would be improved if its constituents were rebuilt in a 64-bit userland? 

Don't forget, we still see users run into "interesting" issues after choosing the 64-bit (experimental) kernel architecture. Anecdotally, these issues seem to be diminishing as we go along but there's no reason to expect we won't run into some more with a full 64-bit OS. As always, whether an underlying problem is trivial or complex, dealing with it requires an investment of time and effort.

Regards,
Kent

[Skip Pack]

I had tried 64 bit back around 7.0-7.1 and felt there was a small SQ improvement and encountered some of the glitches it entailed (mostly needing to switch back to 32 bit to scan new additions to the library then go back to 64 -- the time and work to do so was too much). I don't know if that SQ gap remains and understand that other changes and new versions of components my well have bridged or surpassed that gap. My current motivation is that I am studying DRC and hope to become able to generate filters/impulse responses to use with CamillDSP in Moode. I would think that a 64 bit OS would be more efficient for a convolver.

Thanks,  Skip

[TheOldPresbyope]

...
I would think that a 64 bit OS would be more efficient for a convolver.

Thanks,  Skip

Fair enough. By default, CamillaDSP used 64-bit floats (but optionally can use 32-bit floats) and as its maintainer says in his repo README, "In general, a 64-bit CPU and OS will perform better."

Last year I built 64-bit RaspiOS/moOde several times to explore what has to be changed in the build recipe. I tested only for software issues and had no way at the time to assess SQ adequately (and don't trust my ears and brain to do the assessment anyway). There have been many updates to various software components since.

Testing that all DACs/drivers/3rd party software work is necessary and time consuming. Fortunately, the RPF is moving from a heavily customized userland to a Debian userland with a few RPi-specific additions so we can hope that packages which have been wrung out in other 64-bit environments will show few issues in RaspiOS.

Regards,
Kent

[roderickvd]

You don't need to run a 64-bit kernel to use 64-bit integers or floats in user land. In fact on CPU's that support 64-bit, there will be no noticeable difference in CPU or RAM usage when using 64-bit samples on either a 32-bit or 64-bit kernel.

64-bit kernels will allow access to more RAM (which is doubtful you'll have) and may offer micro-optimizations because some 64-bit instructions are bit more efficient than 32-bit instructions. Those optimizations will be almost unmeasurable except in specific benchmarks.

It is very unlikely you will hear any SQ improvements. Given a certain audio file, renderers will have the exact same output on either 32-bit or 64-bit kernels. If there are any improvements, they will be side-effects in drivers that perhaps influence jitter. But it's very unlikely.

[TheOldPresbyope]

Let's move any further discussion of 64-bit RaspiOS to its own thread since it's out of scope for this one.

Regards,
Kent

[rusconi]

Hi Tim,

I notice that the currentsong.txt file now has %-encoding in the coverurl field.

e.g.

coverurl=imagesw%2Fradio-logos%2F1.FM%20-%20Blues%20Radio.jpg

instead of

coverurl=imagesw/radio-logos/1.FM - Blues Radio.jpg

Is this intentional and permanent?

Regards

Russ

[Tim Curtis]

From the 7.6.0 release notes

Code:

Bug fixes

- FIX: URL encoding for radio station logos