search

Opendigitalradio / dablin

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

dablin in Debian and Fedora? #7

Closed russel closed 7 years ago

russel commented 7 years ago

The support for DVB in Linux is very high, LinuxTV, libdvbv5, /usr/share/dvb, etc. Is there a possibility of improving the support for DAB/DAB+. dablin doesn't support local transmitter files, and other things to make the user experience good. I wonder if dablin could be updated for Gtk3 (yes I am volunteering) and a format for tuning files agreed (along the lines of DVBv5 perhaps) so that it is possible for DAB/DAB+ UI experience to be like that of DVB-T and DVB-T2 (I am rewriting Me TV). Getting things into the Debian and Fedora (also Arch?) repositories (librtlsdr is already there) would make things much easier. Having to download and compile things such as ka9q-fec is irritating (is this repository being supported, it doesn't appear to have been updated recently).

mpbraendli commented 7 years ago

Hi, I cannot comment on dablin, but regarding ka9q-fec: The code was taken from http://www.ka9q.net/code/fec/ and adapted so that it compiles. I'm not maintaining the project in any way. The other ODR-mmbTools that need fec use it as an internal source library, removing the dependency to the fec shared library. Maybe dablin could do the same, copying it from https://github.com/Opendigitalradio/ODR-DabMux/tree/master/src/fec

russel commented 7 years ago

Processors have moved on since 2007 and if the code has not been updated to deal with this, it might be considered a bit of a liability – but I am not an FEC expert. Searching the Debian packages GNURadio has an FEC package, there is jerasure2, and librscode1. They all seem relatively slow moving, i.e. unchanged in a long while. However, I cannot find then in Fedora.

If staying with the ka9q code, I would definitely ditch the separate repository and pull the code into the dablin codebase given that ODR-DabMux already has. The alternative would be a Git sub-project but that would require changes in both dablin and ODR-DabMux.

basicmaster commented 7 years ago

Indeed Linux has a quite good DVB support and the DVBAPI is great. Regarding DAB a similar API would be great as well e.g. with a subchannel filter similar to the PID filter of the DVBAPI.

I'm not sure if I understand what you mean with "local transmitter files", as you can already use the parameter -C to specify the list of the channels which shall be in the channel list. While in DVB you have FEC/symbol rate/polarisation etc. in addition to the frequency when you want to tune, in DAB you just need the frequency.

In terms of GTK3 (great that you volunteer!), do I get you right that you want to switch from the C++ binding to the plain C lib? This would make sense as the GUI already has to use a workaround to access the link button's label. I just had in mind the previous usage of GLib in another project where there were lots of macros/casts necessary to get it right, so I chose gtkmm here.

Having packets would be great and the FEC lib indeed has been a showstopper since. I also took a look at some other libs like the ones you mention, but they are not that high level like the current one and I don't have deeper knowledge of Reed-Solomon coding. So I think it's time to copy the current lib into DABlin; I will do this soon.

Thanks for your helpful feedback and suggestions!

russel commented 7 years ago

@basicmaster The DVB "local transmitter files" I meant were the ones to be found in /usr/share/dvb. Having a worldwide store of what frequencies multiplexes/ensembles are being transmitted on is invaluable – otherwise you need a DAB/DAB+ equivalent of wscan. Also there is the issue of polarisation, unless all DAB/DAB+ is always transmitted with vertical polarisation.

Antti Palosaari started the rtl2832_sdr driver, within the Video4Linux/LinuxTV context, but it is not clear that it is still being worked on. The OSMoCom folk explicitly separate themselves from his work and emphasise the librtlsdr/libusb route as the right way forward.

I avoid C if at all possible! C++ and gtkmm is just fine – but only if C++11, or better still C++14, is allowed.

I'll take a look at doing a "vendor fork" of ka9q-fec so as to remove it as an external dependency.

basicmaster commented 7 years ago

The "transmitter files" (currently) affect the dabtools and should be discussed there. Discussion about that topic makes sense in my opinion, as the circumstances of DVB and DAB are different.

The SDR lib approach is discussed in Opendigitalradio/dabtools#10.

The FEC lib issue is solved for DABlin as well, so I close this issue here.