Custom audio players

We’re looking for something like the fixed position player in your published example: http://zirafa.github.io/pushtape-player.js/demo/fixed-position.html

But, I did find this player, which is similar: https://github.com/lucasato/Sticky-Responsive-Audio-Player-Jquery

We’re working on building something in as a premium option - but want to make sure it works natively with LibreTime.

Let us know what solutions you’re thinking about and how we can collab on this.

I’ve created a webcomponent audio player for that : https://dascritch.github.io/cpu-audio/

Licenced in GPL
You can see it in action at http://cpu.pm . The sticky player may be seen when you scroll out the in-content player out of view.

We are working to adapt it for streamed content

1 Like

Have you looked at the webcomponent audio player referenced above? Curious if there’s something already built that could be extended.

@djtonyz Is the player you’re building going to be part of Radio Station plugin or could it be a stand alone project?

Think that ideal would be to collaborate and funnel resources into a player all projects could use. Extending one of the webcomponent players might be a good way to go?

Would be part of the plugin - an “add-on” that needs to be a plugin for WordPress. Regardless of whether it’s built inside or outside of Radio Station, it still has to be built for multiple CMS’s. There are already competing players in the market that are being used, so I don’t see the value of trying to compete with the player. And, our users want to take the LibreTime stream and port it into WordPress as well as utilize an API going in/out of LibreTime to add/publish show schedule, playlists, and DJs/Hosts or the reverse if it’s being done in LibreTime. We want someone to use Radio Station as the defacto WordPress plugin that brings LibreTime content into WordPress. So, if someone were to install it and set the API key, once they published their Shows in LibreTime, it would automatically publish the Show in Radio Station. Same for Playlists, but we’d have to figure out how and when to pass and publish playlist meta data based on the air date or whatever.

I think there’s agreement to collaborate around a player that could plug into multiple OSS projects and platforms. Could we build on any of the ones referenced in this discussion?

https://radio.co/ provides good inspiration for customizable radio players. Wonder if there’s good source material to replicate.


@dascritch The webcomponents player you developed is working here? https://cpu.dascritch.net/

Do you think it could be extended to incorporate some of the functionality referenced here?

We must see what is missing and can be asked.

Today, it can be personnalized (color, font, mode) https://dascritch.github.io/cpu-audio/LIVE#configurator_html , there is chapters and playlist features, an i10n minimalistic service, and mostly, trying to keep using standard HTML5 API features.

This looks very promising! So will this play LibreTime streams or is there still work to be done on that end? Possibly other folks building or needing this type of player could collaborate or contribute?

I was able to play inside an icecast stream.

But it will indefinitively keep in ram the downloaded stream…

May be problematic for smartphones ?

Le mar. 4 févr. 2020 à 20:18, Gus Austin via LibreTime libretime@discoursemail.com a écrit :

Circling back to this as some of the folks/projects talking here have overlapping goals.

LibreTime has a couple issues in the queue -


Radio Station plugin for WordPress has a few related to audio players -


OpenProducer platform for radio stations and podcasters would like to bridge these together -


Assuming all these features could be provided by Radio Station + LibreTime (once there’s an API), we can direct resources towards development with a bounty, paid beta and/or series of hackathons directed towards radio stations and podcasters.

Would be great if we could bring all involved contributors together in the #openproducer channel in https://slack.opencollective.com/

So ultimately there are a bunch of different issues here.
The primary one is LibreTime provides widgets that use libraries that seem to not work reliably on all systems. The widgets and radio page are the most obvious way for people to stream but in reality they could use any of these players with LibreTime because most of them should be able to stream the Icecast stream LibreTime provides. Most modern browsers can stream a mp3 stream just by opening up the file.

The Sticky Audio Player is something that would need to be implemented on the front-end website and our widget will never support that out of the box as per the reasons above.

What we need at this point is for someone to deep dive into the Widget/built-in audio player and test it on a whole slew of platforms and identify where it fails and then suggest a solution that works for all of them that we can resolve it with.

