Minhas configurações de áudio

ALSA

~/.asoundrc

pcm.usb
{
type hw
card U0x46d0x81b
}

pcm.!default
{
type asym
playback.pcm
{
type plug
slave.pcm “dmix”
}
capture.pcm
{
type plug
slave.pcm “usb”
}
}

pcm.hda-intel
{
type hw
card 0
}

ctl.hda-intel
{
type hw
card 0
}

/etc/modprobe.d/alsa-base.conf

options snd-usb-audio index=0
options snd-hda-intel model=dell-headset-dock

PulseAudio

Instalar: paprefs, pulseaudio-module-jack, pasystray, pavucontrol

/etc/pulse/default.pa

#!/usr/bin/pulseaudio -nF # # This file is part of PulseAudio. # # PulseAudio is free software; you can redistribute it and/or modify it # under the terms of the GNU Lesser General Public License as published by # the Free Software Foundation; either version 2 of the License, or # (at your option) any later version. # # PulseAudio is distributed in the hope that it will be useful, but # WITHOUT ANY WARRANTY; without even the implied warranty of # MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU # General Public License for more details. # # You should have received a copy of the GNU Lesser General Public License # along with PulseAudio; if not, see . # This startup script is used only if PulseAudio is started per-user # (i.e. not in system mode) .fail ### Automatically restore the volume of streams and devices load-module module-device-restore load-module module-stream-restore load-module module-card-restore ### Automatically augment property information from .desktop files ### stored in /usr/share/application load-module module-augment-properties ### Should be after module-*-restore but before module-*-detect load-module module-switch-on-port-available ### Load audio drivers statically ### (it’s probably better to not load these drivers manually, but instead ### use module-udev-detect — see below — for doing this automatically) #load-module module-alsa-sink #load-module module-alsa-source device=hw:1,0 #load-module module-oss device=”/dev/dsp” sink_name=output source_name=input #load-module module-oss-mmap device=”/dev/dsp” sink_name=output source_name=input #load-module module-null-sink #load-module module-pipe-sink ### Automatically load driver modules depending on the hardware available .ifexists module-udev-detect.so load-module module-udev-detect .else ### Use the static hardware detection module (for systems that lack udev support) load-module module-detect .endif ### Automatically connect sink and source if JACK server is present .ifexists module-jackdbus-detect.so .nofail load-module module-jackdbus-detect channels=2 connect=0 .fail .endif ### Automatically load driver modules for Bluetooth hardware .ifexists module-bluetooth-policy.so load-module module-bluetooth-policy .endif .ifexists module-bluetooth-discover.so load-module module-bluetooth-discover .endif ### Load several protocols .ifexists module-esound-protocol-unix.so load-module module-esound-protocol-unix .endif load-module module-native-protocol-unix ### Network access (may be configured with paprefs, so leave this commented ### here if you plan to use paprefs) #load-module module-esound-protocol-tcp #load-module module-native-protocol-tcp #load-module module-zeroconf-publish ### Load the RTP receiver module (also configured via paprefs, see above) #load-module module-rtp-recv ### Load the RTP sender module (also configured via paprefs, see above) #load-module module-null-sink sink_name=rtp format=s16be channels=2 rate=44100 sink_properties=”device.description=’RTP Multicast Sink'” #load-module module-rtp-send source=rtp.monitor ### Load additional modules from GSettings. This can be configured with the paprefs tool. ### Please keep in mind that the modules configured by paprefs might conflict with manually ### loaded modules. .ifexists module-gsettings.so .nofail load-module module-gsettings .fail .endif ### Automatically restore the default sink/source when changed by the user ### during runtime ### NOTE: This should be loaded as early as possible so that subsequent modules ### that look up the default sink/source get the right value load-module module-default-device-restore ### Make sure we always have a sink around, even if it is a null sink. load-module module-always-sink ### Honour intended role device property load-module module-intended-roles ### Automatically suspend sinks/sources that become idle for too long load-module module-suspend-on-idle ### If autoexit on idle is enabled we want to make sure we only quit ### when no local session needs us anymore. .ifexists module-console-kit.so load-module module-console-kit .endif .ifexists module-systemd-login.so load-module module-systemd-login .endif ### Enable positioned event sounds load-module module-position-event-sounds ### Cork music/video streams when a phone stream is active load-module module-role-cork ### Modules to allow autoloading of filters (such as echo cancellation) ### on demand. module-filter-heuristics tries to determine what filters ### make sense, and module-filter-apply does the heavy-lifting of ### loading modules and rerouting streams. load-module module-filter-heuristics load-module module-filter-apply ### Make some devices default #set-default-sink output #set-default-source input

