Swift implementation (IOS Equalizer)

[SimoneBressan]

I have opened this PR to trace the development of the implementation in swift and to give the possibility to use the equalizer in both platforms.

It is not stable and it is not complete. Any contribution is welcome. This branch originated from:
https://github.com/wavy-assistant/just_audio/tree/feature/new_ios_implementation

RelatedIssue: #334

Basic Features:

• play
• pause
• stop
• seek seekToNext seekToPrevious
• setVolume
• setSkipSilenceEnabled
• setSpeed
• setLoopMode
• setShuffleModeEnabled
• shuffle
• setAutomaticallyWaitsToMinimizeStalling
• setCanUseNetworkResourcesForLiveStreamingWhilePaused
• setClip
• setPitch
• setPreferredPeakBitRate

Media Supports:

• Assets
• Ipod-library
• Web url
• Local file

Equalizer:

• Ios
• Android

Extra:

• Support switch output device

[ryanheise]

Oh, wow. That must have been a big job to convert all of that into Swift, and also implement AVAudioEngine (I see you tried at one point to use AudioKit - any reason for reverting?).

Ideally this could co-exist with the objc implementation while it become stable, and the federated plugin model is supposed to allow this, but last I checked a default endorsed implementation can't be overridden unless the implementation is written in Dart. I'll have to check if there are any updates on this, otherwise it could be tricky to have these both coexist.

[BreX900]

@ryanheise Not all I undertake are mine. Those from AudioKit aren't mine. They are derived from the branch which was linked in the issue.
However, I admit that I tried to use but I couldn't. I just couldn't get it properly added to dependencies (pods) and therefore couldn't run the app. (I'm not a magician with swift and pods, sorry)

I needed a player with an equalizer and this seemed like the simplest solution, continue the implementation in swift.
So I decided to share my work but I don't think I will complete it with all the just_audio specifications but only the ones that need

[toonvanstrijpwavy]

@ryanheise The reason I ditched AudioKit was that it didn’t work smoothly. Some basic functionality didn’t even work. Also the pod package wasn’t keeping up to date with the GitHub code of theirs.

so I tried using AudioKit at first, bus because basic play and pause functionality wasn’t working without doing weird and dirty tricks. I ended up switching to AVAudioEngine.

@SimoneBressan thanks for cleaning up the swift code! And all the improvements you made. I’m not a native swift developer. So converting it from c was doable but the code didn’t really felt clean and robust to me.

ow and I was using two different GitHub accounts, one of my clients accounts. And my personal one to work on it during the evening and weekends. So that’s why the commits are a bit of a mess 😬.

anyways great work all! The equalizer of iOS is actually ahead of Android in terms of flexibility. I’m looking forward to get this all merged within this library, so that the community can maintain and improve it! 🥳

[ryanheise]

Ah, @toonvanstrijpwavy my apologies for not acknowledging your name earlier. Excellent work! Yes, I seem to recall when AudioKit 5 was originally coming out, the main author expressed some dissatisfaction with cocoapods and didn't want to continue doing those releases. I was later reassured when I saw the pod actually did come out, but from your comment above it seems like maybe they aren't diligent in updating it?

From what I gather, AudioKit provides wrappers for all of the AVAudioEngine features but also provides extra utility for the visualizer which is another feature we need on iOS. For that reason, I was thinking AudioKit would be the way to go. But of course it is still possible to implement the visualizer on top of AVAudioEngine, and we now also have a pull request implementing the visualizer on iOS for the current Objective C version which might be useful as a reference.

[ryanheise]

Ideally this could co-exist with the objc implementation while it become stable, and the federated plugin model is supposed to allow this, but last I checked a default endorsed implementation can't be overridden unless the implementation is written in Dart. I'll have to check if there are any updates on this, otherwise it could be tricky to have these both coexist.

I think this has now been solved, and I think we can use path_provider as a reference. Before merging this, I will need to create a separate package for the iOS implementation and then update the pubspec to list that as the default implementation. Then the new swift implementation would also be implemented as a separate package, hopefully allowing the app to choose which package to plug in. I haven't fully investigated everything yet, in case it's not completely supported yet, a workaround is suggested here:

#582 (comment)

[ryanheise]

Oops, it seems that when I renamed the dev branch to major, this PR got automatically closed. And unfortunately I can't edit it (as I normally can) to re-base it on major. Would you mind doing that on your end?

[ahmedalshakkaki]

I'm very lost here trying I've been trying to implement the equalizer to my project, it runs perfectly on Android but I couldn't figure out the way to make it work on IOS can you please share any kind of instructions on where to start to implement this on IOS,
PS: thank you for the great work

[ryanheise]

Replaced by #784