diff options
author | kaotisk <kaotisk@arching-kaos.org> | 2024-10-20 07:57:54 +0300 |
---|---|---|
committer | kaotisk <kaotisk@arching-kaos.org> | 2024-10-20 07:57:54 +0300 |
commit | a2ae752641c5b97e24bba94815e3adca662689f0 (patch) | |
tree | 27b17e597498d585ffb579371a1017424c2d2f9d /news/1729396343-radio_station_emulator | |
parent | e02c5d91baad8678ef980390a47c16fddac016ae (diff) | |
download | 01-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/1729396343-radio_station_emulator')
-rw-r--r-- | news/1729396343-radio_station_emulator | 93 |
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! + |