Jack

o que é som?

A wikipédia afirma categoricamente: “Som é a propagação de uma frente de compressão mecânica ou onda mecânica; é uma onda longitudinal, que se propaga de forma circuncêntrica, apenas em meios materiais (que têm massa e elasticidade), como os sólidos, líquidos ou gasosos.” Embora seja uma definição correta, ela reduz drasticamente o fenômeno sonoro, cuja complexidade não permite que seja analisado apenas do ponto de vista físico. O som é, sim, isto. Mas não apenas.

Há um trecho conhecido do romance Contraponto, de Aldous Huxley, que descreve de maneira precisa todo o percurso do som, desde o momento em que as ondas são geradas mecanicamente por um emissor até a sua metamorfose em informação estética depois de atravessar salas e passar por todo o sistema auditivo do receptor:

“O sopro de Pongileoni e a esfregação dos violinistas anônimos tinham sacudido o ar do grande hall, tinham posto em vibração os vidros das janelas que davam para ele; e estas por sua vez tinham sacudido o ar do apartamento de Lorde Edward, do lado mais afastado. O ar posto em vibração havia sacudido a membrana tympani de Lorde Edward; a cadeia de ossos – marterlo, bigorna, estribo – tinha sido posta em movimento e fora agitar a membrana da janela oval, criando uma tempestade infinitesimal no fluido do labirinto. Os filamentos terminais do nervo auditivo estremeceram como algas num mar bravo; um grande número de milagres obscuros se efetuaram em seu cérebro, e Lorde Edward murmurou extaticamente: – Bach!” (HUXLEY, 1971)

 

Para que haja som é preciso, antes de qualquer coisa, que o ar vibre, seja sacudido (o ar ou outro meio elástico, como janelas de vidro, paredes, água, o estribo, o fluido do labirinto…). É preciso que esta vibração seja transmitida até chegar aos ouvidos de alguém. E, enfim, é preciso que, dentro do sistema auditivo, ela passe por inúmeras etapas e transformações até que seja convertida (de maneira ainda não completamente compreendida pela psicoacústica) num conjunto detalhado de informações sobre as ondas que ali chegaram.

Se não há vibração, não há som. Se há vibração, mas esta não é transformada em sensação auditiva – por exemplo, se ela acontece numa frequência mais baixa ou mais alta do que o ouvido pode perceber – também não há som. Não é possível, portanto, definir o que é o som apenas pela sua existência física. Devemos considerar que ele também possui existência perceptiva. E aquilo que é percebido nem sempre tem correspondência exata com o fenômeno objetivo. Por exemplo: frequência é uma propriedade objetiva do som e tem um correspondente perceptivo, o pitch, que costumamos traduzir como altura. A frequência pode ser medida num osciloscópio e definida com exatidão. A altura não.  A mudança de intensidade do som, por exemplo, afeta a percepção de altura, de forma que uma mesma frequência ouvida com intensidades diferentes pode ser percebida com alturas diferentes. O mesmo acontece com a relação amplitude (objetiva) e intensidade (percebida). E mais: as vibrações sonoras não são percebidas apenas pelo ouvido, mas também pelo tato. Assim, nossos mecanismos de percepção e a sua interação com os fenômenos físicos são uma parte complexa e essencial do estudo do próprio som.

