Audio messages functionality missing. Can I do PR?

[GauravCalidig]

Hi, As i can seethe functionality to send audio is still missing, i have added a similar thing in my project, Just wanted to ask if i do a pull request for audio messages, will it be added? I mean Are you guys looking for this feature? The thing is it will need changes in all the depending packages such as flutter_firebase_chat_core, chat_types

[demchenkoalex]

Hey @GauravCalidig depends on the library you use for the audio. Is that still https://pub.dev/packages/flutter_sound? Why they just don't use Apache or MIT license..

[gauravmehta13]

record package

[gauravmehta13]

And audioplayers

[GauravCalidig]

its record and audio_players

[demchenkoalex]

Those are good, will be able to merge. I'd wait for audio_players v1.0.0 release, seems like a new big step, after 7 months :)

[shashwatadi]

Is this planned?

[demchenkoalex]

Suggested dependencies are good, if this will not be developed before it will be next in line for us to do after we finish swipe to reply (ongoing atm) and refactor the package to make it more modular and nicer to contribute

[UmairSaqibBhutta]

@demchenkoalex audio_player has issues on Samsung devices.

[demchenkoalex]

@UmairSaqibBhutta are there better alternatives?

[UmairSaqibBhutta]

I think every audio player lib has some issues so I used HTML (audio renderer lib with audio tag) to render my audio. But you can choose any lib with lesser issues.

[Yahllil]

@demchenkoalex Any update on this/other voice messages functionality? This is crucial to one of my projects using this package.

Is there a temporary branch that can be used in the meantime until it is merged to the main branch?

[demchenkoalex]

Hey @Yahllil I did not work on that, people here suggested that they can contribute, I did not see anything since. This will be the next feature after swipe to reply and reactions, together with video messages.

[Yahllil]

@demchenkoalex thanks for the answer. Do you maybe have any rough estimation when these features would be released? This is crucial to one of my apps. If it'll be soon (up to a month for example) so I would wait, but if it will take a long time I would have to find a solution :)

[demchenkoalex]

I don't think it will be there in a month. Swipe to reply is in the "works, but not really" state for I don't know how many months now, because it is either I am busy at work or lots of other big PRs coming in. I hope I will be able to finish this swipe to reply this month, then road will be open to look at audio messages, but given I am a perfectionist I will spend lots of time making it beautiful and functional, it definitely won't be drop a library with some shitty UI, merge.

[Yogesh-Dubey-Ayesavi]

I would personally not suggest using the audio_players package because it has in web although it works fine in other platforms. I was working on this for long period of time went through a lot of packages found record package one of the best for recording purposes and combination of Just_audio and audio_service for playback the only issue i noticed with record package was it does not provide duration of the recorder stream which becomes on of the biggest issue. I tried to fetch the duration of the stream from just_audio by passing local path i obtained from the record package where the audio was recorded but just_audio was not able fetch the duration with local path. It becomes the biggest issue because by not having exact duration of the audio you can not render any visual representation for it . Flutter_sound does not provide a sort of wave implementaion for visual representation where as just_audio also has a package for it. Using just_audio with audio_service using custom audio_handlers with overridden methods will are the absolute thing that we are right now looking for. From my point of view i conclude to have plugins like just_audio, audio_service and record.

[demchenkoalex]

Thanks for this @Yogesh-Dubey-Ayesavi!

[elhe26]

Hi @demchenkoalex , any updates?

[Yahllil]

Hi @demchenkoalex , any updates?

+1

[demchenkoalex]

Nope. When swipe to reply and video messages will be included in the chat, this will be next, unless again, done by someone else :) if someone will want to do it I will provide exact requirements I have in my mind.

[elhe26]

@demchenkoalex,

What requirements do you have in mind?

[demchenkoalex]

1. I want to keep supporting all the platforms like we do now, Android, iOS, Linux, macOS, web, Windows. I wanted to research if this is possible to add packages needed to implement this that do not support all platforms, but keep all of them listed on pub.dev for the chat UI. Basically, like optional import or something. For those platforms where we will not be able to use new dependencies, we will render empty container or something, or maybe a message that audio messages are not supported on this platform.
2. Test 2 sets of libraries - audio_players and record or just_audio,audio_service and record, people in this thread mentioned pros and cons of both, so we need to see which ones will be optimal.
3. We need to check how can we get a waveform on as many platforms as possible.
4. Play/pause should be supported from the message level, but probably we also need some kind of a bar appearing to keep the reference if we scroll too much from the original audio message (similarly like Telegram does).
5. Audio progress shown visually
6. Optionally, scroll though the waveform to fast forward/rewind.
7. Optionally, full screen player with all audio messages passed as an array (similarly like we have images gallery) - I guess this can be done if we go with just_audio. If we go with audio_players we don't need to develop full screen player.

[marinkobabic]

