Una fotografía/vídeo estereoscópica es aquella técnica que permite reproducir la sensación de relieve y volumen de los objetos en quien contempla la imagen. La técnica básicamente consiste en hacer llegar a cada ojo del espectador dos imágenes ligeramente diferentes de tal manera que al procesarlas el cerebro recree la sensación de profundidad de la escena original.
Para conseguir esto hay multitud de técnicas más o menos exitosas, desde un simple GIF animado realizado con una sola cámara que muestra alternativamente el ojo izquierdo/derecho, hasta modernas técnicas cinematográficas de imagen a todo color, a gran resolución de imágenes perfectamente visibles con gafas especiales o sin ellas.
La técnica más primitiva consistiría por tanto en grabar dos imágenes al mismo tiempo y proyectarlas en paralelo para hacer llegar mediante un dispositivo a cada ojo la imagen que le corresponde. Sin embargo hacer llegar dos imágenes con calidad fotográfica y diferentes a cada ojo no es fácil (ni barato si se aspira a cierta calidad). Con el abaratamiento de la electrónica los cascos de realidad virtual se han vuelto razonablemente accesibles en los últimos años, pero aún siguen siendo raros y poca gente dispone de ellos habitualmente, pero lo que sí tiene mucha gente hoy en día es un smartphone, y aquí es donde entra el ingenio de algún ingeniero de Google ¿porqué no usar la pantalla del teléfono móvil y transformarla en un casco de realidad virtual? solo hace falta un poco de cartón, dos lentes y una tijeras y ya tenemos unas Google Cardboard.

Las Google Cardboard son básicamente un recortable de cartón dentro del cual instalamos el teléfono móvil que proyecta un vídeo partido en dos frames, uno para cada ojo (además de un ingenioso sistema de imán para transmitir “clicks” ar una aplicación en nuestro Android). Google distribuye los susodichos planos/instrucciones para construir tu propio casco de realidad virtual en casa y en Ebay las podéis comprar por 3-4 euros. Una vez tenemos nuestro casco de realidad virtual ya solo falta generar nuestro vídeo estereoscópico para el casco.

Vídeo estereoscópico

Como ya he contado muchas veces tengo en casa varias cámaras tipo CCTV. Desde que conseguí mis Google Cardboard llevo queriendo experimentar a juntar dos de estas cámaras y producir mis propias películas 3D caseras, y eso es lo que hice estos días pasados.
La conexión del hardware no tiene más truco, se cogen dos cámaras conectadas al ordenador con idéntico objetivo (6 mm en mi caso) se sitúan en paralelo (teóricamente con una separación de 63 mm entre el centro de ambos objetivos, que es la separación media entre pupilas) y se graban dos vídeos al mismo tiempo de todo lo que se quiera.

Problemas de calidad

La calidad de estas cámaras no es para tirar cohetes como os podéis imaginar, dan para un vídeo de 640×480 px y poco más. No lo que no me esperaba es que dos cámaras idénticas con idéntico objetivo y ubicadas en el mismo sitio dieran imágenes tan sorprendentemente distintas, no ya en nitidez/saturación/contraste (estos miniobjetivos si se les aprieta mucho la rosca del enfoque podemos hacer saltar hacer saltar las lentes por los aires con mucha facilidad. Ya he tenido que montar los cristalitos de algunos de estos objetivos varias veces.)… sino pura y simplemente en encuadre. Me explico: si situamos las dos cámaras una al lado de otra y grabamos a una persona a 2 metros con un encuadre tipo busto/retrato, si la cámara A la encuadra bien, la cámara B la encuadra de los ojos para abajo.

Esto es, como si una de las cámaras tuviera un ligero cabeceo hacia abajo y viera una porción de espacio por debajo de lo que veía la otra. Deduje que esto es muy probablemente producido por ligeras variaciones en la posición del sensor y en el cono de luz que proyecta el objetivo. Una variación de 1-2 mm produce un desplazamiento enorme en la imagen capturada (y no vale con “levantar” ó “agachar” algunas de las cámaras porque al cambiar la altura del centro del objetivo se produce un cambio en las perspectiva/paralelaje que desbarata cualquier intento de 3d).
Estuve probando diversas cámaras pero el resultado era siempre el mismo, no tengo dos cámaras que situadas de forma contigua graben lo mismo a la misma altura.