Há, ainda, uma série de fatores culturais e sociais que influenciam na forma de se perceber sons. A intensidade do ruído de um tiro não é percebida da mesma maneira por um morador de uma metrópole barulhenta e por um inuíte que vive no silêncio do Alasca. O tipo de atenção que um cego dá para os sons à sua volta é diferente do de alguém que enxerga.

E, por fim, existem inúmeras questões filosóficas que atravessam o universo sonoro. Um dos filósofos mais reconhecidos que tratam sistematicamente de sons em seus escritos é Don Ihde.

O som, portanto, é um fenômeno complexo que pode ser estudado sob a perspectiva de diversas disciplinas: acústica, psicoacústica, ciências cognitivas, ciências humanas, filosofia. Defini-lo, analisá-lo, esgotá-lo, não é tarefa fácil. Nas próximas postagens, vamos adentrar em alguns dos tópicos que foram mencionados aqui.

REFERÊNCIAS

HUXLEY, Aldous. Contraponto. São Paulo: Abril Cultural, 1971. 445 p. (Os imortais da literatura universal; 25)

PIRES, ISABEL. Esses sons que nos seduzem. INTERACT. 2016. Disponível em: < http://interact.com.pt/22/esses-sons-que-nos-seduzem/ > Acessado em: 9 mar 2019.

conceitos básicos #1

GNU/LINUX

Por uma questão de conveniência ou desconhecimento, muitas vezes usamos a palavra “Linux” como se ela se referisse a um único e completo sistema operacional. Mas na verdade não é único porque existem diversas distribuições (falaremos delas mais tarde) e não é completo porque “Linux” é apenas o kernel, o núcleo do sistema. Mas para ser chamado de sistema operacional não basta haver o núcleo, é preciso que existam programas que funcionem a partir desse núcleo – e a maioria dos programas que rodamos pertencem ao projeto GNU.  O projeto GNU e o kernel Linux foram desenvolvidos por pessoas diferentes com objetivos diferentes: enquanto o primeiro foi concebido por Richard Stallman e sua equipe, o segundo foi feito por Linus Torvalds. Por isso é de bom tom, ao nomear o sistema, dar o devido crédito às duas iniciativas, e fazer como os mais sistemáticos que não dizem apenas “Linux”, mas “GNU/Linux”.

DISTRIBUIÇÕES

Existem diversos aplicativos, interfaces gráficas, compiladores, etc. que podem ser colocados para funcionar junto com um kernel Linux, gerando assim diversas possibilidades de sistema operacional. Cada uma dessas possibilidades é uma distribuição. Existem centenas de distribuições GNU/Linux, cada uma voltada para determinadas funções e categorias de usuários. Algumas das mais conhecidas são Debian, Ubuntu, Fedora, Slackware, RedHat, Mandriva… Certas distribuições são baseadas em outras e, por isso, possuem muitos aspectos em comum (Ubuntu, por exemplo, é baseada em Debian). Algumas apresentam apenas diferenças cosméticas em relação às outras, não passando de poluição. Mas outras possuem características que as tornam únicas.

Escolher uma distribuição adequada às suas necessidades e  nível de conhecimento talvez seja o passado decisivo para quem quer migrar de outro sistema para o GNU/Linux. Um iniciante que acabe se deparando, por azar, com uma distribuição completamente distante daquilo que precisa pode acabar tendo uma impressão muito distorcida do que é Linux e nunca mais voltar a tentar usá-lo.

AMBIENTE GRÁFICO

