fluid-dev
[Top][All Lists]
Advanced

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

Re: [fluid-dev] Fluidsynth + Portaudio device selection


From: Pedro Lopez-Cabanillas
Subject: Re: [fluid-dev] Fluidsynth + Portaudio device selection
Date: Wed, 6 Jun 2012 12:04:50 +0200


On Wed, Jun 6, 2012 at 9:47 AM, Massimo Callegari <address@hidden> wrote:

The option "audio.portaudio.index" may be useful for some use cases, but the
problem for Qsynth users remains: PortAudio may return the same name for two
different indexes (one for DirectSound, and another for WDMKS) so FluidSynth
will remember only one option. The only general solution for this problem is
modifying the strings stored as options for "audio.portaudio.device",
including the device type, index, both, or whatever else.

I do not agree here. "audio.portaudio.index" can NOT be the PortAudio index, since we're talking about applications linking Fluidsynth, and not PortAudio directly. So "audio.portaudio.index" has to be an index of the FS devices list. That's the whole point of doing this change.
Moreover in my solution I kept backward compatibility. Changing the names of the PA devices returned by FS would break all the applications out there that work on devices names.
 
Your first message to the list about this issue explained the problem very clearly: PortAudio returns the same device name for several device indexes, and this prevents a FluidSynth client to select other than the first one. Your preference may be to choose devices by index, but a correct solution for the FluidSynth project must take into account other use cases as well.
 
PortAudio distributions include a "pa_devs" utility, that prints a list of the devices as they are known by PA. So using the PA index is possible, for some use cases.
 
The PA device names used by FluidSynth are different from one machine to another; they cannot be considered part of the API. If a FluidSynth client program has hardcoded a device name, that program is wrong written and deserves the breakage and be ashamed for that.
 

OTOH, the <unistd.h> header inclusion should be protected (instead of removed)

#if HAVE_UNISTD_H
#include <unistd.h>
#endif

HAVE_UNISTD_H is defined (or not) in the cmake generated header "config.h"

Unistd.h include can be removed. It's useless either in Windows or Linux, since FS builds fine without it.
 
Have you tested that in all Unix variants where FluidSynth can be compiled?
 
Regards,
Pedro
 

reply via email to

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