Después de diversas pruebas, incluida el intento de reajustas la posición del sensor interno de las cámaras opté por un solución salomónica: recortar la salida de ambas cámaras al área compartida por ambas, de tal manera que el fotograma válido por ambas cámaras pasaba de 640×480 a 640×332, se desechaba una franja de 148 en ambas cámaras, en una por arriba y la otra por abajo. Bueno, siempre me han gustado las panorámicas.

Software FFMPEG

Para la grabación y composición de la panorámica de vídeos he usado ffmpeg, un potente editor/conversor de vídeo en linea de comandos pero que ha traído otro pequeño problema: al tomar dos dispositivos y codificarlos a mp4 para producir la composición final producía un ligerísimo retardo (apenas 4-5 frames) en uno de los vídeos de manera que cualquier movimiento en la imagen se producía un poco antes en el ojo izquierdo que en el derecho. Aunque era un retardo muy pequeño, había que fijarse mucho para descubrirlo pero en cambio producía un efecto muy incomodo de falta de sincronía. Nada especialmente grabe que no se pudiera arreglar con la opción itsoffset desde el propio FFMPEG.

Estas son algunos de las líneas de comandos ffmpeg utilizadas para producir el vídeo estereoscópico:

Comando básico para reproducir un dispositivo conectado a la capturadora del ordenador
ffplay -s 640x480 -f v4l2 /device/video4

Capturar, componer y mostrar en tiempo real dos dispositivos de vídeo
ffmpeg -s 640x480 -f v4l2 -i /dev/video4 -s 640x480 -f v4l2 -i /dev/video8 -filter_complex "[0]pad=iw*2:ih[a];[a]overlay=w" -b 2200k -f mpegts - | ffplay -

Retardar ligeramente el “ojo derecho”
ffmpeg -s 640x480 -f v4l2 -i /dev/video4 -s 640x480 -f v4l2 -itsoffset 0:0:00.08 -i /dev/video8 -filter_complex "[0]pad=iw*2:ih[a];[a]overlay=w" -b 2200k -f mpegts - | ffplay -

Recortar (crop) fotogramas, corregir luminancia en ojo derecho y guardar a mp4
ffmpeg -y -s 640x480 -f v4l2 -i /dev/video4 -s 640x480 -f v4l2 -itsoffset 0:0:00.08 -i /dev/video8 -filter_complex "[0]crop=640:340:0:140[a];[1]mp=eq2=0.8:1:0:2[b];[a]pad=iw*2:ih[a];[a][b]overlay=w" video_final.mp4

Todavía quiero hacer algunas pruebas, desplazando cámaras cambiando objetivos, etc.. pero ya se puede ver algo. Si tenéis las Google Cardboard o similar podéis ver el vídeo en grande en esta dirección.

The ever-amazing Plasma team from KDEjust put out a new release of Plasma. I won’t spend much describing how big of an improvement it is - the release announcement at KDE has all the details needed to whet your appetite.

And of course, now it’s the turn of distributions to get out packages for the users at large.

This is also the case for openSUSE. The KDE:Frameworks5 repository hosts the new 5.2 goodness for released distributions (13.1 and 13.2) and Tumbleweed. Packages have also been submitted to Tumbleweed proper (pending legal review, so it will take some time).

Don’t forget the rule of thumb, in case you find problems: bugs in the packages should be directed towards the openSUSE bugzilla, while issues in the actual software should be reported to KDE. You can also discuss your experience on the KDE Community Forums.

