This is my first reply to the mailing list. I am not sure if there is any format not good.
Thanks for your suggestion. The sound font I am going to use is copied from Creative's sound card installation CD: CT4MGM.SF2 (4M bytes). The quality should be OK for me. But I am not sure if this is a free sound font. Do you have any idea on this?
Stan Zhang (China)
------------------ Original ------------------
From: "fluid-dev-request"<address@hidden>;
Date: Thu, Mar 21, 2013 00:01 AM
To: "fluid-dev"<address@hidden>;
Subject: fluid-dev Digest, Vol 119, Issue 4
Send fluid-dev mailing list submissions to
address@hidden
To subscribe or unsubscribe via the World Wide Web, visit
https://lists.nongnu.org/mailman/listinfo/fluid-dev
or, via email, send a message with subject or body 'help' to
address@hidden
You can reach the person managing the list at
address@hidden
When replying, please edit your Subject line so it is more specific
than "Re: Contents of fluid-dev digest..."
Today's Topics:
1. Re: Is it possible to immigrate FluidSynth to a
DSP(ADSP21xxx) or an CORTEX-M4 CPU? (Aere Greenway)
2. Re: Feature Request: Load everything into RAM to make program
changes instant (Nils Gey)
3. Re: Feature Request: Load everything into RAM to make program
changes instant (David Henningsson)
----------------------------------------------------------------------
Message: 1
Date: Tue, 19 Mar 2013 10:15:59 -0600
From: Aere Greenway <address@hidden>
To: FluidSynth mailing list <address@hidden>
Cc: *simple* <address@hidden>
Subject: Re: [fluid-dev] Is it possible to immigrate FluidSynth to a
DSP(ADSP21xxx) or an CORTEX-M4 CPU?
Message-ID: <address@hidden>
Content-Type: text/plain; charset="iso-8859-1"; Format="flowed"
My response is perhaps a side-note regarding your question.
In my experience, the better soundfonts are nearly 60 megabytes in
size. The Fluid_R3GM soundfont (which is my favorite of the free
soundfonts) is 142 megabytes.
If you must live with a 32 megabyte limit for soundfonts, the "TimGM6mb"
soundfont (distributed with MuseScore) is pretty good, but its French
Horn sound is out-of-tune in a fair number of notes. But at least, this
6-megabyte soundfont doesn't sound overall like a toy musical instrument.
- Aere
On 03/19/2013 08:17 AM, *simple* wrote:
> I plan to immigrate FluidSynth to CORTEX-M4. Could anyone please give
> me some hints?
> The Cortex-M4 system I am going to use: 1MByte flash code memory.
> 192KByte internal SRAM, with FPU, 168MHz, 32MByte external parallel
> NOR flash (for soundfont). Is it possible to immigrate Fluidsynth to
> cortex-M4 with these limits (64 polyphony)?
> I've tried to use optimized cortex-m4 ASM to replace FluidSYnth's
> lowpass filter, linear interpolation, reverb, chorus. And I also tried
> to reduced the memory needed down to 240KBytes. At this moment,
> without concerning the low speed of reading external flash
> (soundfont), it looks that 192KByte, 168MHz limit would be OK.
> However, the low speed of reading external flash seems to be a big
> problem:
> the flash IC is 90ns, which means you can read 16bits (1 sample point)
> every 90ns. To make a 64 polyphone rendering, and output at 44.1kHz,
> for each output sample, you need to read at least 64*2 samples (if
> linear interpolation is used), this is 128*90ns=11.52us, which is
> already 50% time of the sample period of 44.1KHz. So, I am afraid I
> will have to use DMA to do the readings to the audio samples, so that
> rendering and transfering audio sample data at the same time. This
> will need some more (maybe 10KBytes) memory buffering space, and
> increase the complicacy. I wonder if it is really the only choice here
> to do DMA for transferring audio sample data?
> Does anybody here have similar question/experience? And what's your
> solution?
>
>
> _______________________________________________
> fluid-dev mailing list
> address@hidden
> https://lists.nongnu.org/mailman/listinfo/fluid-dev
--
Sincerely,
Aere
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.nongnu.org/archive/html/fluid-dev/attachments/20130319/249a16a0/attachment.html>
------------------------------
Message: 2
Date: Tue, 19 Mar 2013 17:54:03 +0100
From: Nils Gey <address@hidden>
To: David Henningsson <address@hidden>
Cc: FluidSynth mailing list <address@hidden>
Subject: Re: [fluid-dev] Feature Request: Load everything into RAM to
make program changes instant
Message-ID: <address@hidden>
Content-Type: text/plain; charset=US-ASCII
On Tue, 19 Mar 2013 14:14:47 +0100
David Henningsson <address@hidden> wrote:
> On 03/19/2013 01:55 PM, Nils Gey wrote:
> > Hello,
> >
> > could you please add a running or loading mode to load an sf2 completely into memory?
> > The goal is that program changes (and bank?) get rid of the load hiccups and the new sound is available in an instant.
>
> It already is loaded completely into memory. It tries to lock it too, so
> it does not get swapped out.
> (If you get the message "Failed to pin sample data to RAM, swapping is
> possible" warning, you know it failed.)
>
> Any hiccups you might get would be related to CPU bound activities
> happening at program/bank changes, but these should not cause underruns
> if priorities are set right; possibly delays to midi events coming after.
>
> Is this Windows or Linux, btw? I don't know the Windows parts very well.
>
> // David
>
Linux.
Then maybe it is a different issue? Does fluidsynth make sure that program changes (and CCs etc.) which happen on the same tick/time value or are received at the same time (via the lib) as note ons always come first?
My problem is that if I send a program change and the first note at the same time the first note plays back with the old program, either program 0 on program start or if fluidsynth kept running in between the current channel program.
Nils
------------------------------
Message: 3
Date: Tue, 19 Mar 2013 20:03:23 +0100
From: David Henningsson <address@hidden>
To: Nils Gey <address@hidden>
Cc: FluidSynth mailing list <address@hidden>
Subject: Re: [fluid-dev] Feature Request: Load everything into RAM to
make program changes instant
Message-ID: <address@hidden>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
On 03/19/2013 05:54 PM, Nils Gey wrote:
> On Tue, 19 Mar 2013 14:14:47 +0100
> David Henningsson <address@hidden> wrote:
>
>> On 03/19/2013 01:55 PM, Nils Gey wrote:
>>> Hello,
>>>
>>> could you please add a running or loading mode to load an sf2 completely into memory?
>>> The goal is that program changes (and bank?) get rid of the load hiccups and the new sound is available in an instant.
>>
>> It already is loaded completely into memory. It tries to lock it too, so
>> it does not get swapped out.
>> (If you get the message "Failed to pin sample data to RAM, swapping is
>> possible" warning, you know it failed.)
>>
>> Any hiccups you might get would be related to CPU bound activities
>> happening at program/bank changes, but these should not cause underruns
>> if priorities are set right; possibly delays to midi events coming after.
>>
>> Is this Windows or Linux, btw? I don't know the Windows parts very well.
>>
>> // David
>>
>
> Linux.
>
> Then maybe it is a different issue? Does fluidsynth make sure that program changes (and CCs etc.) which happen on the same tick/time value or are received at the same time (via the lib) as note ons always come first?
>
> My problem is that if I send a program change and the first note at the same time the first note plays back with the old program, either program 0 on program start or if fluidsynth kept running in between the current channel program.
What version of FluidSynth are you running? 1.1.0 and 1.1.1 could have
had some ordering bugs.
In all other versions, AFAIK, things happen in the order they are sent
to the engine. For MIDI files, that would be in the order you find the
events in the MIDI file. There is no reordering.
Could you clarify how you mean that you send two things at the same
time? The MIDI engine, internally and as accessed through the API,
processes events one at a time.
// David
------------------------------
_______________________________________________
fluid-dev mailing list
address@hidden
https://lists.nongnu.org/mailman/listinfo/fluid-dev
End of fluid-dev Digest, Vol 119, Issue 4
*****************************************
.