Flutter Sound Version 4.0.0

Hi, guys and girls,

It is time to think about the future Flutter Sound version 4.0.0

My thinking is that the major development that we must do is to support, on Android, a way to record without using this horrible Media Recorder. If we use the low level API Android AudioRecord instead of MediaRecorder, it will open doors on many good improvements :

• Record OGG/OPUS (this is already supported on iOS)
• Record PCM (this is already supported on iOS)
• Support other codecs, like MP3 (several developers want MP3)
• … And support streaming to the Application

The last point would be great to use Flutter Sound for recording to a Speech to Text Server.

I looked quickly on this development, and it seems that some features already supported by Flutter Sound will not be easily done with Android AudioRecord, for example the DbPeakController feature. But supporting DbPeakController is mandatory for some of us.

I see two possibilities if we want to use the new features allowed by Android Audiorecord.

1. Develop a new flutter_sound module for recording. This new module will exist side to side with the actual ‘FlutterSoundRecorder’ module. The code will be very clean, because the actual FlutterSoundRecorder module and the new module will be completely separated. No flags to handle during the execution, no hack, no patch.

With this option, we will have then two modules for play-back :

• FlutterSoundPlayer
• TrackPlayer

And two modules fo recording :

• FlutterSoundRecorder
• GreatNewModuleForRecording

The drawback of this option is that it will not be very clear for the developer, which module he must use.

1. Keep just one module for recording : the current FlutterSoundRecorder. When the developer wants to use a feature not supported by Media Recorder (for example record using a Codec like OGG/OPUS, or use a new API verb : startRecordToStream()), FlutterSoundRecorder will delegate the task to another private module.

Probably better for the developer, but I worry that it will be rapidly a mess, when he will want to use at the same time a feature supported natively by FlutterSoundRecorder (DbPeakController) and a feature supported by the new private module.

OK, I hope that I am understandable, because my English is poor.

I would be glad to have your point of view for this development. If you think that there are other priorities for the V4.0.0, it is time to vote.

Thank you for reading me.

[bsutton]

Let’s wait until I’m finished with it and the review where things stand.

Code should be as simple as possible but no simpler 😃

On Tue, 21 Apr 2020 at 16:29, Larpoux [e-mail] wrote:

Too complicated. 👎 Your branch is more and more complicated. Flutter Sound must be light and simple, for the user and for the maintenance.

I do not approve your proposition.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/dooboolab/flutter_sound/issues/288#issuecomment-616980370, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAG32ODZIEVAXQGIKKPONXDRNU4LZANCNFSM4MIAQDZA .

[bsutton]

I would like to suggest changes to the subscription apis.

For recorder we currently have a no. of methods for setup up a subscription:

setSubscriptionDuration setDbPeakLevelUpdate setDbLevelEnabled onRecorderStateChanged onRecorderDbPeakChanged

I would like to suggest that we merge this down to a single api call:

Stream<RecordingDisposition> disposition({Duration interval}) 
{
    _setSubscriptionDuration(interval);
    _setDbLevelEnabled(true);
    _setDbPeakLevelUpdate(interval.asSeconds());
    return     _dispositionController.stream;
}
   
class RecordingDisposition
{
     Duration duration;
     double decibels;
}

I don’t think there is any need to cancel this call. Whilst there is a performance overhead when this runs I don’t think it will be that significant. If it turns out it is then we can add a method: void stopDispositionStream();

As to the player I would suggest the same type of amalgamation: We currently have: setSubscriptionDuration onPlayerStateChanged

These would be reduced to

Stream<PlaybackDisposition> disposition({Duration interval}) 
{
    _setSubscriptionDuration(interval.asSeconds());
    return     _dispositionController.stream;
}

class PlaybackDisposition
{
    Duration duration;
    Duration position;
}

The above changes provides a cleaner and easier to understand api and removes inconsistencies between the two modules.