Comments (15)
I'm waiting for flac maintainers to have a look. I talked to them already but they say they are are very busy. The PR is just pending.
from squeezelite.
No, it can only be done inside flac, it's deep inside there. I'll increment the version in my PR and use that to verify
from squeezelite.
That #208 should do, at least for all dynamic load case and static cases in Linux. I don't have much possibility to check currently.
from squeezelite.
You can download the patch that we use from SF https://sourceforge.net/projects/lmsclients/files/source/flac.patch/download and apply it to a local build of libflac 1.4.3 and build a local copy.
from squeezelite.
Will this libflac patch be upstreamed?
from squeezelite.
Thanks. I guess I’ll wait and see how that goes. I maintain the squeezelite package for nixpkgs, but I’m hesitant to propose patching libflac for everyone.
from squeezelite.
I understand but you can have a look at the patch, it is not activated unless a libflac API is called. Otherwise, it's the same code that runs, a Boolean prevents any new code from being activated.
from squeezelite.
So a feature was merged into Squeezelite which uses a function in libFLAC which is not part of (upstream) libFLAC, but just a pending PR without any ETA? This seems odd 😄.
I mean doesn't it make more sense to have this functionality within Squeezelite source code, at least until it gets merged into libFLAC? Even then, the time it takes before it tickles down to downstream distribution versions of libFLAC can be years.
We provide DEB packages for recent Squeezelite on Debian Bullseye til Trixie for all architectures. For this to work now, we'd need to patch, compiled and ship own versions of libFLAC, overwriting Debian's libflac
package for end users (which can cause conflicts with other software), as well as libflac-dev
/headers for our build scripts/systems, maintaining this for all Debian versions and all architectures, which is actually above our possible time and efforts.
FLAC support in Squeezelite is not optional, so there is no way to work around this by disabling FLAC functionality.
The only thing I can practically do now is providing Squeezelite versions before this commit, and I see no real chance to change something about this until all Debian versions we support provide libFLAC versions which have the future of this commit included. This of course breaks the whole purpose of our packages, since Debian itself provides Squeezelite packages, just outdated ones.
Let me know if I understood something wrong, of when someone has an idea how we can practically deal better with this.
from squeezelite.
I can provide a PR so that this function is disabled, but that means no proper support for OggFlac radio for squeezelite, per what you say, for years
from squeezelite.
There is no way to implement this functionality within Squeezelite source code?
Else, the proper solution would be probably to make it optional, yes, and in case enable it automatically if the used function is actually present in the libFLAC it is gonna be linked against. I.e. check whether the method is available, if so use it, else skip it. But forcing everyone to patch and compile/ship libFLAC when compiling/shipping Squeezelite, is a problem, at least for us.
from squeezelite.
I'll increment the version in my PR and use that to verify
Of course there is the risk that the version gets incremented for other reasons before the PR is merged. I am no C coder, but I guess there is a way to check whether the used function/symbol is available? That seems more failsafe to me.
from squeezelite.
I'll increment the version in my PR and use that to verify
Of course there is the risk that the version gets incremented for other reasons before the PR is merged. I am no C coder, but I guess there is a way to check whether the used function/symbol is available? That seems more failsafe to me.
Not really. I'll see if I can do something with weak functions but that would still to work with MSVC (sigh...)
from squeezelite.
Many thanks for the quick solution. I'll test this ASAP.
from squeezelite.
I was thinking about this too, because the newest GPIO code requires a newer version of libgpiod than is typically included with distributions, so I ended up statically linking the new version of just this library in my squeezelite build, so I could deploy it to all my players without having to manually build other packages on them. I was thinking that static linking the modified version of libFLAC might be the way forward here as well, so that it removes the tie to the distro's libFLAC version.
from squeezelite.
But it still means that you need to compile those patched or recent libraries at build time. Trying to use features/methods of libraries in a dynamic way, when they are available in the linked library, makes it easier for distributors. E.g. Debian themselves would decline statically linking libraries they ship with their own repo for dynamic linking.
However, requiring a newer version of a library is one thing, but requiring a patch to implement a feature which was never upstreamed is something entirely different, IMO 🙂.
I am happy to report that the change done with this PR works for us 👍: #208
from squeezelite.
Related Issues (20)
- flac and ogf streams HOT 3
- output threshold is incorrect HOT 2
- Power controls (gpio/script) tied to output device being open rather than soft power button state
- Build error in flac.c on revision 1466 HOT 2
- Whole-album flacs with embedded cuesheet playback broken by commit c89faf3 Ogg metadata (and a bit more) HOT 11
- relay-script toggles off/on/off during start HOT 9
- Version 1476 - Error compiling on X86 and Raspberry 4 HOT 13
- Request: Create Release HOT 4
- OggFlac chaining HOT 2
- unhandled grfe HOT 4
- squeezelite-pulse sync issues
- Issue with mp3 playback on Alpine Linux with recent squeezelite versions HOT 8
- Crash on Arch Linux
- Building on macOS does not use libraries installed by package managers HOT 5
- macOS M1 binary release Squeezelite.app is corrupted HOT 2
- Compiling: error with gpio.h HOT 3
- Meta-package squeezelite-2.0.0.1488-aarch64 HOT 1
- Squeezelite-2.0.0.1488 dont play FLAC radios HOT 1
- Native DSD not working HOT 2
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from squeezelite.