Quem vê um sistema operacional pela primeira vez, costuma associar o sistema em si com o ambiente gráfico. No Windows e no Mac isso pode fazer sentido porque eles possuem um único ambiente gráfico por versão, que não é muito customizável e nem substituível. Já no GNU/Linux existem diversos ambientes gráficos que podem ser trocados e personalizados. É possível até ter mais de um instalados ao mesmo tempo no computador. Mais uma vez: existem ambientes voltados pra diversos tipos de usuário – alguns tentam manter semelhanças com os ambientes de sistemas mais populares, alguns são fáceis mas estranhos no começo, alguns são um pouco mais complicados por exigirem muitas configurações manuais e é possível não ter ambiente gráfico nenhum (para os usuários hardcore). Alguns dos ambientes mais conhecidos são: Gnome, Unity, KDE, XFCE, LXDE, MATE, Cinnamon, FluxBox… Cada distribuição vem com um ambiente gráfico por padrão, mas é possível instalar outros. Portanto, não existe uma relação necessária entre distribuição e ambiente gráfico – embora alguns ambientes tenham sido criados especificamente para uma distribuição, como é o caso do Unity, criado especificamente para o Ubuntu, mas que ainda pode ser usado em outras distribuições.

música no linux

A velha pergunta “é possível trabalhar com música usando linux?” não cabe mais. Uma pesquisa rápida na internet mostra que sim e que tem muita gente usando o linux e software livre em geral, tanto para as necessidades mais simples, como ouvir música, até para a produção musical profissional. Uma pergunta mais pertinente seria: “é viável ou vantajoso fazer música usando linux?” Com certeza não é tão simples quanto em sistemas mais comerciais, mas espero terminar este texto com bons argumentos a favor.

Em primeiro lugar é bom pensar nas vantagens do uso de software livre para qualquer fim que seja: segurança, estabilidade, gratuidade, transparência… Recomendo a leitura deste pequeno guia publicado por Fátima Conti no Outras Palavras. Usar software livre é praticar um esforço pela “liberdade de executar os programas sem restrições, a liberdade de conhecer e modificar os programas e a liberdade de redistribuir esses programas na forma original ou modificada entre os amigos e a comunidade.” Não se trata, portanto, só de ter programas de graça (sem precisar de fazer downloads piratas), mas principalmente de reconhecer que a produção digital (do software aos arquivos de imagem, texto, vídeo e som) é produção de conhecimento e que, como tal, deve ser tratada como  patrimônio público e não como mercadoria privada.

O software proprietário é dominado por empresas que nos restringem de todas as maneiras possíveis. Invadem nossa privacidade a fim de aumentar a efetividade da propaganda, limitam os dispositivos que podemos usar (por exemplo, quem não tem smartphone não pode ter whatsapp), tornam produtos obsoletos sem necessidade (obsolescência programada). Enfim, nos tiram toda possibilidade de autonomia no mundo digital. Talvez isso não seja suficientemente grave pra muita gente. Pra mim é.

Tudo isso inclui, claro, os programas de produção e edição de áudio. O Pro Tools, por exemplo, que é a DAW (estação de audio digital) mais utilizado na grande indústria e pelos grandes profissionais, apesar de ter muitas vantagens (desde as facilidades que a interface proporciona que, admito, agilizam muito o trabalho, até certo ganho de qualidade no resultado final que os ouvidos mais refinados alegam) é um software proprietário que limita os usuários em vários aspectos: preço exorbitante, incompatibilidade entre diferentes versões, incompatibilidade com plug-ins (aceita apenas plug-ins exclusivos, que por sua vez também são caros). As outras DAW’s industriais não fogem muito desse padrão: Cubase, Nuendo, Live, etc. 

Em contrapartida, existem DAW’s em código aberto como Ardour, Qtractor, LMMS e muitas outras. Admito que muitas são chatas para trabalhar, mas pelo menos estas três citadas funcionam muito bem e estão em constante atualização, ficando cada vez melhores a cada nova versão. E elas tendem a funcionar melhor à medida que o número de usuários cresce. Embora não tenham as facilidades um Pro tools, não são tão difíceis a ponto de assustar um iniciante em produção musical. E rendem resultados finais bastante dignos. Não sei se é uma boa metáfora, mas para mim o software livre está para o software proprietário como a bicicleta está para o carro: uma te dá autonomia, mas custa certo esforço, o outro te dá conforto, mas custa a liberdade. Eu prefiro a bicicleta.