search

ryanheise / just_audio

Audio Player
1.03k stars 638 forks source link

Provide a simple Audio Visualizer #97

Open oseiasmribeiro opened 4 years ago

oseiasmribeiro commented 4 years ago

Provide a simple Audio Visualizer (showing low, medium and high frequencies) that offers the possibility of increasing or decreasing a number of bars. This is useful for the user to make sure that the audio is being played or recorded in the application. Sometimes the volume or mic can be at a minimum.

Example: https://dev.to/armen101/audiorecordview-3jn5

audioVizualizer

ryanheise commented 4 years ago

I also think this feature would be a good idea, although it is not necessarily the highest on my personal priority list. I will of course welcome pull requests.

The underlying API on the Android side to implement this is:

https://developer.android.com/reference/android/media/audiofx/Visualizer

This API is relatively straightforward to use.

However, on iOS, it does not appear to be as straightforward.

oseiasmribeiro commented 4 years ago

Thanks for your answer! I look forward to and await this resource.

sachaarbonel commented 4 years ago
oseiasmribeiro commented 3 years ago

@sachaarbonel thanks!

esDotDev commented 3 years ago

Any chance you might add this? It's not present in any sound libraries for Flutter currently, and would be really nice to be able to build visualizers.

Edit, looking into it a bit further, I think we just need this value on iOS, is that a big lift? https://developer.apple.com/documentation/avfoundation/avaudioplayer/1390838-averagepowerforchannel?language=objc

ryanheise commented 3 years ago

That would allow for a rudimentary visualiser, although probably what we want is something equivalent to Android's API, so we'd want to do a FFT on the audio signal.

After accidentally stumbling upon it, it seems there is a way to do this. First, we create an AVMutableAudioMix and set it in AVPlayerItem.audioMix. To this audio mix's inputParameters array we add an instance of AVMutableAudioMixInputParameters. And on this instance we can access the audioTapProcessor through which it should be possible to analyse the audio signal and do the FFT.

pstromberg98 commented 3 years ago

@ryanheise I think the best solution for audio visualization is providing a clean way to subscribe or retrieve the samples/buffers of audio data. Providing a way to pull in the raw PCM data would allow for more than just FFT analysis but would open the door to nearly any other type of audio analysis.

The audioTapProcessor could be the way to access the raw data on iOS and then making use of the Renderer in exoplayer to access the raw data for android. I imagine the api would be as simple as a stream on the audio player called rawDataStream or sampleStream or something akin to that. What are your thoughts on that?

ryanheise commented 3 years ago

@pstromberg98 that's possibly a good idea. Looking at the Android Visualizer API, it actually provides both the FFT data and the waveform data, so we could do the same.

Although you could argue we only need the latter, both Android and iOS provide us accelerated implementations of FFT which we should take advantage of.

pstromberg98 commented 3 years ago

@ryanheise Totally! It would be super nice for the library to provide the fft and I don’t see any harm in providing that. I was mainly saying in the case of having either one or the other it would probably be better to provide the raw waveform just in case users wanted to do other analysis and transforms on the data. But having both would be slick!

ryanheise commented 3 years ago

I've just implemented the Android side on the visualizer branch. Call:

samplingRate = player.startVisualizer(
    enableWaveform: true,
    enableFft: true,
    captureRate: 10000,
    captureSize: 1024);

Then listen to data on visualizerWaveformStream and visualizerFftStream. The returned sampling rate can be used to interpret the FFT data. Stop the capturing with player.stopVisualizer().

The waveform data is in 8 bit unsigned PCM (i.e. subtract 128 from each byte to get it zero-centred). The FFT is in the Android format, and I'm not sure yet whether the iOS native format will be different, so that particular part of the API may be subject to change.

It may take a bit longer for me to get the iOS side working, but in the meantime would anyone consider contributing a pull request that adds a very minimalistic visualiser widget to the example, demonstrating how to make use of the data in visualizerWaveformStream?

ryanheise commented 3 years ago

Information on how to interpret the Android FFT data:

https://developer.android.com/reference/android/media/audiofx/Visualizer#getFft(byte[]) https://stackoverflow.com/questions/4720512/android-2-3-visualizer-trouble-understanding-getfft

As for iOS, some ideas for implementation:

https://stackoverflow.com/questions/22751685/using-mtaudioprocessingtap-for-fft-on-ios https://chritto.wordpress.com/2013/01/07/processing-avplayers-audio-with-mtaudioprocessingtap/ (not exactly relevant)