Oh yes.. those were great times! Open Sound System was rocking my Linux based sound system and I was having a time of my life. Like we all know good doesn’t last long. Soon after happiness I find out that OSS couldn’t do recording and playing (full duplex) same time. Fiery same time this was working on Windows 98 very well. I was shocked how the heck my Linux box is so borked? Luckily times were changing and this time they formed only better. ALSA was about to take over OSS in Kernel version 2.6. Why I’m talking about ALSA and OSS when I should talk about Pulseaudio? Read further to find out why or go examples for Pulseaudio here: https://github.com/illuusio/linux-audio-example/tree/master/pulseaudio

Open Sound System

First let’s talk about Open Sound System first before going to ALSA. After that we talk about todays topic: Pulseaudio.  I recall correct OSS was the first sound system that provided support for audio in Linux kernel. Even today it’s emulated by ALSA and you can use it as output with Pulseaudio. Real OSS still lives as Proprietary library and it’s implemented in several OS like FreeBSD.
If you look OSS as API point of view it’s very blocking because it uses heavily IOCTL-calls and because they are direct memory calls you have to wait. Only reason I can imagine why someone wants to support OSS in new application is trying to support whole UNIX family. If it’s not must then trust me you don’t want OSS. Event lack of duplex audio wasn’t biggest problem at late ’90.  I had Gravis Ultrasound and OSS support sucked a lot. ALSA wasn’t even pre-alpha and without thinking I jumped that rapidly moving wagon.

ALSA

Advanced Linux Sound Architecture is current Linux Audio API. You should use it for new applications and it has impressive set of supported audio chips. I haven’t find a single audio hardware that doesn’t work. Only problem with ALSA is that is so stable that it’s getting little bit too mature. times have change from ’90 and ALSA is starting look not fantastic like I thought about it first but just OK.
Getting your hardware working is not the complicated case with ALSA. Hard part comes whne you want set up more complicated patterns like USB audio, Bluetooth or send audio to another machine for playing.

Nowadays Every other platforms than Linux desktop had neat audio servers. There have been several attempts for Linux also ESD, KDE audio server and several others that never reached much attention. There is also JACK but it’s again little bit too hard to use and not for old morons like me. Believe I have use it for high-end stuff and I cannot recommend it more but when you just want your audio come from the speaker without routing it half an hour then Pulseaudio is just better, sorry you can hate me being old senile fart.

Pulseaudio

Supported outputs: Alsa, Oss, Jack, Mac OS X, Windows
License: GNU Lesser General Public License 2.1

So why we talked ALSA and OSS? Because Pulseaudio doesn’t handle sound cards. It expects that someone else have knowledge about what cards are in system and how to use them. Pulseaudio just provides common way to use them. But let’s start from beginning shall we? Lennart Poettering is who created Pulseaudio. His new beast Systemd is just like Pulseaudio hated from the start and dividing Linux community but making huge impact in Linux. Pulseaudio was meant to be replacement for Gnome ESD and there is compatibility layer for ESD available.  Pulseaudio works for  KDE, XFCE and others. Prove me wrong but I don’t know anyone how misses ESD! I miss KDE 2.0 Audio server Arts in sentimental moments but in my point of view ESD was horrible piece of crap. My opinion is only Android Audioflinger is more popular audio server in Linux world. Sometimes I wonder why Pulseaudio doesn’t provide Audioflinger compatibility layer? How does Pulseaudio sit top of the Linux audio stack. I try to make nice picture of it.

If you want to talk to sound card you make connection to Pulseaudio server with Pulseaudio C-library and talk to the Pulseaudio. Not direct to ALSA not direct to sound card. Pulseaudio is built upon sockets so you can access Pulseaudio from another machine or from network if you have bandwidth and play your tunes from or to other machine. Pulseaudio takes care about find out what sound cards you may have and connecting to them for example Bluetooth audio device. What is so wrong with Pulseaudio if it’s working so well? Basicly, it adds latency between application and audio coming out of speakers. Not me or not you not your mother are going to spot it but those nerdy super HIFI audio humans (Homo HIFIcus) can spot it. If you have some very bad audio chip there you notice but 99% times you are happier with Pulseaudio than without it.

Stop praising Pulseaudio and get to API

