aboutsummaryrefslogtreecommitdiff
path: root/news
diff options
context:
space:
mode:
authorkaotisk <kaotisk@arching-kaos.org>2024-10-20 07:57:54 +0300
committerkaotisk <kaotisk@arching-kaos.org>2024-10-20 07:57:54 +0300
commita2ae752641c5b97e24bba94815e3adca662689f0 (patch)
tree27b17e597498d585ffb579371a1017424c2d2f9d /news
parente02c5d91baad8678ef980390a47c16fddac016ae (diff)
download01-NEWS-a2ae752641c5b97e24bba94815e3adca662689f0.tar.gz
01-NEWS-a2ae752641c5b97e24bba94815e3adca662689f0.tar.bz2
01-NEWS-a2ae752641c5b97e24bba94815e3adca662689f0.zip
Added 1729396343-radio_station_emulator with Radio Station EmulatorHEADorigin/masterorigin/HEADmaster
Diffstat (limited to 'news')
-rw-r--r--news/1729396343-radio_station_emulator93
1 files changed, 93 insertions, 0 deletions
diff --git a/news/1729396343-radio_station_emulator b/news/1729396343-radio_station_emulator
new file mode 100644
index 0000000..ce128dd
--- /dev/null
+++ b/news/1729396343-radio_station_emulator
@@ -0,0 +1,93 @@
+Radio Station Emulator
+======================
+
+First of all, since you are reading this at most probably the web/internet, let
+me clarify that the "radio station" part is referring to a webradio station, a
+station that resembles the classic "radio" that plays on the FM/AM and other
+bands which instead of transmitting signal to the airwaves, it actually streams
+data over the internet.
+
+Secondly, the "emulator" part means that the particular radio station we are
+going to talk about it has mainly pre-recorded shows to play on its program.
+Live programs are also possible in this emulator by extending the core idea but
+to keep it simple and trully emulator we will only consider the pre-recorded
+shows, for ease and to not create a hybrid emulator, in the sense that sometimes
+is an emulator, some other times is not, cause it actually plays live.
+
+The main goal is to eliminate the streaming of data in its synchronous form and
+make it asynchronous. One of the main problems moving from streaming the data
+the audience is supposed to hear is that with no synchronous streaming, we would
+be unable to synchronize the audience in the same way radio stations are doing
+this.
+
+At the current time this is getting written, the link to the website
+https://radio.arching-kaos.com will land you to the implementated idea we are
+here to talk about.
+
+While being analytical to this point, the solution to the problem won't be of
+the same degree of analysis. For this, a thesis paper is being developed but I
+am eager to share the news about it and talk about how the emulator works.
+
+Assume the pre-recorded shows and that these shows are played on after another
+on a radio station. If new content is not added, the list of these shows is
+repeated from the beggining.
+
+To make the asynchronous part, we need to have each show ready to be transfered
+to the audience. For convenience and for further expanding of the project, we
+would be having some metadata files, describing somethings about each show and,
+also, point the audience to the actual show. These metadata files, would need to
+let the audience about some key elements for later use. The most important parts
+are:
+1. date of publishing,
+2. duration,
+3. pointer to the show,
+4. the format of data that the show is stored in.
+The third and fourth parts are for the audience to be able to play the shows.
+The first and second ones, we will need them later for calculations.
+
+Now, think that these metadata files are referenced from another file that holds
+the list:
+of them, with to more elements:
+1. date and time of first appearance of this list and
+2. total duration of the list.
+
+To make the asynchronous, synchronous, we will need to calculate how much time
+has passed since the playlist started playing for the first time. Subtracting
+these two timestamps, we would get the number of seconds that have passed
+since.
+
+Timestamp(now) - Timestamp(playlist) = SecondsPassed
+
+Dividing the SecondsPassed with the total duration of the list we would now the
+times the list was fully played (the integer part of the outcome) and a ratio
+of how many seconds have passed since the latest start from the beggining of the
+list (the decimal part).
+
+SecondsPassed / TotalDuration = TimesFullyPlayed + K
+
+where TimesFullyPlayed is an integer/natural number
+
+K = SecondsPassedSinceLastStart / TotalDuration where 0<=K<1 which also means
+that SecondsPassedSinceLastStart > TotalDuration
+
+Finding the TimesFullyPlayed + K part would be easily calculated if for the
+ratio SecondsPassed/TotalDuration we would keep the integer part of the outcome
+and subtract it from the actual ratio. This would leave us with K which to
+convert back to seconds, we would multiply it by the TotalDuration which would
+be the amount of seconds passed since the last repeatition of the list.
+
+Knowing this amount of seconds, we would manage, knowing the durations of each
+show, to calculate which show is already played, which is not and which is the
+one that the audience is supposed to hear and the moment of tuning in.
+
+This part could be achieved by looking for each show in the list, effectively
+iterating until the point that the SecondsPassedSinceLastStart is greater than
+the summary of the durations, that we have already iterated in our process.
+When this condition is met, we get the current iterated show and load it.
+
+Finally, we sync on that show, by subtracting the summary of the previous shows'
+durations from the SecondsPassedSinceLastStart and we start playing the current
+show starting at the amount of seconds we just calculated.
+
+And we are back in synchronicity!
+