So the sticky audio player would be a separate project (from the web player that ships with LibreTime)?

Would this be a LibreTime feature/project? Part of the Radio station plugin project? Something else?

As noted in this discussion there are several existing solutions or projects with similar goals. How can we reduce duplication and focus resources on something that can be shared across all projects?

I think that Radio station plugin is a separate project in and of itself but the web player plugin they are developing should be stand-alone and at the same time compatible with LibreTime and other radio streams.

Really the widget is kind of a hack for people who don’t have their own solution built into their website like what hopefully the radio station plugin will provide or whatever other custom player.

At this point we just need someone to do full testing on the widget we provide with every imaginable browser and operating system combination, report their findings and then make a decision if there is something better we can plugin that will replace what we have. It could be a rather involved process.

I don’t see the widget being an essential part of LibreTime because the functionality can be easily duplicated elsewhere but in reality a lot of people using LibreTime depend on it I think because they don’t have other solutions in place already. So it is a useful component and it’d be good to provide the best option that we can out of the box.

Right now, it looks like they’re releasing it as part of their pro version, but maybe I’m missing something as we were talking about collaborating on a player earlier in this discussion -

There are players that looked promising like the webcomponent player @dascritch was working on

Wonder how close Azuracast comes to something we’d want to include in LibreTime. Maybe there’s an opportunity to incorporate what they’re using and collab with their team https://www.azuracast.com/about/screenshots.html#public-player-page

@guasaus As regards the player review thread, you’re right it is a more general review of Players rather than just for Pro. Whatever we decide upon will be in both Free and Pro versions though, but we may split up the player features for those. For example, currently we have decided that a widget player will be in the free and a sticky header/footer player in Pro. A popout player could be added to the widget later and might be in either.

As regards continuous playback, I have an experimental side project that uses javascript History API to allow for navigation and page loading on a site without playback interuptions. (This works between WordPress pageloads, but the same javascript code can be applied on other platforms.) As far as I know this hasn’t been possible before without going “headless” or changing CMS platforms.

@robbt Curious what underlying library the LibreTime widget uses?

So this could be a potential solution? If I’m understanding correctly, the continuous, sticky player doesn’t really depend on Radio Station plugin or a particular CMS. It would be nice to include something you can enable w/o custom theming, but not a requirement.

If that’s the case, can we work towards a common solution?

@gusaus I am playing with some code to try to use a common HTML element structure and styles for the player, but with the option of using one of a number of different javascript libraries for the player script. (Amplitude, Jplayer, Howler, Media Elements.) I’m doing the coding in a WordPress context but depending on what I end up it may be useable or modifyable for other platforms.

As for the continuous playback, yes that is a potential solution I am keen to pursue. The History API transition loading would be a cool WordPress plugin in it’s own right, as not having to convert your WordPress site to a headless javascript loading one just to make that happen is a real plus.

But I haven’t yet tried combining those with a Sticky Element. There is an additional challenge… Since with this method the current player could be “within” each of the loaded pages, there needs to be some additional code to communicate between player instances so that the any newly displayed player controls would be able to pause the existing player audio.

Further from this would be later solving the problem of possibly having multiple tabs playing audio from a site… There are websockets and things to communicate between windows and stop a stream in another player so this shouldn’t be too hard either, but that gives you an idea of what needs to be solved over time.

Most of this is over my head (even with coffee) but my takeaway is there’s some overlap with what’s on the Radio Station/WordPress roadmap and needs of both LibreTime and AzuraCast.

Would it be possible to scope out x-project solution? https://github.com/OpenProducer/openproducer-platform/issues/16#issuecomment-623311641

@gusaus As I go I’m trying to write it in a way that works both within WordPress and without it, but this means adding a bunch of extra functions and function checks just to replicate some of what WordPress does already. Am making good headway though.

1 Like