search

Opendigitalradio / dablin

DAB/DAB+ receiver for Linux (including ETI-NI and EDI AF playback)
GNU General Public License v3.0
123 stars 27 forks source link

Switch to vendor fork of ka9q-fec #17

Closed russel closed 7 years ago

russel commented 7 years ago

This sequence of changesets introduces a vendor fork of ka9q-fec into the DABlin repository to replace the need for this library to be installed when it is not packaged by the main Linux distributions.

basicmaster commented 7 years ago

Mhhh....this consists of the complete FEC lib and also builds all the test tools. I think we should not kind of "overload" the repo with the complete lib. @mpbraendli stripped the lib down to a slim version which only consists of the needed Reed Solomon codec: https://github.com/Opendigitalradio/ODR-DabMod/tree/next/lib/fec

This would be the ideal way in my opinion. What do you think?

russel commented 7 years ago

Clearly I got overly involved in the build, and didn't follow up properly on the point about the ODR-DabMod use of FEC, which someone had already told me about. Sorry about that. Let's close this pull request off unmerged.

Simply copying the ODR-DabMod version of the FEC code is one option but is it the best in case there are changes. One option might be to create a separate FEC repository to be used as a submodule for the two using repositories.

I investigated the option of using a ready made Reed-Solomon library, but whilst Debian has librscode, Fedora does not, not even if RPM Fusion. So I think we have to embed something, the question is whether to embed something new rather than just the current code in ODR-DabMod and have both use the same new code, maybe by a shared submodule. Or the easiest is, I guess cut copy and paste the FEC code from ODR-DabMod to DABlin.

I guess this is your call @basicmaster but it would be good to get a view from @mpbraendli .

mpbraendli commented 7 years ago

I'm against using submodules because it's going to make building the tools for all users more complicated. The advantage would be that we could more easily modify the FEC code, but it's very unlikely we'll have the need for that. Not a tradeoff that sounds very interesting.

I'm quite sure we haven't touched the RS part of that FEC library since its release in 2007 :-)

Summary: I'm also in favour of copying https://github.com/Opendigitalradio/ODR-DabMod/tree/next/lib/fec

russel commented 7 years ago

Given I am not a great fan of submodules that sounds like a 3–0 choice. I'll do the copy. If anyone does analysis of the code and finds improvements, we just coordinate two sets of amendments. I'll get on with this now.

basicmaster commented 7 years ago

I had prefered a separate FEC Lib from the package sources as well, but I did not found one. As it is only a small lib (at least the part needed by DAB+) it is reasonable in my opinion to include the lib. Furthermore I do not really expect that there is anything that will have to be changed etc. in that lib. So for now I think this is the best way. And of course, as you said, sync the two copies if there should nevertheless be an improvement.