Some official Apple stuff:

https://developer.apple.com/documentation/avfoundation/avplayeritem/1388037-audiomix?language=objc https://developer.apple.com/documentation/avfoundation/avaudiomix/1388791-inputparameters?language=objc https://developer.apple.com/documentation/avfoundation/avmutableaudiomixinputparameters?language=objc https://developer.apple.com/documentation/avfoundation/avmutableaudiomixinputparameters/1389296-audiotapprocessor?language=objc https://developer.apple.com/forums/thread/11294 (forum post) https://codedump.io/share/KtEfM7VG0wrL/1/how-do-you-release-an-mtaudioprocessingtap (releasing tap)

ryanheise commented 3 years ago

I've changed the API slightly to include the sampling rate in the captured data, and included a very simple visualiser widget in the example. The iOS side will be more difficult and I have some higher priority things to switch to for the moment but help is welcome. In particular, if you would like to either give feedback on the API, contribute a better visualiser widget example or even help getting started on the iOS implementation using the documentation linked above.

ryanheise commented 3 years ago

To those interested in this feature, would you like a separate method to start the request permission flow to record audio for the visualizer? Currently startVisualizer() will start this flow when it detects that permission hasn't already been granted, but perhaps some apps would like more control over when permission is to be requested.

pstromberg98 commented 3 years ago

@ryanheise Personally I like when libraries provide more fine grain control but I can see the argument for both. Perhaps it would be best to have startVisualizer() request permissions (if needed) by default but also have a way to request the permission separately.

defsub commented 3 years ago

I second the comment from @pstromberg98

ryanheise commented 3 years ago

I've made an initial implementation of the visualizer for iOS. Note that this is definitely not production ready. Some problems to investigate:

  1. Against Apple recommendations, I allocate an NSData buffer for each capture inside the TAP. You might want to keep an eye on memory usage in case this causes a leak.
  2. I've only crudely converted the samples into 8 bit unsigned PCM. To make it look closer to Android, I fudged the scaling by 3x'ing every sample. Not really sure what Android is going under the hood so I can't emulate it exactly.
  3. There's a chance this might not work with different audio formats, and I may need to add special cases for the different formats.
  4. FFT is not implemented yet, only the raw waveform data.

Thanks, @pstromberg98 for the suggestion. I agree, and I'll try to implement that.

As before, I unfortunately need to work on some other issues for a while, particularly null safety. But hopefully this commit provides a good starting foundation to build on.

Contributions are also welcome, so here is the "help wanted":

ryanheise commented 3 years ago

Has anyone been able to give this a whirl yet? I think this would be a really useful feature to include in the next release, so I'd like to make it a priority, although for that to happen, it would definitely help to get some feedback on the iOS side in terms of memory efficiency and stability. I will of course eventually add the option to start the permission flow on Android on demand, but I think the iOS stability will be the most critical thing to be confident about before I include this in a release, along with the iOS FFT implementation.

Of course, I could just document it as being experimental and unstable, and release it that way, which might actually not be a bad idea to get more eyes on it.

pstromberg98 commented 3 years ago

@ryanheise If I can find time I will talk a look at the iOS side and give my thoughts and feedback. I appreciate your efforts on it so far and am eager to jump in and help when I find time 👍.

I think marking the feature as experimental would make a lot of sense.

MichealReed commented 3 years ago

I pulled it over and merged the changes to check out the android version, but cant seem to get it working.

Mic permission is granted (although it crashes app after prompt acceptance), but it prevents my player from playing anything. I even tried wrapping it in a future to ensure the player has data before calling. Any ideas?

Future.delayed(Duration(seconds: 2), () {
        var samplingRate = activeState.player.startVisualizer(
            enableWaveform: true,
            enableFft: true,
            captureRate: 48000,
            captureSize: 1024);
        activeState.player.visualizerWaveformStream.listen((event) {
          print(event);
          this.add(AudioManagerVizUpdateEvent(vizData: event.data));
        });
      });
ryanheise commented 3 years ago

Thanks for testing that. It turns out there is another change to the behaviour of ExoPlayer in that onAudioSessionIdChanged is not called initially for the first value. I've done the merge and fixed this issue in the latest commit.

ryanheise commented 3 years ago

Perhaps. With the null safety release of Flutter soon to reach stable, I'm not sure if I'd like to do this before or after that. Currently I'm maintaining two branches which is a bit inconvenient to keep in sync.