As beautiful as Pulseaudio API is it’s horrible same time! Modern slick callback based monster that just does something and at the you get audio or you can play it so feed me with bytes. I think they noticed this and made blocking Simple API. Which is very simple and easy to use. If you don’t want to use Pulseaudio Simple API then oh boy!
There is two main mode which you can use if we count Simple API out. There is normal mainloop and threaded mainloop. So if you want to control everything you choose mainloop mode. You iterate your mainloop and get events to your callbacks or you can let Pulseaudio do it with pa_mainloop_run() command. In threaded version it just runs and gives you callback as you go. Difference is that threaded loop stays away of you sight and normal blocks your application.

What kind of callbacks there is?

In Pulseaudio question is more like what doesn’t have callback. Stream is ready, check, buffer underrrun, check, something weird just happen, check. You just choose what to implement and then they appear as they happen. Then you choose do something or not.

Is there something wrong with this. No there isn’t, it works as expected. Actually it worked better than I was expecting. Learning curve for Pulseaudio is bit high because fully understanding how Pulseaudio works takes time and patience.

Summary:  Little bit weird pure C API but when correctly implemented very powerful. Widely spread in Linux world such all major distributions use it. Even it support Mac OS X and Windows it’s not really as easily portable at it sounds. It’s little bit Linux specific although BSD family is  beginning to use it. But if you need to support Linux and want to have higher level API than ALSA then this is for you but most frameworks support it so you can also leave it to them and not shovel into API.

In our house we have a very simple system to capture rainwater into a tank. We use it to water our vegetable garden during the dry season.

Parts

We use a 1100 liter water tank. I would have liked something bigger, but there just wasn't enough space for it.

1 is the exit from the roof; water from various roofs in the house gets directed here.

2 is a T connector. On the horizontal side it goes to 3, where it enters the water tank. On the vertical exit side it goes down a relatively long pipe, all the way down to 6, which is a valve or faucet. That long pipe is the "dirty water collection pipe". When it starts raining, the first charge charge of water can be quite dirty from all the dirt on the roof. This dirty water fills the long pipe. The dirt accumulates in the bottom of the pipe, and finally cleaner water will have a chance of filling the tank when the water level in the pipe reaches the T connector.

4 is the overflow pipe. When the tank gets full, any overflowing water will exit through here.

5 is the water tank's exit pipe.

6 is the valve controlling the output from the dirty water collection pipe, as mentioned above.

7 is a normal faucet coming from the water tank. This is where you would plug a garden hose.

The trick is to adjust 6, the valve of faucet at the bottom of the dirty water collection pipe, so that water and dirt can trickle out of it. That is, don't leave it fully closed. The pipe will fill up shortly after it starts raining, allowing the rest of the rain to reach the tank; finally the pipe will empty itself for the next rain.

Does it work!

It works very well! We use the stored rainwater for plants in the vegetable garden. We used that water for construction of the garden's planting beds, to make mortar for bricks. Although we have managed to empty the tank a couple of times during very heavy use, normally it rains often enough that the tank stays almost full.

Note that the tank is basically one storey above ground level. This gives barely enough water pressure for a slow-running garden hose.

2022 Update: Since the installation of the original system in 2015, we have added a flow-activated pressurizer pump so we can irrigate comforatbly.

References

T.H. Thomas and D.B. Martinson, Roofwater Harvesting: A Handbook for Practitioners (PDF)

