Comments (14)
from eti-stuff.
Hi @JvanKatwijk ,
Thank you for your comment! I'm glad to hear it. 😄
Regarding your suggestions:
-
The use of a listening socket, in my personal opinion, is less elegant and more complex to implement. For sure, it will be more flexible. But using an unidirectional protocol it's in fact irrelevant. If you need to use the network, then you can use tools like NetCat or SoCat to achive it. In any case I'll review the example 6. Perhaps I'll modify my opinion.
-
Instead of adding a new thread, just to receive only control commands, my idea is to use the main thread. The checking of new commands can be done only time to time. Perhaps each 100ms (10 times a second). So, this doesn't disturbs any other process. What you think?
-
My concern now is about the "re-tune" when changing the frequency. You think that the current code will work as expected when I call to
deviceHandler::setVFOFrequency()
from the main thread?
Regards.
from eti-stuff.
from eti-stuff.
from eti-stuff.
Hi @JvanKatwijk ,
I really appreciate your feedback, thank you!
First have a look at the example in dab-cmdline
I'll do! 😄
i wouldnot recommend adding a timer interrupt for polling commands
This isn't my idea. The current mainloop is doing sleeps...
https://github.com/JvanKatwijk/eti-stuff/blob/master/eti-cmdline/main.cpp#L409
My idea is put here the code to check if new incoming command are in the control file waiting to process it.
I think it's not a bad idea, right?
no it is not sufficient to just set the vfo, the whole processing chain has to be rest and restarted.
😢
My objective isn't "restart" the driver, only change the frequency. This is required for a fast frequency change. For sure, I feel I need to call to driverHandler::restartReader(), and before stop the processing thread. However, I susposed that will be sufficient with this pseudo-code:
::changeFrequency() {
driverHandler::pause();
driverHandler::setVFOFrequency();
driverHandler::restartReader();
}
You think this makes sense? Or am I completely wrong and none of this is possible?
Regards.
from eti-stuff.
Hi @JvanKatwijk ,
The example 6 was developed some time ago for someone who intended to
create a remote handling facility for dab-cmdline. The tcp-handler
can be used almost immediately for eti-cmdline. Obviously the command to
select a service should be removed. There is a command
to set the gain of the device as well.
Ok. I'm starting to review the example 6:
https://github.com/JvanKatwijk/dab-cmdline/tree/master/example-6
Changing the channel is a major operation for the backend and brings
disruption of the output (obviiously)
But, as the output is ETI-NI, my intent is to do the change without interruption (perhaps some NULL frames in the middle). The player will handle after the change (that's the one has requested the change!).
In my opinion it is the most flexible solution and can be integrated with
some "ifdef" constructs in the current eti-cmdline implementation easily.
However, it is your choice
I'll try to be clear and safe.
Thank you!
from eti-stuff.
from eti-stuff.
Hi @JvanKatwijk ,
Since the eti-cmdline software was built with the idea that a frequency was
fixed when starting, you should at least have a look
what possibilities there are for the main controller (Radio in dab-cmdline)
to stop and restart
Thank you for all this info. I think now that it can be more complex than initially I feel.
In any case, what I really like to overcome is the reinitialization of the driver. For example, using the RTL-TCP driver I don't like to close the TCP socket, just send the ChangeFrequency command. However, it's clear than some parts of the bitstream will be lost.
Regards.
from eti-stuff.
from eti-stuff.
The design is push-based. The clock is the device clock. If the device does
not provide samples then no output will be genersted. Even further: if
there is no timesync, then no data will be send to furthrr processing
parts. If you want a continuous output stream, then you have to redesign
such that the rti generating part is the driver. Complete rewrite.
Yes! I know it. And I have thinking on this. My conclusion is:
- When one command "Change Frequency" is executed, then the diverHandler is stopped and incoming buffer is flushed. Until new data arrives again, there will be no new data out. This will be detected by the DAB player as a simple "bitstream interruption". But this isn't a problem because it needs to "restart" to the new frequency when new data starts to come.
Therefore, no problems in common environments. Only when a SYNC output will be required the problem needs to be targeted. And for this special case (a total different issue, commented in #26) I have one idea to target it... (I write in the other there as here has no sense).
Regards.
from eti-stuff.
Lars18th: making any progress?
from eti-stuff.
Lars18th: making any progress?
I'm very busy. However, with a lot of ideas. I'll prepare some implementations soon.
Keep on hold!
from eti-stuff.
What does "soon" mean here? It was 5 months ago...
from eti-stuff.
closing this
from eti-stuff.
Related Issues (20)
- Update info of RTL-TCP input HOT 8
- [Suggestion] Windows version for the backend HOT 7
- Add option for time sync timeout HOT 3
- rawfile from optical media not working HOT 6
- eti-cmdline/devices/rtlsdr-handler/rtlsdr-handler.cpp segfaults if device not in HOT 1
- obsolete directories HOT 3
- eti-cmdline: PIPE support for changing the frequency HOT 5
- eti-cmdline:facing audio glitch HOT 7
- eti-cmdline: not able to generate DAB+ ETI file HOT 20
- Compiling eti-commandline in Ubuntu 18.04 HOT 7
- [eti-cmdline-rtlsdr]: fibquality gets 0 on RPI3B HOT 7
- Can't compile on Ubuntu 18.04 HOT 2
- eti-cmdline: parameters -S and -h missing HOT 2
- Compile error in 'eti-cmdline' with -DRTLSDR=ON HOT 4
- FR: System Date/Time from Ensemble HOT 4
- segfault invalid next size HOT 3
- repeat after EOF for xml broken HOT 4
- rapidxml::parse_error in eti-cmdline-xmlfiles HOT 1
- eti-cmdline-rtlsdr does not find DAB+ channels, dab-scanner-rtlsdr shows HOT 17
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 eti-stuff.