We'll see how things pan out but first I may need to focus on getting the null safety releases ready.

MichealReed commented 3 years ago

Thanks for jumping to this. Things are working great so far, but the fft buffer visual is a bit different than I expected from using my custom visualizer on other fft sources. Will try to take a deeper look and report back the bug if I find it.

ryanheise commented 3 years ago

That's basically just the raw output from the Android API which is documented here:

https://developer.android.com/reference/android/media/audiofx/Visualizer#getFft(byte[])

So it's possible you might get weird output unless you interpret that byte array as per the above documentation.

penalosa commented 3 years ago

Is this supported on iOS currently? I tried using the visualiser branch, but I keep getting an error: flutter: setPitch not supported on this platform

ryanheise commented 3 years ago

Is this supported on iOS currently?

The waveform visualizer is implemented on iOS but not pitch. You can track the pitch feature here: #329

There is a big question at this point whether to continue with the current AVQueuePlayer-based implementation or switch to an AVAudioEngine-based implementation. For pitch scaling, I really want to take advantage of AVAudioEngine's built-in features, but that requires a rewrite of the iOS side - see #334 and this is a MUCH bigger project.

I would really like to see an AVAudioEngine-based solution see the light of day, but it will probably not happen if I work on it alone. If anyone would like to help, maybe we can pull it off with some solid open source teamwork. One of the attractive solutions is to use AudioKit which is a library built on top of AVAudioEngine which also provides access to pitch adjustment AND provides a ready-made API for a visualizer and equalizer. That is, it provides us with everything we need - BUT it is written in Swift and so that involves a language change and it means we may need to deal with complaints that old projects don't compile (we'd need to provide extra instructions on how to update their projects to be Swift-compatible).

