Sharing some findings generally

Helle

New member
Hi everyone,
writing in order to share to some findings during implementation of the RadioBOSS Cloud maybe it helps someone.

for the autodj:
I think, that the very first thing everybody should do is to have a clean Library wirh all ID3 Tags and if possible Covers. I recived the Library of a friend which was not the very best in terms of data quality, even if all songs were baught correctly... :rolleyes: Therefore I'd suggest to use, if you don't know allready know MusicBrainz Picard - taking some time to get familiar with it; ands it's plugins will do most of the job for you. Additionally you can safe de AccousticID in the Tag which you might want to use later on in the front-end (it opens a shit lot of possibilities).

player on the website:
It's cool that the platform provides an embed player for a website, but in my case I don't implment 3rd party code on my site and on top - <iframes> I don't like. 🥸
There are also a few requirements from buisness in terms of compatibillity, accessibility & hardware - like always. Ah & Budget 0....
In order to display any kind of stream, manipulate and play it, the best approach is to do it on byte level. But here in my case the dependecies say: NO
Why? In order to encode or decode any stream you need hardware recourecer - on server or on client side. In my case no money for server rescources and our listeners should be able to enjoy also on low performance smartphones.
To discard the last one I tried many different approaches using:
Unfortunately in order to implement it taking all requirements into account - would take in my case 2 months full time 😬, thusthe best way was to use the native <audio> implementation of each vendor. Which has it's tricks across Browsers but it can be mastered easyly - onfortunately this won't give us that much power if we want to manipulate/use the srteam on bytecode level. (Anyway if it would be possible we would need to tahe a deep dive into encoding, streaming, buffer, connection speed etc.. 😅)
In my case using the
Web port link | RadioBOSS Cloud > Settings
as src and setting the type to:

type="audio/mpeg"
did the trick, accordingly you can manipulate it

By the end, until now the streaming searvice is robust and works as expected. I'm using iceast and it's working perfectly - it's a bullet proof technology. If you do some reverse engeneering on the page that's provided you'll find easy the information you are looking for- anyway the key is to have clean Id3 tags.....
 

djsoft

Well-known member
Staff member
thusthe best way was to use the native <audio> implementation of each vendor
Using <audio> tag is a viable solution. You can have streams in MP3 and AAC (RadioBOSS Cloud allows using multiple output formats). If you detect what web browser is used, you can use either MP3 or AAC stream - wither of those is always supported.
 

Helle

New member
Using <audio> tag is a viable solution. You can have streams in MP3 and AAC (RadioBOSS Cloud allows using multiple output formats). If you detect what web browser is used, you can use either MP3 or AAC stream - wither of those is always supported.
True!

In the requierements based on our usecases of target audience; mostly connect with low/mid performance smartphones throu browser.

Allthough most users are on Andriod / Webkit; which handels <audio> quite awesome - it comes often to memory 🤮
Thus using Fetch API and pusch to Buffer would give more freedom and if correct implemented it would lower the memory overuse... but as mentioned it would take too long to implement
 

Helle

New member
It could be a good idea to create the app that will play the stream.

hey!
If you mean a native App working cross plattform would be too much work, anyway currently most of my teams which develop Apps which requeirements meet usecase, develop with Kotlin which would use in any case HTMLAudioElement - but in any case I can just recomend Kotlin for corss platform mobile dev....

BUT :geek:
I just found


looks pretty solid, and I'll take the last H. of today to implement it on our own client-side player:

We found an issue on IOS when using HMTML5 audio on Safari when playing stream in background and it gets interrupted by an other audio which is beeing blayed; e.G. Phone call, WhatsApp audio etc...
- when resuming automaticall Audio buffer gets 🤪🤪🤪🤪

This is something I should have known as "Issue" is old and to avoid it, we created soundsprites long time ago; Thought this was already takeled by vandors... anyway thought somebody should have a ready to plugin class for that and voilá howler.js found....
 

djsoft

Well-known member
Staff member
develop with Kotlin which would use in any case HTMLAudioElement
This is not necessary. You can use any means to play the audio. Our test radioboss.fm app did not use it, we used other audio engine for playback. The app will be available again soon, by the way.
 
Top