Hi, Josh,
hi, Pedro,
How are you?
I was hoping to use PortAudio in my own project under Windows and cross
platform. The current state of affairs does sound quite discouraging.
Thank you for your work. Keep up the good work!
May the Lord bless you,
Philip
Josh Green wrote:
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
though.
Regards,
Pedro
Cheers!
Josh
_______________________________________________
fluid-dev mailing list
fluid-dev@nongnu.org
http://lists.nongnu.org/mailman/listinfo/fluid-dev
_______________________________________________
fluid-dev mailing list
fluid-dev@nongnu.org
http://lists.nongnu.org/mailman/listinfo/fluid-dev
