[Top][All Lists]

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

Re: PortAudio driver (was Re: [fluid-dev] New development)

From: Josh Green
Subject: Re: PortAudio driver (was Re: [fluid-dev] New development)
Date: Sat, 31 Jan 2009 20:31:10 -0800

Hello Pedro,

On Sun, 2009-02-01 at 02:05 +0100, Pedro Lopez-Cabanillas wrote:
> I've checked in some changes to the PortAudio driver.
> - PortAudio enumerates devices having input only ports. As we need audio 
> output  devices, I've changed the enumeration to ignore devices with less 
> than 2  output channels available.
> - For the default device name, I've defined the string "PortAudio Default" 
> trying to solve the clash with ALSA's "default" device name. The function 
> Pa_GetDefaultOutputDevice() provides the default device index.
> - Added an assignment for the device index of the matching requested device 
> name.

Sounds like some good stuff.  Thanks for completing those!

> About the Windows tests. The current status of PortAudio is somewhat sad, 
> being optimist. Their autohell build system allows only one backend at once. 
> To compile the WDMKS backend the documentation says that it needs DirectX 
> SDK, but the needed headers come from the Drivers Kit instead. It compiles, 
> but the initialization is deactivated, requiring to uncomment some lines in 
> the file "pa_win_hostapis.c". After some googling you realize that there is 
> an active ticket about this: http://www.portaudio.com/trac/ticket/47
> In order to build Fluidsynth, portaudio.pc needs to be modified by hand. Only 
> to  realize that there is no sound at all. Using different devices doesn't 
> help. PA Test programs don't produce noise, either. It is a problem with the 
> backend code, that only invokes the callback when there is an input stream, 
> in addition to the output one. There are some googles talking about this. 
> Finally, after commenting out the offending condition, there is sound at 
> last!. Buffer size: 64, Buffer count: 2, latency of less than 3 msecs at 
> 48000 Hz. The sample rate depends on the device: there isn't automatic 
> resampling, only the rates supported by the device. The bad news: the first 
> underrun affects very badly the audio quality forever. There is no automatic 
> recovery, or any other solution than restarting over.

That sounds like a pretty sad state of affairs.  Hopefully it will
improve.  The latency under 3 msecs sounds pretty good though.  Having
the sound get out of sync though on an underrun, doesn't sound too nice

> Regards,
> Pedro


reply via email to

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