eti-cmdline: how to get rtl_tcp working as input device

[nanosonde]

Hi! Could you please give me some advice on how to get the rtl_tcp input working?

[JvanKatwijk]

Can you be more specific? the input port is 1234 I assume you have the rtl_tcp server working

If you touch the connect button it will show a line where you can enter the server address

2017-09-19 15:37 GMT+02:00 chrwick notifications@github.com:

Hi! Could you please give me some advice on how to get the rtl_tcp input working?

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/JvanKatwijk/eti-stuff/issues/17, or mute the thread https://github.com/notifications/unsubscribe-auth/AITzwMFZEx5X6oEtHXqwVWPJ7T-FPwSIks5sj8OIgaJpZM4PcZ7W .

-- Jan van Katwijk

+31 (0)15 3698980 +31 (0) 628260355

[andimik]

Seems he is talking about the command line version. There is currently no support for it, only for the five mentioned under https://github.com/JvanKatwijk/eti-stuff/blob/master/eti-cmdline/README.md

[JvanKatwijk]

Yes sorry I did not notice that. As Andreas notes, rtl_tcp is not standard implemented in the cmdline version but it is not hard to do, so give it a try. I do not have time right now.

2017-09-19 21:09 GMT+02:00 andimik notifications@github.com:

Seems he is talking about the command line version. There is currently no support for it, only for the five mentioned under https://github.com/ JvanKatwijk/eti-stuff/blob/master/eti-cmdline/README.md

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/JvanKatwijk/eti-stuff/issues/17#issuecomment-330640704, or mute the thread https://github.com/notifications/unsubscribe-auth/AITzwN8JIgSCuQIK2JA4OOkl1lSsSVlzks5skBGDgaJpZM4PcZ7W .

-- Jan van Katwijk

+31 (0)15 3698980 +31 (0) 628260355

[nanosonde]

Ok. Thanks.

Meanwhile I have found a way to get it working via rawfiles and a pipe.

I have setup the RTL_TCP server to the desired frequency and gain. Then I have used netcat to connect to the RTL_TCP server port and pipe the stdout to a fifo created with mkfifo.

This fifo file is then used for eti-cmdline-rawfiles: ./eti-cmdline-rawfiles -F ./test -O -

The stdout of eti-cmdline-rawfiles is then piped to the final tool which handles the ETI stream. (In my case ni2http from here ) However, I am now experiencing this weird issue.

Closing this issue.

[andimik]

Your idea does not work. Please forget all normal players. For ETI Frontend you should pipe it to dablin_gtk or dablin.

[nanosonde]

Why should it not work? It IS already working with ni2http as it streams the pure AAC stream to a file or to an icecast2 server. It works with VLC and my Sonos speakers listening to the icecast2 stream.

However, the only problem left is that it plays slightly to slow so as described in the other issue. The question for me is: whose fault is it? eti-cmdline-rawfiles or ni2http

What could be the reason for this?

The other players are of no use for me. My use case is to stream DAB+ (AAC) to my Sonos speakers, because my internet connection is sometimes unstable and the tunein radio station stop playing.

So ni2http is the perfect tool for me.

[andimik]

We are talking about DAB, the fault is the spec ;-)

AAC for files or streams is not the same as AAC in DAB.

[JvanKatwijk]

I had some spare time and added a version of rtl_tcp to the eti-cmdline stuff. Unfortunately, while I can see that there is a connection with an rtl_tcp server, I cannot see the full operation, since where I am right now, there is no decent DAB signal

You could give it a try or wait until monday. Relevant parameters -H hostname -I port -G the gain is NOT in the range 0 .. 100 as with other devices, but in tenth of db

best jan

2017-09-22 18:50 GMT+02:00 andimik notifications@github.com:

We are talking about DAB, the fault is the spec ;-)

AAC for files or streams is not the same as AAC in DAB.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/JvanKatwijk/eti-stuff/issues/17#issuecomment-331500531, or mute the thread https://github.com/notifications/unsubscribe-auth/AITzwGflZxWw3qS1s4_ZuYK2X3Sk241fks5sk-U5gaJpZM4PcZ7W .

-- Jan van Katwijk

+31 (0)15 3698980 +31 (0) 628260355

[nanosonde]

Thanks! Seems to be working for me. It outputs an ETI stream to which I can listen with ni2http. My other issue is still there.

[nanosonde]

This does not work with dablin:

./eti-cmdline-rtltcp -H <ip> -I <port> -C 11D -O - > ./eti-pipe

When trying to play a radio station with dablin, I get:

ETIPlayer: ignored ETI frame with ERR = 0x55
ETIPlayer: ignored ETI frame with ERR = 0x55
ETIPlayer: ignored ETI frame with ERR = 0x55
ETIPlayer: ignored ETI frame with ERR = 0x55

Using netcat, a pipe and eti-cmdline-rawfiles it works:

nc <ip> <port> ./sdrpipe
./eti-cmdline-rawfiles -F ./sdrpipe -O - > ./eti-pipe

Note: The RTL_TCP server has been started with the "-f" option to set it manually to channel 11D.

[JvanKatwijk]

My mistake. It happened that the rtl_tcp handler wrote some stuff to stdout. When piping the output, the erroneously written text preceded the data in the eti file, and syncing was lost.

I tested it writing output to a file, that - obviously - went well, so it took a while before I found out what was wrong

Corrected

2017-09-28 13:25 GMT+02:00 chrwick notifications@github.com:

Reopened #17 https://github.com/JvanKatwijk/eti-stuff/issues/17.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/JvanKatwijk/eti-stuff/issues/17#event-1269580701, or mute the thread https://github.com/notifications/unsubscribe-auth/AITzwFxl_9VllcANtk7M5aTed1fqpdUkks5sm4I4gaJpZM4PcZ7W .

-- Jan van Katwijk

+31 (0)15 3698980 +31 (0) 628260355

[nanosonde]

Thanks.