[Discussion] Network Tuner support

[lars18th]

Hi,

I like to discuss about the option to add the option for working as a network tuner.

A network tuner is a simple device that receives some "tunning commands" and sends one "stream" over the network with the received data. One example of such devices are the SAT>IP tuners. See more at: http://www.satip.info/

My suggestion is add to welle.io the option to run in background as a "Network Tuner Server". It can tune any frequency and stream the audio over UDP/RTP packets. Then, any device connected to the network can use it as a Digital Radio Proxy.

You agree?

For a fast development, perhaps a simple extension of the SAT>IP protocol can be viable. This protocol supports DVB-S/S2/T/T2/C/C2, and some people has implemented basic support for ATSC and ISB-T. Then is quite simple to enhance it. My suggestion is support tunning commands like:

"satip://WELLE_IP/?msys=dab&freq=209.936&pids=all"

Some opensource software SAT>IP servers exist, and then will be quite easy to reuse them to implement this function.

What you think?

[stefanheinrichsen]

OK... I was planning to suggest something similar quite soon. Since lars18th has not mentioned it I will speak up as well.

I was thinking about the same functionallty but in a bit more general way. Maybe it is possible to add an option into welle.io to provide several network ports where each port provides a single channel from a how mux on a given frequency.

Not sure if this would be possible in welle.io directly or if it would be more feasible to create some kind of comand-line version of it. Anyhow: I think this would be a really GREAT change. :-)

Also I'm planning to investigate deeper into this field mid of August as I have 2.5 days off then (no kids, no work, just free time).

Best regards, Stefan

[lars18th]

Hi Stefan,

I'm glad you found it interesting!

However, your proposal (streaming different channels) is quite complex: you need then to decode all incoming RF signals. Futhermore, you're streaming even if no listener exists.

In my opinion, the concept of a "Network Tuner" is the best option. Why? Consider these points:

1. The server only streams when some client requests it.
2. Only the frequency resquested by the client is tuned and decoded.
3. One server can serve to multiple clients, with the only limitation of the physical/SDR tuners.

Then, the abstraction of a "Network Tuner" is very powerful. I feel isn't very hard to include this server functionality inside Welle.io, or create a fork focused on this behaviour. And the advantage using some "standard" protocol for the communication is that several clients can start to implement the DAB support with a minimal modification.

For example, if you use the SAT>IP protocol (very well described and documented, and with a lot of implementations and good support), and if the Welle.io project implements the "dab" extension as a server... then is very easy to create a "client". In fact, the only difference about tunning a DVB signal and a DAB signal are: a) the RF modulation; b) the frequency; c) the encapsulation. However, the stream encapsulation used in DAB (ETI) can be encapsulated inside an MPEG-TS. Using this technique (ETI-over-TS) is feasible to extend the SAT>IP protocol to support DAB/DAB+/T-DMB signals. Obviously the RF demodulation is done by the Welle.io software; and the frequency is a mere parameter.

Please, let us to know your opinion. Regards.

[stefanheinrichsen]

I might be wrong but I think normally you have about ~5 stations per frequency. At least in my area there are 13 stations in channel 5C and 11 stations on 11D. You will have to decode the whole multiplex to get the data for a single station. In my opinion you already have the whole data for all those stations on a given frequency. For playing a given station you will need only one part of the multiplex. For a network stream you could provide all of them without much addtional efford.

Also streaming those multiple stations will not happen when no client is connected. The decoding will continue, yes. But this will do no harm, or?

I have no idea how difficult it would be to implement the SAT->IP system.

[andimik]

Forget Sat>IP. We are NOT talking about DVB, but DAB. This is very complex. It took several months even Jan to convince to use ETI.

If you know how to get the ETI stream with Eti-stuff then this would be an enhancement, indeed.

But already now this is implemented in welle.io. Just stream the rawfile over the network. But this causes lots of traffic.

[lars18th]

Hi to all,

First to comment about the complexity of the goal, I like to discuss about the benefits of this functionality. Let me to explain my point of view:

