On Sun, 2012-12-09 at 13:39 -0800, Miller Puckette wrote:
grasping at straws but... maybe try Alsa using callbacks - so that Pd
maintains the FIFO instead of having ALSA do it. I think you can do
this by opening ALSA through portaudio, requesting blocking in Pd but
replace
#if
On 09/12/12 11:12, Roman Haefeli wrote:
[...]
If my intent to have an as huge as possible latency in order to decrease
likeliness of drop-outs, it is still advised to use a low latency kernel
and run Pd/Jackd with realtime priorities? Or would I be better off then
with standard settings?
You
On Mon, 2012-12-10 at 13:17 +0100, Lorenzo Sutton wrote:
On 09/12/12 11:12, Roman Haefeli wrote:
[...]
If my intent to have an as huge as possible latency in order to decrease
likeliness of drop-outs, it is still advised to use a low latency kernel
and run Pd/Jackd with realtime
So the current state of affairs is that it is not easily possible on
linux? Is this in the responsibility of the application or the audio
back-end? I ask in order to find out whether this is the right list to
discuss the issue.
It remains in the dark what the author of the ubuntugeek article
grasping at straws but... maybe try Alsa using callbacks - so that Pd
maintains the FIFO instead of having ALSA do it. I think you can do
this by opening ALSA through portaudio, requesting blocking in Pd but
replace
#if defined(__APPLE__)
#define FAKEBLOCKING
#endif
with just
#define
Hi all
For certain types (non-interactive) Pd patches, I'd like to be able to
set a large audio buffer, say 1s or more. However, I figured I'm not
able to do that on linux.
With -alsa only the -blocksize parameter has any effect, but the maximum
allowed value is 2048 which still feels like only
Looks like the snd_pcm_hw_params_set_buffer_size_near(0 call in
s_audio_alsa.c is truncating the buffer rudely (when I tried an advance
of 10 seconds it went from 48000 to 43690 (one device) and 2048 (a different
one).
I don't know any easy way around this... perhaps it's time to look at
'native'
