Adding player back — Howler Instance Reference

[phemartin]

In v1, a player parameter directly references the Howler instance.

The current API is great, but I found it a bit buggy, and some things aren't supported yet. I can use it to create custom behaviors by directly accessing the Howler instance.

Regarding the bugs, I found that sometimes when heavily manipulating the audio with rate and seek, the player crashes and stops working (requiring a refresh).

This also occurred in v1, but accessing rate/seek directly helped.

@E-Kuerschner Are there any plans to incorporate player back into the API?

Thanks!

[E-Kuerschner]

@phemartin im open to adding an escape hatch method: getHowl: () => Howl for instance, but I do want to resist leaking implementation details beyond that. A goal of mine was to keep the interface abstract so that the implementation could potentially be swapped out in the future. Howler isn't currently being maintained so the life of this library really depends on its revival or switching to something else in the future

[E-Kuerschner]

As for the bugs is there something specific that you want to address? If we can create a set of reproducible steps maybe we can do something about it!

[phemartin]

@E-Kuerschner getHowl: () => Howl would be fantastic!

The bug I'm running into is that sometimes the audio simply stops playing. Refreshing the page doesn't help replaying the audio. The audio only plays again if the user opens a new tab (which is a pretty bad experience).

Reproducing it is hard because the bug occurs sporadically, which makes it hard to predict when/what is causing it.

This usually occurs when:

• Streaming audio (~ podcast)
• HTML5 mode on
• Long audio (20min or more)
• High speed (2x or more)

I usually get two errors in my console:

• HTML5 Audio pool exhausted, returning potentially locked audio object.
• The AudioContext was not allowed to start. It must be resumed (or created) after a user gesture on the page.

I experienced a similar issue with v1, and accessing Howler directly solved it for me. Which is why I'm asking for a direct interface with Howler. But ideally, it wouldn't be necessary if the audio didn't crash.

Hope this is helpful! ✌️

[E-Kuerschner]

thanks @phemartin! Yeah I agree, going through the Howl object directly kinda defeats the purpose of having a React-hooks based integration all together, but it might be a necessary evil for some cases such as this.

The issues you describe are interesting. Clearly the library is introducing some sort of overhead that doesn't exist with using Howler directly, but what/where this is will be difficult to tray down.

Unfortunately I won't have as much bandwidth for changes as I did earlier this year. If the getHowl change and/or this investigation around the bugs are things you would be interested in writing, I would be happy to look at some PRs.