At time, the use of the "rtl_tcp" provides in fact one method for "client-server" functionality. However, this mode is very inefficient. And reasons are three:

1. You need to export all IQ data in realtime that consumes a lot of bandwith.
2. The clients needs to process IQ inputs in realtime that consumes a lot of resources.
3. Even if the data are a simple audio stream and some metadata, the client needs to implement a lot of SDR stuff.

So the abstractions of a "Network Tuner" can simply the complexity in a "client-server" environment. The idea is quite simple: the "server" implements all RF and deencapsulation stuff, and the "client" only receives the data in a bitstream form and it controls the "server".

If you analyze this with the SAT>IP protocol using DVB you can show that:

• The server manages the tuner.
• The server only streams plain MPEG-TS.
• The server can filter the pids on the streamed MPEG-TS.
• The client controls the server, using the well known RTSP protocol (TCP).
• The client receives the MPEG-TS, using the well known RTP protocol (UDP).

So, I see a simple mapping for DAB using this approach. This is my vision:

• The DAB server (welle.io or any other project based on it) can export his functionality as a "tuner server".
• The DAB server can be controlled using some "control protocol" over TCP.
• The DAB server can stream the radio data using one "streaming protocol" over UDP.
• Finally any Radio App can receive DAB signals using this "network tuner".

The mapping is then evident: the protocol proposed for the "network tuner" is one extension of the "SAT>IP" protocol. And here is my suggestion for expanding the SAT>IP URI specification for DAB support:

• "satip://DAB_SERVER/?msys=dab&freq=209.936&encap=ETI&pids=all"

The parameter "msys=dab" indicates to use a "DAB tuner" (or DAB modulation for a multi-tuner), and "freq=" is the frequency to tune in MHz. Futhermore, two other parameters are included: "encap" is the modus to server the stream, and "pids=" is the standard pid filtering control used with DVB tuners. My proposal for the behaviour is then like this:

• "encap=ETI" and "pids=all": This streams all the ETI received bitstream encapsulated over a simple MPEG-TS (as some satellite transmissions do).

• "encap=IQ" and "pids=all": This is for convenience, and do the same as "rtl_tcp" do: encapsulates the IQ stream over a plain MPEG-TS (identical as the ETI-over-MPEG-TS but with IQ data).

• "encap=DVB" and "pids=X": Here some "reencapsulation" is done. The output is a valid DVB MPEG-TS stream with the radio content. It has one simple PAT table, one minimal NIT table, and one PMT for each program inside the DAB mux. Here the SID number of the program is the corresponding to the DAB service number. And here the client can "filter" the stream for receiving only the desired data.

With this approach can be very easy to program Radio Apps that can receive efficiently the stream. Futhermore, apps not focused on DAB or radio can now process the stream, as it's a valid DVB stream. For example, you can imagine to use VLC or FFMPEG for receiving DAB radio.

Perhaps the Welle.io isn't the best project for develop this functionality. However, I found it the most flexible DAB processing project at time, and I feel it can be a good starting point.

What you think?

[lars18th]

HI @andimik ,

We are NOT talking about DVB, but DAB. This is very complex.

In my opinion, and it's only a feelling, if we encapsulate DAB data over MPEG-TS as DVB we can open the number of potential software clients.

I don't found it a very complex goal, as the concept is an ETI-NI to DVB-MPEG-TS. I hope this doesn't offend you! DAB is Digital RADIO, and not Digital TELEVISION like DVB. However, I don't see any drawback in develop this ETI-NI to DVB-MPEG-TS. And using it, it will be very easy to incorporate it to the SAT>IP protocol.

For example, at time exists the "ETI ni2http" inside the ETI-tools project: http://github.com/piratfm/eti-tools

Perhaps one first step is develop the "ETI ni2mpegts"... I don't know.

[andimik]

I know DVB is used in professional transmission for ETI over Satellite (NRW or Bundesmux via 23,5 East or Italian or UK muxes over others)

And I understand all your suggestions and agree with them. But believe me, it was very hard up to now having the first consumer products and software to handle with ETI streams.

And if you go a step further people are asking for an implementation in their Linux Settopbox as well...

