[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[fluid-dev] More commits on the way to 1.1.1
From: |
josh |
Subject: |
[fluid-dev] More commits on the way to 1.1.1 |
Date: |
Mon, 16 Nov 2009 00:04:17 -0800 |
User-agent: |
Internet Messaging Program (IMP) H3 (4.1.6) |
I just committed code to make preset querying use the most recent
assigned preset. I also added the code below to the public API as per
previous discussions.
I'm not completely happy with the new API though, since it does seem
really close to fluid_synth_get_program() in functionality and is semi
overcomplicated by using a structure. There is only the name and
assigned fields which are additional. I'm tempted to just add a
simple fluid_synth_get_program_info() function with an added name
buffer pointer of fixed length and the return value could indicate if
there is an assigned preset or not. That would be more like what the
current API is. What do you think?
I did not resolve the issue in regards to program changes causing
mutex locks in the synthesis thread. It seems like ideally the return
event queue would have a counting semaphore that the normal priority
helper thread could block on, waiting for work. As soon as it got
events, it would operate on them. Program changes could then be
passed as return events to the worker thread to be processed. I'm not
sure how to implement that without requiring locking also though,
since GCond is supposed to be used with a mutex and there is no native
counting semaphore type in glib.
Anyone know if mutex locking is an issue between a realtime thread and
a non-realtime thread? Some information points to the possibility
that if a realtime thread blocks on a mutex that a lower priority
thread is holding, the lower priority thread will be elevated to high
priority (in the case of SCHED_FIFO and non SCHED_FIFO for example).
In this case, using a mutex only for use with a signaling GCond, might
not be an issue. The likeliness of there being any lock contention is
minimal and the lock would not be held for long. It could be a
problem though, if the lower priority thread doesn't get elevated when
there is contention.
Josh
#define FLUID_PRESET_INFO_NAME_LENGTH 32
/**
* Preset information structure.
* @since 1.1.1
*/
struct _fluid_preset_info_t
{
int assigned; /**< TRUE if a preset is assigned, FALSE otherwise */
int sfont_id; /**< ID of parent SoundFont */
int bank; /**< MIDI bank number (0-16383) */
int program; /**< MIDI program number (0-127) */
char name[FLUID_PRESET_INFO_NAME_LENGTH]; /**< Preset name */
};
int fluid_synth_get_channel_preset_info
(fluid_synth_t *synth, int chan, fluid_preset_info_t *info);
- [fluid-dev] More commits on the way to 1.1.1,
josh <=
- Re: [fluid-dev] More commits on the way to 1.1.1, Rui Nuno Capela, 2009/11/16
- Re: [fluid-dev] More commits on the way to 1.1.1, josh, 2009/11/16
- Re: [fluid-dev] More commits on the way to 1.1.1, Rui Nuno Capela, 2009/11/16
- Re: [fluid-dev] More commits on the way to 1.1.1, josh, 2009/11/16
- Re: [fluid-dev] More commits on the way to 1.1.1, David Henningsson, 2009/11/16
- Re: [fluid-dev] More commits on the way to 1.1.1, josh, 2009/11/16
- Re: [fluid-dev] More commits on the way to 1.1.1, josh, 2009/11/17
- Re: [fluid-dev] More commits on the way to 1.1.1, Pedro Lopez-Cabanillas, 2009/11/16
- Re: [fluid-dev] More commits on the way to 1.1.1, josh, 2009/11/16
- Message not available
- Re: [fluid-dev] More commits on the way to 1.1.1, Corbin Simpson, 2009/11/17