Would anyone like to help me with this? (Please reply on #334)

hemanthkb97 commented 3 years ago

@ryanheise how do i use this experimental wave visualizer

ryanheise commented 3 years ago

Hi @hemanthkb97 . Clone this repo and checkout the visualizer branch. Inside, the example/ directory has been modified to demonstrate how to use the API. There are also some comments above on things to be tested on iOS - though Android should be reliable. I plan to rewrite the iOS implementation on top of AudioKit.

hemanthkb97 commented 3 years ago

@ryanheise thank you so much for super fast reply.

i tired out but got error like this: The following MissingPluginException was thrown while de-activating platform stream on channel com.ryanheise.just_audio.waveform_events.188f771f-2570-46fe-be90-7b07198f3587:

full error: I/ExoPlayerImpl( 5453): Init 8b35ed1 [ExoPlayerLib/2.13.1] [generic_x86_arm, sdk_gphone_x86, Google, 30]

════════ Exception caught by services library ══════════════════════════════════ MissingPluginException(No implementation found for method listen on channel com.ryanheise.just_audio.waveform_events.2b0b1792-cd7f-4b16-88bd-ab92c7de5799) ════════════════════════════════════════════════════════════════════════════════

════════ Exception caught by services library ══════════════════════════════════ MissingPluginException(No implementation found for method listen on channel com.ryanheise.just_audio.fft_events.2b0b1792-cd7f-4b16-88bd-ab92c7de5799) ════════════════════════════════════════════════════════════════════════════════ E/flutter ( 5453): [ERROR:flutter/lib/ui/ui_dart_state.cc(199)] Unhandled Exception: MissingPluginException(No implementation found for method startVisualizer on channel com.ryanheise.just_audio.methods.2b0b1792-cd7f-4b16-88bd-ab92c7de5799) E/flutter ( 5453): #0 MethodChannel._invokeMethod E/flutter ( 5453): E/flutter ( 5453): #1 MethodChannelAudioPlayer.startVisualizer E/flutter ( 5453): E/flutter ( 5453): #2 AudioPlayer._setPlatformActive. E/flutter ( 5453): E/flutter ( 5453):

ryanheise commented 3 years ago

What is the reproducible project - is it it the provided example?

hemanthkb97 commented 3 years ago

@ryanheise sorry, i didn't copy files properly. now its working fine. 👍🏼

one last question, does this work on IOS?

thank you so much.

ryanheise commented 3 years ago

As per the above comment, I am asking people to test it on iOS the let me know whether or not it's working for them

enric1994 commented 3 years ago

@ryanheise I can confirm that 1e033273a8b3757995ad416ebfb21f17a973fa98 example from the visualizer branch works on iOS (simulator). Is it possible to visualize the amplitude instead of the "frequency"? Something more like the SoundCloud visualizer.

Great project by the way, keep it up!

Piero512 commented 3 years ago

This is very nice! I was just into creating some audio visualization stuff in a production app using this plugin and I couldn't keep but wonder, is the sending of samples to Dart working?

This would help me a lot as this would save me from having to decode my input file twice (one in just_audio and other in native code to retrieve the raw samples) to show some FFT derived visualizations.

I can work with the samples already, as I also ported a Rust based FFT implementation with good enough performance for my POC.

ryanheise commented 3 years ago

Hi @Piero512 , yes sample data is working on iOS and Android, while FFT is currently on Android only (but you could do your own FFT in Dart I suppose). Have you tried the example as mentioned above?

Piero512 commented 3 years ago

No, sorry, I haven't. Will check once I find free time. Mind linking it directly (or do you have a FAQ/summary) on the top post?

dfdgsdfg commented 3 years ago

Other flutter FFT implementation for just reference.

https://pub.dev/packages/audio_visualizer (Seems abandoned) https://github.com/Eittipat/audio_visualizer

https://pub.dev/packages/flutter_visualizers (Seems abandoned) https://github.com/iamSahdeep/FlutterVisualizers

ryanheise commented 3 years ago

Thanks, @dfdgsdfg . FYI, just_audio already captures the samples on Android and iOS, and does the FFT on Android but not on iOS. So of these two packages above, flutter_visualizers is now obsolete since just_audio does all that it does plus iOS, while audio_visualizer could still be useful to add the FFT layer on top of just_audio's iOS sample capture.

But probably it would be better to run the FFT in the native code. Not only will it be faster, but it will also be more accurate since the sample data that is used for visualization is typically at a much lower resolution.

Although in any case the plan is still to leave this visualizer branch as an unofficial branch (still usable, but you must use it as a git dependency) until I can redo it as an AVAudioEngine-based implementation.

cedvdb commented 3 years ago

Is there a visualization option for viewing the sound in it's entirety, I don't know the exact term but this is often seen in audio editing apps like ableton..

If not is there an output in the api I can use to generate that ?

ryanheise commented 3 years ago

@cedvdb no, the visualizer is intentionally a low res view of the samples specifically for the use case of realtime visualizers used in audio player apps (i.e. to visualise what you are "currently" hearing). If we transport the samples in full resolution over the platform channels in realtime, I suspect we'll hit a performance limit of Flutter's platform channels. There are some developments with FFI which may allow this down the track but for now that is not a goal. If you are building an app like ableton, then that is also not a current goal since just_audio focuses on playing audio and not editing (but who knows what the future may hold).

Now, your use case to view the entire soundwave in its entirely would best be handled by its own plugin. You would basically have to parse and decode the entire file which may take quite a while depending on the length of the audio. For example, on some Android phones without optimised decoders, it might take several minutes to decode an entire file. This is generally not a problem for playback because normally a decoder only needs to decode "just in time".

I could create such a plugin if people want this, but I don't know how many people would want it so I don't know whether it is worth the effort. As you can expect, I am already quite stretched developing my current plugins.

Can I ask, do you just want to be able to visualise the sound wave of the entire file, and be able to view different parts of that sound wave depending on there the user seeks to? For that use case, you don't actually need full resolution either. The actual sample rate of most audio is much higher than what the human eye needs to visualise a span of audio that fits within the width of a mobile screen. So such a plugin would probably have an option for how many samples per pixel or something like that.

cedvdb commented 3 years ago

The use case I had was to let the user record his voice and then clip the record where he wanted to (the visualizer would help with that). However after some more research on what I wanted to create that might not be necessary for reasons I won't explain.

You often see such visualizer, in a low resolutions version, in players such as soundcloud players and the likes, so I'm not sure it should take a minute to process ? Maybe there is a way to "skip" parts of the file depending on how big it is and the precision required. You can only fit so many data on a screen so there must be a precision aspect, or zoom aspect to it. Excuse my lack of vocabulary in this domain, I don't know it very well.

I agree that this could be done by another package but I would not do it currently. There are so many things that could be done for sound but it remains to be seen how successful dart is going to be. For example on the web, if I recall correctly they have a good API for creating synthethized sounds as well (sin waves etc) and adding effects. This makes it theoritically possible to create an ableton clone. However this is a playback library, not a synthethizer library. All those things related to sound are more niche and I'm not sure there is a demand for it, except from a few.

ryanheise commented 3 years ago

To clarify:

These two things are fundamentally different, and it does not make much sense to shoehorn the second feature into just_audio, but it does make sense to make it a separate plugin since after all it will need to use its own decoder. It won't be able to share the decoder with the one just_audio currently uses for real-time decoding. just_audio's decoder essentially happens at a pace in line with the current playback speed, and for a real-time visualizer, that's exactly the same thing. But for a waveform display, you typically want a decoder to operate at a much faster rate. Well, basically, as fast as possible, so that you can see ahead, not just see the current 100ms window.

Anyway, let's not debate the technical side of things, as I will make the implementation decisions. In this case, I would put it in a separate plugin because that would be easier. The question I put to you in my previous comment was, do you want a waveform display? If so, I can create that. But first, how many other people would want it?

Note that the way apps like sound cloud actually work is that because the decoding process is very expensive, they do it once when the audio file is imported and then the cache the resulting waveform image. Once cached, you then essentially have random access to any point in the waveform allowing you to jump to and zoom into any segment instantly to display it.

cedvdb commented 3 years ago

Yes I understood you the first time

The question I put to you in my previous comment was, do you want a waveform display? If so, I can create that. But first, how many other people would want it?

Yes but I can live without.

rahmanrezaee commented 2 years ago

I need as this any can help me image

ryanheise commented 2 years ago

I have created a separate issue for the waveform display: #507

If you are interested in that feature, please vote on it over there.

Eittipat commented 2 years ago

Hello,

I just made native FFT on ios #546

Cheers,

ryanheise commented 2 years ago

Awesome work, @Eittipat ! I've left some comments over on the PR, and we can discuss it there. I feel the same way about the fragility of the whole thing when I wrote the waveform visualizer, and it definitely needs a lot of testing before I could feel confident about merging it into stable, or at least ensuring that when the visualizer is not running, that the rest of the just_audio functionality will be unaffected (one complication to that is that the tap may be useful to activate for other features besides the visualizer, such as audio panning.). But so long as this branch exists, people who absolutely need the visualizer can still use it (and test it :-) ).

I like that you've modified the iOS FFT data to match the Android format. Something similar is necessary also for the waveform visualizer data, but unfortunately the Android documentation doesn't actually tell us exactly how this waveform data has been scaled and I've just done a simple linear scale approximation.

onatcipli commented 2 years ago

Hi @ryanheise, thanks for the great plugin at first and I'm looking forward to having this Audio Visualizer.

I got another question for you, I have some Live Stream Audio and I'm using the HlsAudioSource and it is working perfectly but I need to create the wave effect like in Google Meeting when you talk it shows the decibel level as Wave effect (you can see from the video)

so Is there any way to achieve this, I only need to know currently playing audio decibel level (as converted to double, from 0.0 to 1.0 for example, It would be great to have Stream<double> decibelLevelStream for showing basic sound changes)

I thought I could achieve this by getting the Live Stream Audio data with the HTTP package as a byte array and somehow get the decibel level of current data after that pass that data to your just_audio package for being able to play.

I have seen your StreamAudioSource, LockCachingAudioSource classes and implementations, is it possible to have currently playing decibel level with your package? If there are some walkarounds please let me know

https://user-images.githubusercontent.com/26159899/137099228-d6885826-ec74-4edf-a5df-9a228a7bdbed.mov

ryanheise commented 2 years ago

This visualizer should allow you to do that if you listen to either the waveform or the fft data and look at the amplitude or magnitude.

zatovagul commented 2 years ago 
onPlay() async{
    _justPlayer.startVisualizer(
        captureRate: 10000,
        captureSize: 1024
    ).then((value){
      _justPlayer.visualizerWaveformStream.listen((event) {
        print("VISUALISER $event ${event.samplingRate}  ${event.data}");
      });
      _justPlayer.visualizerFftStream.listen((event) {
        print('FFTVISUALISER $event ${event.samplingRate} ${event.data}');
      });
    });
    await _justPlayer.play();
  }

  onPause() async{
    _justPlayer.stopVisualizer();
    await _justPlayer.stop();
  }

I am trying to visualize audio information. But visualizerStreams doesn't share any data. So that streams didn't print any value, but audio already playing

ryanheise commented 2 years ago

The API for starting the visualizer is not currently ideal, but I would suggest looking at the example (in this repo) to see the order of initialisation that works.