You are browsing as a guest. Sign up (or log in) to start making projects!

10h 6m 26s logged

WebOS 2 Devlog #17: Media player + Audio spectrum widget implementation

It has been a massive coding session. And I barely managed to keep the time below 10 hours and I still went over it. But, on the bright side, the OS now has a fully functional, media player and an audio spectrum widget! In the media player, anyone can listen to radios, and lots of music. But the reason it took 10 hours is because implementing these stuff required facing some serious bugs-some of them for genuinely stupid mistakes-and rebuilding the audio engine the right way (you’ll see what I mean). Here is a breakdown of how these new features work, what went wrong, and some other stuff:

Overview of features

The Media Player:

The new Media Player is a audio application that routes requests to three distinct APIs to fetch music that the user can listen two:

  • Audius: This is a “decentralized music streaming platform for artists, labels, and fans.” And it’s free! I fetches some of the music from this API.

  • Radio-Browser: This is a platform that is, in a nutshell, Wikipedia for radios. I fetched thousands of live, global radio broadcasts using this API

  • Apple iTunes (Preview): This was a golden find because I didn’t know this existed (not for free anyway). This API pulls top hits and previews of music. Granted, it’s not full music tracks but the songs are much more famous and popular.

The Audio Spectrum Widget

To complement the player, I also added an Audio Spectrum visualizer. It uses the Web Audio API, or more specifically, its AudioContext and an AnalyserNode to get the frequency data from the audio element. That data is then mapped to an HTML5 element. Using requestAnimationFrame, I made it such that the spectrum repaints 40 individual frequency bars roughly 60 times a second, which creates the audio visualiser waveform thing.

Challenges

  • The Geolocation failure:

The OS was originally hardcoded to fetch radio stations from my address because I hardcoded that for testing purposes. But I stupidly forgot to remove that so when attempting to make this dynamic by using vpns I spent like 40 minutes trying to figure out why ut kept showing stations from my local area and not japan (where my VPN was connected to). And the reason for that is the hardcoded address I mentioned earlier. Moreover, some of the API queries were too specific, causing the media player to return empty for smaller regions like the Bahamas. To fix it i used the BigDataCloud API to quietly ping the user’s IP address, cache their true country code, and inject it into the API queries.

  • the broken audio spectrum:

Initially, the audio visualizer was completely blank. Even when fixed, the baseline would just disappear the second music started playing. The canvas drawing logic was also aggressively using clearRect to wipe the entire widget, which erased the idle state baseline. To fix it, I changed the baseline math so that the baseline sits firmly at the bottom of the widget. I also remade the drawing loop to explicitly redraw the baseline before checking the isPlaying state, so the frequency bars can work smoothly.

  • retro theme problems:

I completely forgot about the retro theme as i was just focused on building the player and the widget. So, in the end i had to make the stuff retro theme aswell. I encountered some problems there like some white on white text and some styles not applying which turned out to be because my dumbass brain mispelled the ids and classes

  • Oh, and I found some other big bugs. The dragging engine was hella laggy. Like the response time was like 3 seconds before it registered. I would go deeped but im abt to cross the 4000 character devlog word limit but in a nutshell I realised it was because the mousemove event listener was directly updating the inline CSS (style.left and style.top) on every single microscopic mouse movement so it was really laggy.
0
3

Comments 0

No comments yet. Be the first!