La experiencia habitual es que ALSA se porta mejor, incluso con las tarjetas de sonido embutidas en las placas base, que los drivers de audio de Windows, así que me extraña lo tuyo.
Arranca qjackctl (JACK Control) y pulsa Setup. Haz clic en Realtime y en Force 16bit. Ahora te sugiero jugar con los valores Frames/Period y Periods/Buffer. Prueba con valores conservadores como 2048/16. Si consigues que funcione establemente, ve bajando los valores. Cuanto más bajos, menor la latencia. Con la tarjeta de la placa base de mi portátil funciona con 256/2 para 11,6 ms. de latencia. Prueba también a poner en Audio Playback only si no vas a grabar con la tarjeta. En el peor de los casos puedes probar a activar No Memory Lock y Unlock Memory pero si y sólo si tienes más de un giga de memoria.
Ya nos cuentas...
Gracias por tu consejo:
Nada. He probado estos valores una y otra vez pero sólo consigo peores resultados. Lo bueno es que con los valores 256/2 que dices me marca la misma latencia de 11.6ms, que además deberia de ser imperceptible, pero luego me encuentro que el sonido es pésimo. No se cual problema, pero lo que es seguro es que el registro de jack se llena de xrun en rosa o rojo, y de vez en cuando un skipped.
Me da mucha pena no poder ni empezar con sonido en Linux porque es una cuestión de orgullo el demostrar que LInux sirve también para profesionales de escritorio, pero no puedo ni tan sólo cruzar el umbral de la puerta.
¿ Qué hay en /etc/security/limits.conf?
Esto es:
marcel@ubuntu:~$ cat /etc/security/limits.conf
# /etc/security/limits.conf
#
#Each line describes a limit for a user in the form:
#
#
#
#Where:
# can be:
# - an user name
# - a group name, with @group syntax
# - the wildcard *, for default entry
# - the wildcard %, can be also used with %group syntax,
# for maxlogin limit
#
# can have the two values:
# - "soft" for enforcing the soft limits
# - "hard" for enforcing hard limits
#
# can be one of the following:
# - core - limits the core file size (KB)
# - data - max data size (KB)
# - fsize - maximum filesize (KB)
# - memlock - max locked-in-memory address space (KB)
# - nofile - max number of open files
# - rss - max resident set size (KB)
# - stack - max stack size (KB)
# - cpu - max CPU time (MIN)
# - nproc - max number of processes
# - as - address space limit
# - maxlogins - max number of logins for this user
# - maxsyslogins - max number of logins on the system
# - priority - the priority to run user process with
# - locks - max number of file locks the user can hold
# - sigpending - max number of pending signals
# - msgqueue - max memory used by POSIX message queues (bytes)
# - nice - max nice priority allowed to raise to
# - rtprio - max realtime priority
# - chroot - change root to directory (Debian-specific)
#
#
#
#* soft core 0
#* hard rss 10000
#@student hard nproc 20
#@faculty soft nproc 20
#@faculty hard nproc 50
#ftp hard nproc 0
#ftp - chroot /ftp
#@student - maxlogins 4
# End of file
@audio - rtprio 99
@audio - memlock 512000
Espero que veas algo que pueda cambiar.
Saludos.
Insisto, es muy razonable que tu tarjeta tenga tamaños de buffer fijos y que sólo te funcione con un valor de Frames/Period. Mi RME --¡una RME, nada menos!-- sólo funciona a 32 bits con 1024 y 256. Prueba con todos los valores, no te dejes ni uno.
También ayudará que nos pongas los mensajes que te devuelve jackd, por si algo se nos escapa.
Pongo una muestra del registro de jack. Los valores son:
Priority: 0 (creo que es lo mejor, no?)
Frames: 256
sample rate: 44100
periods buffer: 2
Force 16 bit: enabled
el resto está por defecto. La latencia estimada es de 11.6msec.
________________________
22:57:22.227 Patchbay deactivated.
22:57:22.256 Statistics reset.
22:57:22.371 MIDI connection graph change.
JACK tmpdir identified as [/dev/shm]
22:57:22.478 MIDI connection change.
22:57:25.891 Startup script...
22:57:25.891 artsshell -q terminate
JACK tmpdir identified as [/dev/shm]
can't create mcop directory
Link points to "/tmp/ksocket-marcel"
22:57:26.498 Startup script terminated with exit status=256.
22:57:26.499 JACK is starting...
22:57:26.500 /usr/bin/jackd -R -p128 -u -dalsa -dhw:0 -r44100 -p256 -n2 -s -S
22:57:26.502 JACK was started with PID=5979 (0x175b).
jackd 0.103.0
Copyright 2001-2005 Paul Davis and others.
jackd comes with ABSOLUTELY NO WARRANTY
This is free software, and you are welcome to redistribute it
under certain conditions; see the file COPYING for details
JACK compiled with System V SHM support.
loading driver ..
apparent rate = 44100
creating alsa driver ... hw:0|hw:0|256|2|44100|0|0|nomon|swmeter|soft-mode|16bit
control device hw:0
configuring for 44100Hz, period = 256 frames, buffer = 2 periods
ALSA: final selected sample format for capture: 16bit little-endian
ALSA: use 2 periods for capture
ALSA: final selected sample format for playback: 16bit little-endian
ALSA: use 2 periods for playback
22:57:28.521 Server configuration saved to "/home/marcel/.jackdrc".
22:57:28.522 Statistics reset.
22:57:28.763 Client activated.
22:57:28.767 Audio connection change.
22:57:28.773 Audio connection graph change.
JACK tmpdir identified as [/dev/shm]
22:57:48.340 Audio connection graph change.
22:57:48.376 MIDI connection graph change.
22:57:48.480 Audio connection change.
22:57:48.481 MIDI connection change.
delay of 11443.000 usecs exceeds estimated spare time of 5598.000; restart ...
22:58:03.342 XRUN callback (1).
delay of 5622.000 usecs exceeds estimated spare time of 5444.000; restart ...
22:58:04.969 XRUN callback (1 skipped).
delay of 5417.000 usecs exceeds estimated spare time of 3725.000; restart ...
22:58:06.871 XRUN callback (3).
delay of 5459.000 usecs exceeds estimated spare time of 3725.000; restart ...
delay of 5462.000 usecs exceeds estimated spare time of 3725.000; restart ...
22:58:06.981 XRUN callback (2 skipped).
________________________________
...i mientras tanto el sonido es horrible, claro.
También he probado a añadir la linea con valor nice 10 e incluso -19 para forzar prioridad de cpu pero no ha cambiado nada después de reiniciar el ordenador. También he arrancado jack y mientras funcionaba he probado a modificar la prioridad en el registro de procesos del monitor de gnome pero tampoco cambia nada. Está claro que no tiene que ver con problema de capacidad de proceso del sistema.
Hay algo más y por lo que veo no es algo raro ya que más usuarios se quejan de lo mismo.
Saludos.
Sólo decíros que he probado a poner 3 en buffer con 256 frames y no me ha dado problemas de sonido aunque los xrun van saliendo de vez en cuando. No quisiera cantar victoria antes de tiempo pero creo que ya veo por donde van los tiros. Gracias ivalladt y guitman por vuestros consejos.
Un saludo.
Lo vuelvo a escribir: Es muy habitual que una tarjeta de sonido tenga un tamaño de buffer fijo así que sólo funcione con un valor de Frames específico. En cuanto al buffer, con independencia del valor que pongas las últimas versiones de ALSA van al menor tamaño soportado, para dar la menor latencia posible. Aún así, sigue probando valores altos de buffer y cuéntanos cómo sigue el tema.
Si tienes un giga de memoria, cosas como activar el no memory lock también podría ayudar...
OK. Para que lo entienda, ¿cuales son los valores que exigen más rendimiento del ordenador pero que dan mejor calidad de sonido?... ¿cuanto más altos o cuanto más bajos?. Porque subiendo a 4 buffers va incluso mejor. Pero no puedo subir a 1024 frames. sólo puedo hasta 512. Veo que tengo varias opciones (no entiendo entonces porque no funcionó al principio cuando juraria haberlas probado todas) y no sé cual es la ideal.
Gracias Ivalladt por tu ayuda. Saludos.