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 FAKEBLOCKING
in s_audio_pa.c
I haven't tried this - don't have time right now - but if you're willing I'd be eager to hear how it turns out :)
Miller
On Sun, Dec 09, 2012 at 11:12:01AM +0100, Roman Haefeli wrote:
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 meant by "good", respectively "bad" sound quality. Is there any strong indication that this will help in increasing the latency?
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?
Roman
On Die, 2012-12-04 at 08:54 -0800, Miller Puckette wrote:
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' OSS in linux -
http://www.ubuntugeek.com/howto-install-oss4-in-ubuntu-10-04-lucid-for-bette...
cheers Miller
On Tue, Dec 04, 2012 at 03:23:12PM +0100, Roman Haefeli wrote:
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 200ms.
With -jack, neither the -audiobuf nor the -blocksize parameter have any effect. It seems only the parameters applied to jackd have any effect on the audio buffer, but non of the pd parameters (-audiobuf / -blocksize). In jackd, the maximum I can have is 4096 frames/period and 2 periods/buffer which corresponds to 186ms @ 44.1kHz. Setting any higher number for 'periods/buffer' results in the jackd server not staring.
Recently, I figured that running Pd on Windows (7) with ASIO allows to set virtually any -audiobuf value which allows to do tons of stuff in zero logical time without risking a drop-out. I'd love to be able to do that as well in linux. Is it possible? Or is this is an advantage of Windows/Asio over Linux/Alsa?
Cheers Roman
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list