I don't see the point why not making the player just more abstract by using an interface so that the community can use variation of libraries. This libraries work anyway very similar.

recorder.init() recorder.startRecording() recorder.stopRecording()

player.init() player.play() player.stop()

then in the example we could provide an example how to use one of the most popular libraries. Then the community could provide different packages just by implementing those interfaces. Same is valid for video.

Here a lot of work has been done, but the pull request was cancelled because of the used library https://github.com/flyerhq/flutter_chat_ui/pull/18

[demchenkoalex]

@marinkobabic well abstraction is now in the lib, thanks to you :) however, my point with this package was to also provide quality defaults, i.e. "it just works". I didn't plan to make it an empty Widget and tons of examples on how to add different widgets to it, it is a completely new approach. Might be something to think about though. So it should be like a different set of packages? Like basic flutter_chat_ui, and something like flutter_chat_ui_audio with some good audio message implementation and just hook it to the audio message builder? alternatively, people will hook in their own solutions?

[marinkobabic]

@demchenkoalex

The issue in this case is that you can't just add a fix dependency on your own to the flutter_chat_ui and all works like expected. Many different libraries have also different sizes so the different libraries may blow up the size of the application. Uses not using audio messages will not be happy about the application size. "It just works" is still possible like explained by you by using a different packages. But I would suggest to do it the following structure

flutter_chat_theme
flutter_chat_ui
flutter_chat_audio_player
flutter_chat_audio_recorder

Player and recorder need new theme settings but both components need to reuse some existing theme colors. What are the requirements

Player

You have the player in the chat when you receive a message

Then you have the player in the chat when you are about to send a message with the option to listen again and to remove when you are not happy about the content

And then you have it when you have sent the message as author

Recording For recording you can use library A and for playing you can use library B which is clear. Recording may look the following way

In the documentation you can provide details how to put all the packages together and also the example will have all this packages integrated. Community can provide additional packages for player and recorder.

Challenge The question is now should all the players and recordings have UI at all or is the UI always part of the flutter_chat_ui and those components have just a logic to play and record audio. If you decide to add the ui to chat and keep the logic for playing and recording in other packages, then widgets for playing and recording audio in flutter_chat_ui will provide an interface with callback functions and this way the logic of playing and recording is in other packages and can be implement by the community and you will provide as well some default packages which are used of course in the example project to have fun with "it just works" 😄 New structure would then look like

flutter_chat_ui
flutter_chat_audio_player
flutter_chat_audio_recorder

[Yahllil]

@demchenkoalex Any news? This is a very important feature.

If you will give me your final decision for the requirements I'll try to make a PR.

[demchenkoalex]

@Yahllil high level abstraction (types and buildAudioMessage) were merged and released, so anything can be attached now (like 3rd party lib or a custom implementation) no need to fork the lib or something. You can totally make it work for your use case, you can even do a 3rd party lib to hook to the chat. Unfortunately PR to this repo will not work, because according to our conversation here, it will be better to have some kind of monorepo with optional packages, ours or community ones, than bundling everything here.

[Yahllil]

@Yahllil high level abstraction (types and buildAudioMessage) were merged and released, so anything can be attached now (like 3rd party lib or a custom implementation) no need to fork the lib or something. You can totally make it work for your use case, you can even do a 3rd party lib to hook to the chat. Unfortunately PR to this repo will not work, because according to our conversation here, it will be better to have some kind of monorepo with optional packages, ours or community ones, than bundling everything here.

Can you please explain a bit more about the existing solution with the abstractions? What is currently supported and how to use it? Is the UI ready yet? I cannot find that in the docs

[demchenkoalex]

as I said, types and buildAudioMessage (audioMessageBuilder sorry). There is types.AudioMessage as well. This is the abstraction. There is no UI. You can use types though and you can use audioMessageBuilder to build the audio message that will be intact with other parts of the chat. Going forward, this repo will probably be a "base" chat without any advanced features, and then there will be packages that you include if needed (like default audio message implementation), and hook it into audioMessageBuilder. Or as well community can make their own implementations (like community audio message implementation) that other people can hook into audioMessageBuilder if they prefer different dependencies for example.

[Yahllil]

as I said, types and buildAudioMessage (audioMessageBuilder sorry). There is types.AudioMessage as well. This is the abstraction. There is no UI. You can use types though and you can use audioMessageBuilder to build the audio message that will be intact with other parts of the chat. Going forward, this repo will probably be a "base" chat without any advanced features, and then there will be packages that you include if needed (like default audio message implementation), and hook it into audioMessageBuilder. Or as well community can make their own implementations (like community audio message implementation) that other people can hook into audioMessageBuilder if they prefer different dependencies for example.

Got it. Is there an abstraction for the audio message input as well (when the logged user records a message)? I guess the textfield should disappear and be replaced by an audio indicator. Is there a way to achieve that currently?

[demchenkoalex]

I don't think so, but should be an easy PR