El "stack de audio" es esa parte del OS que te permite escuchar los diálogos ̶d̶e̶l̶ ̶p̶o̶r̶n̶o̶ de las películas, música, tener notificaciones con sonido, etc... MacOS lo tiene. Windows lo tiene. Arrancas el ordenador, enchufas cualquier altavoz comprado en el todo-a-cien, abres una o varias aplicaciones a la vez y todo se escucha. Sin dramas, sin complicaciones. Es lo único que pide y se espera el 836% de los usuarios en desktop. Fin. ... y luego está Linux...
Comentarios
Pues si en la otra mierda no se había enterado de nada, en esta aún menos. Se olvida que OSS se hizo de pago y por eso no quedó otra que montar ALSA. Por eso sólo podías tener las últimas versiones si compilabas tú el kernel: porque tenías que pagar por ellas e instalarlas aparte. Además, el diseño de ALSA es superior al de OSS precisamente porque su API se basa en una biblioteca, y no un fichero de dispositivo en /dev, que es precisamente lo que permite "emular la API de ALSA desde donde te de la gana". ESO es hacer las cosas bien. El que OSS utilice un dispositivo e IOCTLs es una limitación bastante gorda. Pero este tío, obviamente, en su vida ha programado nada a ese nivel, y se limita a soltar cuatro payasadas que ha escuchado a saber donde.
Por otro lado, aunque es verdad que Lennart Poetering (el creador de PulseAudio) es para darle de comer aparte, sí es cierto que buena parte de los problemas de PulseAudio originales no eran por su código, sino por los drivers de las tarjetas de sonido: PulseAudio utilizaba un montón de funcionalidades avanzadas de las tarjetas, y al no estar los drivers bien pulidos, pasaba lo que pasaba. Esos problemas están más que superados, y desde hace años PulseAudio funciona perfectamente y permite tener "un sonido que, simplemente, funciona", incluso con control de volumen independiente para cada aplicación y multitud de cosas más.
Encima, pretendía "parchear los drivers de OSS para hacer el mixing por software"... ¡Claro hombre! ¡Hacemos el mixing por software DENTRO DEL KERNEL! ¿NO? Claro que sí... si ya te quejas de que las cosas van como van, metemos una operación como esa dentro del kernel, para que el más mínimo fallo provoque un kernel panick... di que sí. Las cosas hay que hacerlas bien, y todo lo que se pueda mover al espacio de usuario debería ir al espacio de usuario. Pero parece que una máxima tan sencilla se le escapa.
Y bueno, mezclar SDL y GStreamer como si pretendiesen ser lo mismo que ALSA y OSS o que PulseAudio ya es el colmo. Otra vez más, este tío no se entera de nada. Aparte de que PulseAudio es mucho más que una interfaz para la tarjeta de sonido física (cosa que sí son ALSA y OSS).
En fin... otro artículo de mierda de alguien que ha escuchado campanas y no sabe donde.
#4 Pipewire funciona. SDL2 es un intermediario multimedia multiplataforma y gstreamer es una plataforma de codecs a lo DirectShow.
Voto sensacionalista por no votar puta mierda.
#9 Corrige: pipewire TAMBIEN funciona.
#10 Pipewire manda a Pulse y Jack al cuerno. Ya lo han metido en Slackware -current, y lo que diga Pat va a misa. Un problema menos.
#12 Has editado el comentario. Pero efectivamente, Pipewire reemplaza a Pulse y a Jack. Lo que decía es que Pulse hace años que funciona, y Pipewire simplemente mejora aún más la situación.
#14 Es lo que me jode. Echan pestes a Linux por el audio cuando con Windows puedes pasarlas putas con ASIO, codecs FFDShow y similares. Y meter a SDL y Gstreamer es no tener ni puta idea de lo que se habla, SDL funciona desde Windows a Linux, OSX, Haiku, BSD y creo que hasta la PSP. Por supuesto, también en Android. Y en vídeo soporta hasta framebuffer y GL bajo DRM.
#15 Tal cual. El tío ha soltado cuatro estupideces sin base alguna.
#4 Sobre iotcl's, ojo que el audio en plan9/9front funciona así pero como cada ventana en rio tiene su propio namespace el usar la API en bruto en 9front funciona incluso con varios sonidos a la vez. Y con OSS4 (que es libre) creo que también se puede.
#4 Es que no me jodas, que la solución a los problemas de audio de Linux sea montar una empresa de transporte por autobús...
#22 Pero mira que eres ignorante... ¡¡¡es de POSTRES!!! ¡¡¡POS-TRES!!!
Yo en la vida he tenido problemas de audio con linux.
Que no digo que estas cosas no tengan su trasfondo, pero que al usuario, mientras funcione, todo lo demás le trae sin cuidado.
#5 Afortunado tu, a mi los mismos cascos bluetoth en un mes ya me han funcionado de 3 maneras distintas según van entrando nuevas versiones del kernel y de pulseaudio
Meneo porque es un artículo técnico, que no he entendido nada, por tanto debe ser bueno.
#1 yo he llegado al punto de "ya no quiero entender nada".... pero es el artículo definitivo para entender por que este no es el año de Linux en el escritorio
#2 Yo, sin creerme superior, sí que he alentado en el trabajo alguna discusión , es divertido entrar en el departamento de ingeniería y decir que has estado con tal o cual comercial de MS y te han dicho que Ubuntu debería sustituir a Debian en nuestros servidores X.
Es sentarme, no entender nada y reirme de que lo toman tan a pecho como un talibán.
Sigo sin entender a los usuarios que quieren Windows, o Mac, y se instalan Linux. Si tegusta tanto tu sistema operativo, ¿por qué te instalas Linux?, y sobre todo ¿por qué quieres que Linux se comporte como tu S.O.?
#19 Mejor me lo pones.
Por cierto, con Alsa y DMIX (por defecto en 2003) no hacia falta Arts o ESD. Todo funcinaba, y para OSS ALSA proveía wrappers y módulos que cargaban compatibilidad OSS.
>como el mixing por software que no terminaba de funcionar
Los cojones. DMIX tiraba de lujo.
Encima, el iletrado este mezcla Jack con Arts. Jack es el equivalente a ASIO en Windows y por supuesto tiene también sus quebraderos de cabeza sobre apropiarse de salidas y entradas.
https://wikiless.org/wiki/Audio_Stream_Input/Output?lang=es
Ah, sndio es de OpenBSD. En OpenBSD funciona de puta madre pero en Linux NO, no tiene soporte de entradas correctamente. Lo sé porque los de Void lo adaptaron y siguen adaptando pero sigue sin ser equivalente a Pipewire. Y tengo mucho respeto a sndio, que conste. Configurar una interfaz loopback en OpenBSD está tirado.
Pues, que yo recuerde, NO he tenido nunca ningún problema de sonido en Linux (como los relatados en la entradilla). Y mira que llevo probadas cantidad de distros diferentes en diferentes PCs.
Por el contrario, donde sí he tenido problemas es al intentar instalar Windows 7 en algunos PCs, (incluídos PCs de marcas de prestigio) y en los que el mencionado S.O. NO reconocía la tarjeta de sonido integrada (ni otras tarjetas externas), ni había manera de conseguir los drivers. (Y sin embargo Linux lo reconocía y lo hacía funcionar todo al instante).
#8 En mi NUC no había forma de instalar los drivers DE SONIDO con un SOC cutre de estos de Intel. Había que bajarse drivers GRÁFICOS de Intel modificados de Megaupload. Drivers para Windows 10.
Antes de que salte alguien con Windows Update, drivers del fabricante? (JUAS) y SDI Tool Origin, todas estas herramientas NO lo pillaron. Tampoco con la herramienta de actualización de drivers de Intel.
Slackware -current salvo el driver de audio que requería un kernel más reciente (y no estoy seguro pues cacharreando con Qasmixer y /lib/modprobe.d/alsa.conf lo arreglé) me pilló todo a la primera.
#8 Hace dos décadas había esos problemas, pero hace muuuuuucho que están más que solucionados. Este tío se quedó en 1997.
#16 Yo tuve Debian Woody y con el kernel 2.4 se podía configurar DMIX creo.
Habia que arrancar con "bf24" en el prompt del instalador del CD si no recuerdo bien.
#8 cómprate unos cascos bluetooth con micro y ya me cuentas. Es un drama.
Use Wayland
Esperando estoy al capítulo de Systemd... no me gusta aunque he de reconocer que simplifica algunas cosas es una Hidra.
El Poetering se debería organizar un poco y colaborar en vez de imponer sus ideas como lo hace.
#21 Huy... como haga uno sobre systemd, y lo haga como creo que lo haría... ¡me voy a poner las botas!