Please, keep Glib usage to platform abstraction only, not for fluidsynth
logic / algorithm.
I have no issues with C++.
In the future it could even make the code more maintainable, as alot of the
current C functions belongs to one domain object or another.
On Wed, Jan 22, 2020 at 8:04 AM Tom M. via
subdevice #0
>
> > > card 1: ODROIDDAC [ODROID-DAC], device 0: PCM5102 HiFi pcm5102-0 []
>
> > > Subdevices: 1/1
>
> > > Subdevice #0: subdevice #0
>
> > >
>
> > > odroid@odroid:~$ aplay -D hw:CARD=ODROIDDAC,DEV=0 Desktop/foo.wav
>
> > > Playing WAVE 'D
device seems to be powerful enough.
maybe you can also try to disable 64bit floating point operations and use
32bit with cmake enable-floats options
also if you are not using pulse at all, try to disable it completely
Philippe
On Fri, Nov 15, 2019 at 9:34 AM Marcus Weseloh wrote:
> Hi Etienne,
I understand that FluidSynth primary usage is not a SoundFont editor, but
being able to live edit the SoundFonts would be awesome.
On Thu, Jul 11, 2019 at 3:03 PM Tom M. wrote:
> ATM, you can only get the names of the soundfont presets, see preset
> iteration here:
>
>
> https://github.com/Fluid
Hi, I don't know what you mean by brightness, but for the output loudness,
you can bump the gain setting.
I think by default it's 0.8, and I might have pushed it to 1.0 for MIDI
Player.
Be aware that bumping the gain might introduce audio clipping, depending on
the SoundFont and the MIDI file being
So do I, but this is not going to happens... like ever.
The issue can be summarised to "get rid of glib dependancy".
glib is used as portable layer for alot of FluidSynth internals,
unfortunately glib has no Android port...
So we are stuck with unofficial forks like mine...
I try to keep it update
FluidR3.sf3 is an heresy !
On Tue, Apr 24, 2018 at 11:54 PM, Marcus Weseloh wrote:
> Hi Philippe,
>
> 2018-04-24 21:32 GMT+02:00 Philippe Simons :
> >> So I think I'm probably the best placed to speak since I'm using
> fluidsynth both as a MIDI player and as a r
Hi all,
So I think I'm probably the best placed to speak since I'm using fluidsynth
both as a MIDI player and as a real-time synthesizer on Android.
Obviously I didn't wait for this feature to be implemented to create my
applications, so I can say that I don't them... like at all.
for the player,
lol I just re read myself, but you understood what I meant :p
On Mon, Apr 23, 2018 at 10:15 PM, Marcus Weseloh wrote:
> Hi Philippe,
>
> 2018-04-23 20:16 GMT+02:00 Philippe Simons :
>
>> Seems to forks fine on Android.
>>
>
> Excellent, thanks a lot for testin
Seems to forks fine on Android.
On Mon, Apr 23, 2018 at 7:25 PM, Tom M. wrote:
> I keep thinking about this preloading feature and I'm not yet fully
> convinced of it. I see quite high obstacles for it being beneficial i.e.:
>
> - We need a user who plays MIDI files via command line and listens
I'll give it a shot on my android fork
On Sun, Apr 22, 2018 at 7:26 PM, Marcus Weseloh wrote:
> Hi all,
>
> the dynamic-sample-loading branch has been merged into master. I will
> follow up with a few more pull-requests that add more bells & whistles to
> the feature, like the preloading functio
that's unavoidable... Bluetooth A2DP compress audio before sending to the
Headset...
the compression needs to buffer some raw PCM, and that buffer is your
latency...
On Mon, Feb 19, 2018 at 8:34 AM, Paul Cohn wrote:
> Hello,
>
> I'm developing a C++ application on OSX (eventually cross-platform)
}/android ./fluidsynth)
On Thu, Jan 18, 2018 at 12:58 PM, Philippe Simons wrote:
> https://github.com/googlesamples/android-audio-
> high-performance/tree/master/SimpleSynth
>
> this a simple synth which generate a sin tone.
>
> just replace the implementation of int Synthesizer::ren
uild, but I'm really not clear
> where I should be calling fluid_synth_write_* - in a driver I've written
> myself? Are there any examples I can follow?
>
>
> On 18 January 2018 at 09:14, Philippe Simons
> wrote:
>
>> The issue I have with an audio driver on Android,
The issue I have with an audio driver on Android, is that it will never
cover all the uses cases that a dev might need.
For ex:
OpenSL is great for real-time MIDI rendering because it allows to work with
very small buffers. (15ms)
But for a MIDI player, working with small buffer is not a option (i
https://github.com/VolcanoMobile/fluidsynth-android
this is my fork of Fluidsynth
basically, I removed the glib dep and all the drivers, so it's up to you to
call fluid_synth_write_s16 to fill a buffer.
it can be a OpenSL buffer, AAudio, or even an AudioTrack
you can build it by calling ndk-buil
I'm running FluidSynth on Android, and I never had sound glitching with the
default voices count (256 or 512) even using large soundfonts like Fluid R3.
How is your setup ? I suspect a too small AudioTrack buffer size (mine is
about 48000 16bit PCM strereo frames)
On Mon, Dec 4, 2017 at 5:43 PM, M
y we are using.
>
>
> Tom
>
>
> 2017-11-13 15:28 GMT+01:00 Philippe Simons :
> > i'd like to add support for SF3 to my android fork, but I'd like to
> avoid to
> > add a dep on libsndfile (shouldn't be impossible).
> >
> > what do you thin
i'd like to add support for SF3 to my android fork, but I'd like to avoid
to add a dep on libsndfile (shouldn't be impossible).
what do you think to include std_vorbis from http://nothings.org/ if
libsndfile is not available ?
___
fluid-dev mailing list
ok, please take into account that on some system LADSPA is just not
available
I'd like to avoid making more changes in my branch to be able to compile
fluidsynth for android
On Mon, Nov 13, 2017 at 10:02 AM, Marcus Weseloh wrote:
> Hi all,
>
> as the LADSPA subsystem has been cleaned up and has
Isn't OS/2 already dead anyway?
On Wed, Oct 11, 2017 at 10:19 AM, Tom M. wrote:
> TinyCThread looks good. Even though they only support Win32 and Pthreads
> they implement the C11 API. So we could move to C11:
>
> #ifdef __STDC_NO_ATOMICS__
> #error "Compiler has no C11 atomics"
> #endif
>
> #
t; the atomics and cstdint part, C++11 for the threading part. Although C11
> atomics seem to optional as well.
>
>
> Tom
>
>
> 2017-10-06 18:48 GMT+02:00 Philippe Simons :
>
>> damn! and I guess moving to C++11 is not an option
>>
>> On Fri, Oct 6, 2017 at 5:55 P
gt;
> Tom
>
>
> 2017-10-06 16:56 GMT+02:00 Philippe Simons :
>
>> According to https://msdn.microsoft.com/en-us/library/hh567368.aspx
>>
>> VS2015 should have decent enough C11 support for threads and atomics.
>> Or is only for C++11 ?
>>
>> P
According to https://msdn.microsoft.com/en-us/library/hh567368.aspx
VS2015 should have decent enough C11 support for threads and atomics.
Or is only for C++11 ?
Philippe
___
fluid-dev mailing list
fluid-dev@nongnu.org
https://lists.nongnu.org/mailman/li
24 matches
Mail list logo
