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
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
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
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
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 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 :)
Hey, I can compile Pd now with portaudio support!
I applied your suggested change, re-compiled Pd and it seems now the default back-end is -pa.
It turns out, that I am only able to open ALSA through portaudio, when no pulseaudio daemon is running. Turning pulseaudio off is not as easy as 'pulseaudio --kill', as the daemon will automatically be relaunched in a standard Ubuntu environment. I had to write:
autospawn = no
to ~/.pulse/client.conf and then do 'pulseaudio --kill' in order to really stop it.
Now I was able to select the 'raw' soundcard through the portaudio dialog of Pd. It turns out that with your proposed change to s_audio_pa.c I can set an arbitrarily high buffer. With an audio buffer setting of 1000ms I was able to do stuff like:
[1000000( | [until] | [pow 123.456]
without getting any drop-outs! Mission accomplished. Many thanks for your help!
Regarding callbacks: This was without checking the 'use callbacks' checkbox in the portaudio dialog. I wasn't able to change the audio buffer when it was checked withouth Pd crashing. Also when I check it after using a high buffer setting, Pd crashes:
*** glibc detected *** pd: free(): corrupted unsorted chunks: 0x082797b8 *** ======= Backtrace: ========= /lib/i386-linux-gnu/libc.so.6(+0x75ee2)[0xb7506ee2] /usr/lib/i386-linux-gnu/libportaudio.so.2(+0x1a45f)[0xb767545f] /usr/lib/i386-linux-gnu/libportaudio.so.2(+0x8a73)[0xb7663a73] /usr/lib/i386-linux-gnu/libportaudio.so.2(+0xb365)[0xb7666365] /usr/lib/i386-linux-gnu/libportaudio.so.2(Pa_CloseStream+0x73)[0xb7661f83] pd(pa_close_audio+0x21)[0x8119fb1] pd(sys_close_audio+0xe5)[0x80ca4c5] pd(m_mainloop+0x917)[0x80bbad7] pd(main+0x1b)[0x8055deb] /lib/i386-linux-gnu/libc.so.6(__libc_start_main+0xf3)[0xb74aa4d3] pd[0x8055e11]
Anyway, I am very glad to see this work in Linux. Will have to test it on the machine with the 'real' soundcard as I only tested with a build-in "HDA Intel, CONEXANT Analog".
Many thanks for your help, Roman
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 probably already know/do this.. but there are a couple of factors which can create dropouts/clicks which seem independent from bleeding-edge-realtime etc. settings:
- CPU: be sure to set it to "performance" and *not* on demand
- Lots of (Pd) gui objects (e.g. sliders, numberboxs) manipulation/updates.
Lorenzo.
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 priorities? Or would I be better off then with standard settings?
You probably already know/do this.. but there are a couple of factors which can create dropouts/clicks which seem independent from bleeding-edge-realtime etc. settings:
- CPU: be sure to set it to "performance" and *not* on demand
Yeah, it appears to me that only since a few years this is an issue for me on Linux laptops (not so on non-mobile computers). Somehow the CPU frequency scaling manager is too slow for Pd, so often it sticks to the lower frequency, although Pd is using 100% CPU (or probably it is related to multi-core CPUs? I don't know).
$ sudo cpufreq-selector -g performance
seems to get rid of the issue.
- Lots of (Pd) gui objects (e.g. sliders, numberboxs) manipulation/updates.
The reason I'm interested in huge latencies is exactly because of this. I'm using Pd in non-interactive setups, so the huge latency doesn't matter. On the other hand, the big latency allows for doing a lot of stuff in zero logical time without risking drop-outs. One example is load new presets while the patch is running, which means reading and parsing a text file, setting loads of number boxes and sliders, loading a number of soundfiles into [readsf~]s or [readanysf~]s, all this in zero logical time. With low latency, this is much more complex while avoiding drop-outs (like loading the preset step-by-step, for instance).
Roman
-
Lorenzo Sutton -
Miller Puckette -
Roman Haefeli