[arch-general] Time delay problem with latest [core] kernel
Hi, I'm using the latest kernel from [core] (linux 3.1-4), and experienced a terrible delay of software MIDI synthesizers. I'm using fluidsynth, using ALSA as the output driver (I simply can't get jack working), and VMPK as a keyboard MIDI event generator. The delay used to be fine, but with the latest kernel, it's longer than 0.5 secs --- that's unusable. I believe this should be kernel-related, could you please suggest some solutions or workarounds? -- Carl Lei (XeCycle) Department of Physics, Shanghai Jiao Tong University OpenPGP public key: 7795E591 Fingerprint: 1FB6 7F1F D45D F681 C845 27F7 8D71 8EC4 7795 E591
On Sun, Nov 13, 2011 at 10:00 PM, XeCycle <xecycle@gmail.com> wrote:
Hi, I'm using the latest kernel from [core] (linux 3.1-4), and experienced a terrible delay of software MIDI synthesizers.
I'm using fluidsynth, using ALSA as the output driver (I simply can't get jack working), and VMPK as a keyboard MIDI event generator. The delay used to be fine, but with the latest kernel, it's longer than 0.5 secs --- that's unusable. I believe this should be kernel-related, could you please suggest some solutions or workarounds?
Some more data would be needed. I suggest trying out latencytop. And also checking if for dev in /proc/asound/card*/pcm*/sub*/prealloc; do echo 64 > $dev done solves the problem. I think the first step should be to figure out why Jack does not work, that's supposed to deal with low-latency situations, so using ALSA directly might not have been tested very much for this use.
Tom Gundersen <teg@jklm.no> writes:
On Sun, Nov 13, 2011 at 10:00 PM, XeCycle <xecycle@gmail.com> wrote:
Hi, I'm using the latest kernel from [core] (linux 3.1-4), and experienced a terrible delay of software MIDI synthesizers.
I'm using fluidsynth, using ALSA as the output driver (I simply can't get jack working), and VMPK as a keyboard MIDI event generator. The delay used to be fine, but with the latest kernel, it's longer than 0.5 secs --- that's unusable. I believe this should be kernel-related, could you please suggest some solutions or workarounds?
Some more data would be needed. I suggest trying out latencytop.
I'll have a look.
And also checking if
for dev in /proc/asound/card*/pcm*/sub*/prealloc; do echo 64 > $dev done
solves the problem.
Thanks, this solves it. Curious about what is this?
I think the first step should be to figure out why Jack does not work, that's supposed to deal with low-latency situations, so using ALSA directly might not have been tested very much for this use.
I believed I did every step in the guide (on the arch wiki), also no programs showed any error --- but they can't produce any sound. -- Carl Lei (XeCycle) Department of Physics, Shanghai Jiao Tong University OpenPGP public key: 7795E591 Fingerprint: 1FB6 7F1F D45D F681 C845 27F7 8D71 8EC4 7795 E591
On Sun, Nov 13, 2011 at 11:35 PM, XeCycle <xecycle@gmail.com> wrote:
And also checking if
for dev in /proc/asound/card*/pcm*/sub*/prealloc; do echo 64 > $dev done
solves the problem.
Thanks, this solves it. Curious about what is this?
As of 3.1 the sound buffers were increased from 64 to 4096 kB. This should make it possible to save a lot of wakeups/power with PulseAudio, and (until now) I thought it would not affect anything else. The command I suggested reverts the buffer to the previous size. For more details see my original feature request: <https://bugs.archlinux.org/task/25501>. -t
On 13 November 2011 20:47, Tom Gundersen <teg@jklm.no> wrote:
As of 3.1 the sound buffers were increased from 64 to 4096 kB
Thank you Tom, this one is a very important change, and is exactly what led to the issue of this topic. -- GPG/PGP ID: C0711BF1
participants (3)
-
Ray Rashif
-
Tom Gundersen
-
XeCycle