Creo estar hace tiempo curado de versionitis informática, a saber: esa manía/costumbre/way-of-life de andar instalando/actualizando programas y sistemas operativos constantemente, de forma compulsiva y (sobretodo) innecesaria.O al menos yo lo intento, el problema es que los programas avanzan independientemente de lo que tu quieras hacer con tu consumismo informático y lleva un día en que si quieres probar algo que no existía dos años atrás no puedes porque directamente el mínimo exigido para funcionar está muy por arriba de donde tu te quedaste. Digikam, GIMP, etc.. hace ya tiempo que habían dejado de ser actualizables. Los repositorios oficiales de openSuse 11.4 fueron cancelados hace tiempo, aunque gracias a repositorios independientes y compilando por mi cuenta puede ir soluciando cuestiones.
A principios de Diciembre para probar ya no recuerdo que cosa, decidí que actualizarías las KDE y a partir de ahí ir actualizando hasta resolver todas las dependencias que surgieran. Todo bien hasta que llegó el momento de reiniciar y llegaron los problemas llegó el problema. Después del reinicio el sistema no arranca, ni produce pitido alguno, ni era posible acceder al SETUP de la BIOS. Con el polímetro mido la fuente de alimentación, que funcionaba correctamente. Quité todo los módulos de memoria (no pita), desconecté los discos duros (no pita), a la placa base parecía darle lo mismo que hubiera o no memoria y discos duros. Placa base muerta. Sospecho que el problema podría venir por la pila botón de la placa. Este ordenador, salvo que ocurra algo raro no se apaga nunca y prácticamente se reinicia una vez cada tres meses. Está montado sobre un SAI de 600W con lo que ni los cortes de luz lo apagan. Tengo el pálpito indemostrable de que la pila estaba agotada y fué responsable de que en el momento del reinicio se dañase el arranque de la BIOS. Probé a cambiar la pila, a resetear con hardware con los jumper de la placa pero con nulo éxito.
Nueva placa…, y claro, casi todo los adosados a ella. La nueva motherboard solo trae conexiones SATA, a mis discos ATA/IDE les dió la risa. La memoria RAM ya no es DDR2 con muesca en el pin 32 (es un decir) sino DDR3 con muesca en el pin 34. El socket del procesador también cambia. En fin, pude conservar la propia torre ATX, la fuente de alimentación, gráfica Nvidia y la capturadora. Todo lo demás es nuevo. Afortunadamente los discos duros están como nuevos y funcionan perfectamente por lo que en las últimas semanas ha tocado recuperar configuraciones y archivos al nuevo sistema y reconfigurar todo.

Ahora este servidor web de Cuaderno de campo corre un openSuse 13.2 a 64bits con ATHLON de cuatro núcleos a 4.3Ghz, 8Gb RAM, la misma Nvida de antes (GT630) y tres discos duros (2 SATA y IDE+Adaptador) que suman unos 2,3 Tb, mas su correspondiente DVD, lector de tarjetas, tarjeta TV de ocho canales para las webcams, USB 3.0, etc…

Lo nuevo en openSuse 13.2

Obviamente si vienes de openSuse 11.4 los cambios en el sistema son poca cosa pero algunos si que me han pillado por sorpresa.
Por ejemplo la distribución por defecto de las particiones de instalación del sistema han cambiado bastante. Ahora / se instala por defecto separado de /home (algo que ya hacíamos muchos antes de forma manual) y se pasa del sistema Ext2 ó Ext3 a BtrFS para root y XFS para /home

Xorg.conf también ha cambiado. De hecho es que ahora mismo ignoro completamente donde está mi viejo /etc/X11/xorg.conf donde se definía el entorno gráfico y periféricos del ordenador. Pero mira (y esto también es una novedad, y de las buenas) el reconocimiento de gráficos y auto-configuración ha funcionado de perlas. Ha reconocido tarjeta integrada y PCI-Express NVIDIA, 2 Monitores LCD con Twinview tan bien que no se ni donde está el archivo de configuración, ale!! a-lo-windows!! :)
Eso sí, tuve que instalar los drivers propietarios de NVIDIA porque los drivers libres de Nvidia-Nouveau no han cambiado, igual que antes siguen fallando.

El sorpresón de los buenos a sido comprobar que la capturadora TV de 8 canales de EBay que usaban en mis anteriores 32 bits sigue funcionando en 64bits. La daba casi seguro por muerta ya entonces el módulo BTTV del Kernel estaba muy obsoleto y abandonado, con lo cual las posibilidades de que siguiese vivo eran mínimas. Pero ahí sigue, vivo y funcionando igual de bien. Otra cuestión es MOTION, el programa de detección de movimientos, que también está abandonado desde 2011 y que no soy capaz de compilar con soporte FFMPEG por lo que ahora las cámaras ahora no graban vídeo, solo foto. Tendré que investigar más.

