IMHO I fixed some of the portaudio latency topics. Some findings:
- the SC portaudio code in PortAudioManager.getSuggestedLatency() returns
the value PortAudio.LATENCY_HIGH which translates to -1d. PortAudio JNI
code translates this value into the device specific high latency, for
my device ~46ms. This results into the 2 to 3 packet bursts on my system.
I changed the return of "getSuggestedLatency()" to 20ms (return 0.02d) and
now I get a packet every 20ms from PortAudio.
- Above does not work for the device "default". This device has its own idea
about buffers, latency etc and always has a latency of 46ms for my device.
- Thus I use the device "hw:0,0" as input device, in my select box this is
the first device with the real sound card name. Setting the environment
variable PA_ALSA_PLUGHW to 1 forces PortAudio to use the "plughw:0,0"
device. This is the preferred device setting.
- For output always use "dmix" or any other device that is capable of mixing
2 output streams if the sound HW does not support mixing.
IMHO the handling of the latency parameters in PortAudio needs some rework.
The latency for Windows is set to 100ms, for example. Why this? Or does
PortAudio behaves differently for Windows with respect to latency?
Also we might need to handle the output latency differently, i.e. set higher
than 20ms (on dmix it is currently 46ms on my device). This would then
act as a sort of jitter buffer if I understood the code correctly. PortAudio
will start output as soon as one period of audio data is available.
Emil told me that you are working on PortAudio handling to support wide band
codecs, thus I don't check-in the modifications and keep them in my Git
repository. Once you are ready we can have a look.
Am 10.06.2010 09:18, schrieb Damian Minkov:
here is the source(of the hostapi alsa) for the latest binary that is
in the trunk.
On Wed, Jun 9, 2010 at 8:22 PM, Werner Dittmann > <Werner.Dittmann@t-online.de> wrote:
can you send me the latest patched sources of the pa_alsa
host adapter for portaudio, I would like to dig into this a
I've checked Twinkle's implementation of ALSA and it is _much_
simpler than Portaudio and does not deal with this complex
buffer arithmetic etc.
IMHO Portaudio's buffer management and the way it checks and
reads the data from ALSA is very complex, to state it in a
kind way :-). PA supports MMAP reads and non-MMAP reads which
complicates matters, also it combines blocking with non-blocking
read functions and it seems to have a sort of own thread
monitoring or something similar.
Maybe we need to use a stripped-down version to make it more
<SNIP --- SNAP>
To unsubscribe, e-mail: email@example.com
For additional commands, e-mail: firstname.lastname@example.org