[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[fluid-dev] Re: libsndfile support for file rendering

From: josh
Subject: [fluid-dev] Re: libsndfile support for file rendering
Date: Sat, 03 Oct 2009 23:01:03 -0700
User-agent: Internet Messaging Program (IMP) H3 (4.1.6)

Quoting David Henningsson <address@hidden>:
address@hidden skrev:
I just committed libsndfile support for the fast file renderer and
aufile driver.

I had a quick look at the code and I think that it looks good.

The new command line switches are:

It was probably the best way to solve the problem, but I'm afraid we'll
run out of letters soon :-/

Yeah, no doubt!

-T, --audio-file-type: Audio file type (defaults to auto, which
determines format from file extension, with fallback to wav)

Suggest fallback to raw for backwards compatibility.

I was thinking that too. There is currently no fast rendering though, so there is no backwards compatibility in regards to that. The aufile driver though, could fall back to raw. Or maybe it should just complain that it couldn't determine what format to store to and exit..

Which reminds me. There is a bug, where if you specify an invalid format (like a floating point flac file), the player gets hung up in the fluid_player_join() function in the while (player->status == FLUID_PLAYER_PLAYING) loop. I haven't investigated any further. Perhaps you might know what is wrong?

I realize that the file renderer could use even more options.  For
example, the ability to specify a time duration for the render or how
much extra time to render after player ends.  For this reason, I think
it may be a good idea to use a mechanism where we can add additional
options in a backwards compatible fashion.

What do you think about something like this:

I think it is a good idea. And better do it now before 1.1.0, when we
can change the public API.

Right. We could just have the filerenderer use the synth settings instead of taking parameters. It is closely connected to the synth, so I don't see a big problem with using settings for it. And it already has settings for most of its parameters. How about just getting rid of all of them and using settings?

// David


reply via email to

[Prev in Thread] Current Thread [Next in Thread]