Ha cambiado también la ubicación donde se montan los dispositivos. Desaparece el /media/xxxxx a donde iba el pendrive/dvd y ahora se monta todo en /var/run/media/xxxx. Parece una tontería pero estos cambios en la ubicación de archivos comunes en el proyecto openSuse personalmente me crispan los nervios. No es /usr/local/bin sino /usr/bin, no es /usr/share sino /opt/kde. Si el programa viene de Debian probablemente se instale en /usr/share/, los de Google en /opt/google y los de Fedora en /usr/local/share. Ahora probablemente haya vuelto a cambiar. Conviene tenerlo en cuenta especialmente cuando se instalan librerías procedentes de otros sistemas ó “genéricas” y con las que acabas teniendo el disco duro con las librerías de Python repartidas como si las hubieses lanzado sembrando alfalfa.

He observado también cambios en archivos de sistema como syslog, la integración de UDEV y otros, pero que apenas he tenido tiempo de probar.

A tortas con KDE4

Ahora que para susto el primer inicio del KDE4. La configuración estética por defecto (nunca mejor traído lo de “defecto”) deja mucho que desear. OpenSuse necesita contratar algún director de arte de manera urgente, feo de cojones.
Ojo, no digo que openSuse/KDE4 sea en sí mismo feo sino el primer arranque, lo que uno se encuentra si deja al instalador solo trabajando 2 horas. Por suerte openSuse/KDE4 es suficientemente flexible como poder arreglarlo sin mucha dificultad en profundidad y a muchos niveles (espantoso color de las sombras de ventana, fuentes muy pequeñas, distribución del escritorio sosa y fea, fondo de escritorio pa-matar-a-alguien, etc…). Lamenté en su día dejar KDE3 y pasar a KDE4 y conforme avanza su desarrollo no termino de abandonar esa idea. KDE4 da sensación frágil e inestable. Ese follón escritorios virtuales llamado actividades soy incapaz de entenderlo y verle utilidad. Los widgets fallan si falla el escritorio y viceversa, ni te cuento como se te ocurra mover widgets entre dos monitores o la cantidad de veces que he tenido que escribir Cartagena en el Widget del clima, el panel de control de KDE4 (systemsettings) tiene organizadas las herramientas de una manera que no consigo memorizar o comprender por más años que pasen. En general el aspecto gráfico y ergonómico de KDE4 es muy mejorable, pero se salva porque sigue siendo el mejor (al menos de los que yo he probado: Gnome, XFCE, LXDE, FVWM, Windowmaker, IceWM )

Kwin (gestor de ventanas) a variado poco (afortunadamente) unicamente para integrar mejor los efectos con el sistema y hacerlos más estables. Funcionan realmente bien sin hacer nada.

Por fín ha exterminado aquel engendro del demonio que era Stigri/Nepomuk. Un proyecto muy ambicioso de búsqueda semántica en el escritorio pero que realmente convertía KDE4 en una puñetera locura de fallos, preguntas, molestias constantes al usuario y sobre todo un consumo de recursos bestial.
Lo viene a sustituir Baloo, que pretende los mismo pero con una configuración simplificada a un simple ¿Activar/Desactivar Baloo?.
Bueno, ni lo uso ni me usa, no me puedo quejar.

Bluetooth funciona perfectamente tal y como se instala. Conecta el teléfono con el PC y podemos enviar/recibir archivos con un click ó escuchar la música del teléfono por los altavoces del PC. Sin tocar ningún HCITOOL, Rfcomm ni configuración ninguna.

Cosas que hacer inmediatamente después de instalar openSuse 13.2

