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-better-sound-quality.html > > > > 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 > > > > > > > > > > > > _______________________________________________ > > > [email protected] mailing list > > > UNSUBSCRIBE and account-management -> > > > http://lists.puredata.info/listinfo/pd-list > > > > _______________________________________________ > [email protected] mailing list > UNSUBSCRIBE and account-management -> > http://lists.puredata.info/listinfo/pd-list _______________________________________________ [email protected] mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