[lars18th]

Hi @andimik ,

ut believe me, it was very hard up to now having the first consumer products and software to handle with ETI streams.

Yes, this is one reason for supporting the idea of the "Network Tuner" for DAB. This can serve ETI streams, but the most powerful functionality is provide encapsulated MPEG-TS streams with the format of a DVB MPTS with only radio streams (and metadata, of course!).

And if you go a step further people are asking for an implementation in their Linux Settopbox as well...

Sure! And if you provide DAB signals over SAT>IP then any software/hardware client (Linux, Android, PC, STB, etc.) can tune the radio signals... this will be true because all RF and deencapsulation stuff is done in the server. Clients only receive TS streams!

Here a very tricky mock-up to demonstrate the functionality:

1. Get one DVB-S satellite tuner, and tune one satellite transponder with DAB ETI encapsulated data.
2. Filter the pid with the ETI data and stream it to a FIFO file using the "ts2na" tools from ETI-tools.
3. Deencapsulate the DAB stream with the tool "na2ni" with the previous FIFO as input and writing to new one.
4. Then using the "ni2http" tool read the second FIFO file and configure the tool for HTTP access to all the radio services in the ETI stream.
5. Configure one instance of TVHeadend with IPTV and create one MUX for each URI of the HTTP server in the "ni2http" tool. Also set one SAT>IP frequency number for each IPTV input streams.
6. Then use any SAT>IP client to "tune" your DAB radio using the fake frequencies you set in the previous step.

That's all! ;) But this is only a mock-up. It ins't a true demo. Several things aren't resolved. However, it demonstrates the concept. And the basic is simple: with a DAB SAT>IP server, the client can be ANY DVB application.

I hope someone found this interesting. Regards.

[andimik]

These steps under the mock up section are very easy and this works now without any further implementation. But this is restricted to only those eti streams which are sent as data over DVB. And this means Astra 4A on 4.8 East. I have also tested this in the past and you even can download one sample eti file from an Ukrainian programmer and hardware developer (I guess you know who)

But DAB is not DVB meaning the hardware and software has to deal with the special form of AAC (960 frames)

If you are a programmer you are invited to open a new git project to encapsulate all DAB streams to a DVB stream.

[lars18th]

Hi @andimik ,

But this is restricted to only those eti streams which are sent as data over DVB

Sotty, my description is a simple mock-up. To go further the Welle.io must to implement the EIT-output stream. Then will be possible to replace the "ts2na" tool with Welle. However, if you know some other SDR DAB radio tool compatible with RTLU with this functionality, please, let me know!

If you are a programmer you are invited to open a new git project to encapsulate all DAB streams to a DVB stream.

My target is the SAT>IP support. I don't know a lot of DAB. If Welle.io developers can provide EIT-output over the network and a remote control API (for receive interaction from programs, and not only from users), then will be possible to work on a "DAB-to-DVB proxy" tool.

This sounds funny to you?

[andimik]

I fear you don't understand the concept of welle.io. It is a software for listening to radio. Of course some implementations were added (like rawfile support) but all of them are for developers to test the basic functions of welle.io.

I personally disagree to implement server functions to a software which is a frontend.

So please install other tools

You can get eti with Eti-stuff and get all streams with dablin_gtk. This combination works well here.

[AlbrechtL]

@lars18th Thank you very much for the proposal about the network tuner approach.
@All Thanks all for the discussion.

I think before we continue with the discussion about the pros and the cons I would like to ask if somebody has interests to implement some advanced network functionality? If there is a developer we can start the discussion again.

[lars18th]

Hi @AlbrechtL ,

My respect for your good work on this project! I pause to put more comments to this thread until some other developer would like to contribute. :)

However, only one thing: Please, can you consider to incorporate a simple ETI streaming? If Welle.io can do this it will be more easy to have a real realtime source of DAB data and start to develop some tool using this stream.

You agree?

[andimik]

But then you need the welle.io also as client. So AlbrechtL should first focus on eti decoding.

[lars18th]

Hi @andimik ,