Instalar los repositorios de Packman (http://packman.inode.at/suse/openSUSE_13.2/Extra/). De los fundamentales donde encontraremos casi de todo.

Y Kaffeine sigue existiendo. Sip. Increíble pero cierto: el reproductor por defecto de KDE4 después de una instalación standard del sistema no es capaz de reproducir un MP4 ni un AVI/Divx sin emitir error con los codecs. Así es que lo primero es desinstalar Kaffeine e instalar un reproductor serio de vídeo sin florituras, MPLAYER, es perfecto. Lo abre todo sin pestañear. Basta definirlo como reproductor por defecto y listo. Solo vídeo.

Tres/cuartos pasa con el visor de imagen, no es normal que para ver un triste JPG haga doble click y se abra por defecto Gwenview (un navegador de álbumes multimedia), ó peor Showfoto/Gimp (editores) que se llevan 6-7 segundos en arrancar cuando lo que quiero en un 99% de los casos es simplemente ver la foto en grande.
Antés usaba GQview un visor para Gnome muy rápido y potente. Ahora me he pasado a Viewnoir, prácticamente igual. Muy rápido, abre cualquier formato de imagen y puedes configurarlo para que muestre únicamente la imagen, sin interfaz. La rueda del ratón y las teclas habituales permiten desplazarse por el resto de imágenes del directorio en que te encuentras, hacer zoom, rotar, etc…

Miniaturas de vídeos. Para mi gusto es fundamental que el icono de un vídeo permita identificar su contenido sin siquiera reproducirlo. Increíblemente KDE4 no instala ningún thumbnailer para vídeos a pesar de que hay dos que funcionan perfectamente y están en los repositorios habituales Mplayerthumbs y Ffmpeg-thumbnailer. En mi caso prefiero instalar una versión embellecida del primero que ya os enseñé por aquí hace la tira de tiempo.

Instalar SPOTIFY para hacer todo lo anterior con música es ahora mucho más fácil que antes que había que andar trampeando con un DEB de Debian para instalarlo, ahora se instala directamente desde los repositorios y YAST sin problemas.

Common disinformation people tends to believe in is that Linux Audio is in bad shape. Actually it’s not. They are right ALSA is getting bit rusty and it’s not top of the notch but list of supported sound cards is long. There have been speak about next generation audio API for Linux but nothing is really happening (I’m happy if you prove me wrong!). Last year I had task to evaluate different Linux audio libraries for playing audio and recording. So these articles try to make some light to my journey and what did I found. inpatient can go to Github  https://github.com/illuusio/linux-audio-example/tree/master/portaudio. There is other library examples also but only Portaudio is currently updated to my last version. I wrote same very simple application to test every audio library. I’ll upgrade rest of the examples and add also Xiph libao and GStreamer.

Application

Like I said example applications are very simple. With Every library I tried to write playback and record example. If you can use blocking API interface there is blocking example also. In these Examples I use sndfile because API is super easy to use and I could test with WAV. So no troubles big bobbles approach.

Code

I won’t be posting code here it can be found on Github repository. I tried to be super clear as they are examples and added comments as needed but if you don’t get glue fault is all mine.

Portaudio

Supported outputs: Alsa, Oss, Jack, Mac OS X CoreAudio and Many Windows Audio API’s

Why do want to use something else than ALSA? If you need to support other platforms than Linux you get idea of cross platform API for audio. Portaudio is hidden gem of Linux audio libraries. It’s stable as can get. Portaudio has blocking and callback support. It has Float 32-bit Int 32-, 16- and 8-bit input/output. I tries to be very high end in every corner. Also licensing is very liberal.  For a while It’s has seen slowing development  because main developers have something else to do in life.

For me biggest no-no for me was lack of Pulseaudio support (I go so upset that I wrote Pulseaudio  hostApi for Portaudio but that is worth of another blog post). Portaudio supports Windows, Linux and Mac OS X so it’s good choice if you need same quality audio in every platform.

Biggest minus in Portaudio is there ain’t much applications using it. There is some highlights like Mixxx and Audacity. Rest of the list can be found here. Why it’s not more popular I can’t say because it’s easy to use.

Summary: Simple but powerful API for I/O which I can recommend. So go and see examples if it’s for you and documentation from official pages. Next time we get on Pulseaudio.