fluid-dev
[Top][All Lists]
Advanced

[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);





reply via email to

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