I hope AlbrechtL doesn't bother if I continue with the conversation. I apologize for it!

But then you need the welle.io also as client. So AlbrechtL should first focus on eti decoding.

Not really, as the welle.io is processing: 1º) the "RF signal"; 2º) the "bitstream"; 3º) the "encoded service". Then, if we don't count the fact of the input source (for example from "rtl_tcp"), the ETI is obtained after the RF signal processing. Right? Then welle.io can stream the "bitstream" (ETI unprocessed) or the DAB stream (ETI processed). I don't know if this streaming will be ETI-NI or ETI-NA. But in any case, to start some project targeting a "DAB-2-DVB PROXY" it is required to have a real ETI input from live broadcasts. And in my opinion here the welle.io can contribute.

I hope AlbrechtL will agree to add this functionality. Thank you!

[andimik]

As you know welle.io even does not have a recording function, so why focus on things which can already be done with other existing software and is restricted to very few users?

In my opinion it makes no sense now, maybe in a later state.

[lars18th]

Hi @andimik ,

I admit that this function can have low priority. However, at time welle.io is one the best multiplatform and user friendly DAB client based on SDR. And it's very easy to setup. Futhermore, the recording function can be "complementary" to the streaming function. The only difference is the output medium (network or file). But in any case, the relevant question is about what to record/stream: the ETI bitstream? The processed RF signal? The service? I feel several users like to "record" services/programs and not ETI. But in my opinion, for developers it's best to record ETI.

Perhaps the most valuable function to implement now is a simple recording of the IQ values. Now welle.io can run with the "-F" parameter with I/Q RAW file as input. Then it be consistent to running from "rtl_tcp" or another source and "save" all incoming data in a file. I feel this can helps other for experimentation. For example, for capture/replay using only welle.io as the main tool.

AlbrechtL, what is your opinion? Regards.

[viktorgino]

Would a web server with a HTML interface and a REST API that could be used to control welle.io + a audio stream not be a better solution? Less effort creating it and there are a lot more clients that could support it. I understand that this way you wouldn't be able to stream complete DAB blocks over the network, but I don't think SAT IP and other alternatives are widely implemented enough to be a useful feature for most of the users at this stage.

[lars18th]

Hi @viktorgino ,

Would a web server with a HTML interface and a REST API that could be used to control welle.io + a audio stream not be a better solution?

This is the same solution as I request (if we remove the SAT>IP protocol).

The only difference I see it's this: I feel you like to receive the MP2/AAC stream of the service, and I like to receive the ETI stream. However, when the HTTP server and REST API will be available, sending one type of stream or another is quite easy. In fact, it's possible to send both!

I found this discussion very positive. And I hope AlbrechtL agree to implement this kind of HTTP+REST API interface... with both MP2/AAC and ETI outputs.

In any case, I add my +1 to the idea of recording (save) the incoming IQ samples.

Sorry AlbrechtL if my comments are requesting a lot of work. I'm only suggesting ideas, and expressing my oppinion. Your work is very good! Thank you for your effort!

Regards.

[andimik]

Maybe this explains a bit more why this quite difficult, but finds a solution for streaming.

https://github.com/Opendigitalradio/dablin/issues/4#issuecomment-192963188

Once again: There are already tools allowing ETI streaming, so Welle.io does not need it in the near future.

[lars18th]

Hi @andimik ,

Thank you for pointing to this interesting information! You're right: this isn't an easy task.

Once again: There are already tools allowing ETI streaming, so Welle.io does not need it in the near future.

Regarding this, I just want to say that Welle.io is multiplatform, and very easy to setup (with support for a lot of inputs). So, including the function to output PCM (as DABlin does) and ETI stream (as does dab2eti) it will simplifies a lot. Perhaps AlbrechtL will consider to incorporate these functions from the original projects.

Thank you all for your good comments!

[AlbrechtL]

Thanks all for the discussion. Because there are no new comments for 4 weeks I close this issue. But you are welcome to use this issue to discuss this topic.

[lars18th]

Hi @AlbrechtL ,

I hope you will implement in the future the streaming function. Thank you for your effort and this good tool!