Sonido 4.1 y Más

Buenas despues de pelear algo, navegando llegue a esta pagina http://www.milmazz.com/archivos/2006/09/20/audigy-se-en-etch-amd64/

donde el amigo tambien dios sus tumbos pero consiguio e interpreto muy bien la informacion. al igual que el debian me detectaba la tarjeta una sound blaster audigy ls (chip snd-ca0106) primero no habia nada de audio, revise el alsamixer y estaba todo off, los active y solo sonaba los frontales y el bajo, faltaban los traseros para lo cual el amigo dio exacto en el clavo.


cito el articulo

Hace días me hice con una tarjeta de sonido Audigy SE de la marca Creative y la verdad tuve que dar bastante golpes para dar con la configuración correcta. ¿Cómo lo logré? Muy fácil: Googleando .

Resulta que el sistema (Debian, of course) reconoce bien el dispositivo y carga de manera perfecta los módulos necesarios; de hecho el alsa-mixer me mostraba todos los canales de la tarjeta pero el único que parecía funcionar era el Analog Front y los otros parecían estar muertos. Casi daño el mouse de tando hacer clicks y darle hacia arriba y hacia abajo . No podía creer que no funcionara!.

Googleando llegué a la página de la gente de Alsa y me encontré una manera de configurar los drivers. Ahi confirmé que el sistema me estaba cargando el módulo correcto, el snd-ca0106. Entonces, después de ver la pequeña lista de instrucciones, no voy a decir que me espanté y maldije a Creative, no, no lo hice, en ése momento miré al cielo y pregunté: ¡¿Acaso no existe una manera más fácil de lograr que suenen la benditas cornetas?! y la respuesta a mi pregunta vino del wiki de Gentoo, ¿qué cosas no? imagínense todo lo que googleé; bueno específicamente de la sección que dice VIA Envy24HT (ice1724) chip. Ahora se preguntarán.. ¿VIA? éste tipo está loco…. pues sí, VIA. ¿Y qué fué lo que hice? Abrí una terminal e hice lo siguiente:

$ gedit .asoundrc

Luego lo que hice fué copiar el contenido del segundo .asoundrc y pegarlo al mío, luego guardar los cambios y voilá, sistema de sonido 5.1 andando . Se preguntarán ¿Cómo hizo éste loco para saber que ese .asoundrc funciona con la Audigy SE?, bueno, con el proceso estándar, prueba error. Copiando y pegando cada uno de los ficheros.

Ahora que el sistema suena perfectamente bien me ha surgido una nueva interrogante, debido a que para poder graduar el volumen del sistema tengo que graduar los tres controles, y la pregunta es: ¿Habrá alguna forma de graduar el volumen para los tres controles al mismo tiempo? Que lo disfruten…

tomado de http://www.milmazz.com/archivos/2006/09/20/audigy-se-en-etch-amd64/

12 preguntas de Joel sobre la calidad de tu Proyecto de Software

The Joel Test

1. Do you use source control? (Utilizas control de versiones - a.k.a subversion, CVS)
2. Can you make a build in one step? (Puedes construir/compilar en un solo paso)
3. Do you make daily builds? (Haces builds diarios?)
4. Do you have a bug database? (Tienes una base de datos de bugs? e.g. Bugzilla)
5. Do you fix bugs before writing new code? (Reparas los bugs antes de escribir codigo nuevo)
6. Do you have an up-to-date schedule? (Tu proyecto esta al dia con lo planeado?)
7. Do you have a spec? (Tienes una especificacion formal?)
8. Do programmers have quiet working conditions? (Tus programadores tienen un lugar tranquilo y silencioso donde trabajan)
9. Do you use the best tools money can buy? (utilizas las mejores herramientas que el dinero puede comprar?)
10. Do you have testers? (Tienes Testers? - Es super recomendable tener alguien experto en QA [quality assurance, que sepa escribir Unit Tests, Regression Tests, Stress Tests, etc])
11. Do new candidates write code during their interview? (Los nuevos candidatos a programar en tu proyecto escriben codigo durante su entrevista de empleo?)
12. Do you do hallway usability testing? (Haces prueba de usabilidad de pasillo? Es decir agarrar cualquier persona no relacionada al proyecto al azar que vaya pasando y forzarla a utilizar tu sistema)

Por cada pregunta que respondes si, sumate un punto. Por cada no, suma cero.
Si tienes 12, perfecto
Si tienes 11, aceptable
Menos de 10, estas en problemas.

Mas detalles sobre cada pregunta
http://www.joelonsoftware.com/articles/fog0000000043.html

Los 10 Mandamientos para Realizar un Proyecto de Software

Los diez mandamientos para realizar un proyecto de forma feliz y eficiente:

1. No propondrás objetivos ambiciosos y vagos

Nada es peor que un proyecto sin fin al que se le invierten semanas y semanas pero nunca se avanza. Muchas veces es porque al cliente se le prometieron las perlas de la virgen, es fácil caer en la irrealidad cuando uno se entusiasma haciendo una presentación en OpenOffice. Manten unos objetivos reales, útiles y bien definidos.

2. No manejarás equipos innecesariamente grandes

Los equipos grandes son más dificles de manejar y mantener motivados. Asegúrate de no tener equipos donde hay miembros de más.

3. Coordinaras gente de tiempo completo

Algunos proyectos no-urgentes son pequeños o su evolución se proyecta tan larga que los jefes deciden ponerlos en "background" para irlos realizando "cuando haya tiempo". Evite hacer esto: nadie toma en serio ni se interesa en un proyecto de tiempos libres.

4. Armarás equipos para evaluaciones periódicas

Los paneles de evaluación no sólo señalan carencias y amenazas al proyecto sino que le dan seguimiento a cada uno de estos aspectos.

5. No quemarás a tu equipo

Generalmente cuando se inicia un proyecto los miembros llegan frescos y descansados pues han pasado algunos días desde la última entrega. Esto hace que los proyectos inicien a un gran ritmo y luego de un mes desciendan a su ritmo de producción normal.

No obstante muchos jefes creen que este descenso es un síntoma de ineficiencia y presionan mas al equipo agotándolo física y mentalmente en un par de meses. Cuado el equipo está quemado su eficiencia está cerca del cero.

6. Tendrás ya investigada la asistencia externa

Hay algunas cosas que el equipo puede hacer pero necesitaría investigar y probar, lo que consuem tiempo. Busca ayuda externa para esos aspectos y le quitarás algo de trabajo al equipo.

7. Reconocerás el ritmo de tu equipo

El agotamiento mental y físico es un factor que muchos no consideran al momento de calendarizar un proyecto. Hay equipos que trabajan bien ocho horas al día durante cinco semanas pero luego necesitan días de descanso. Otros equipos pueden ser eficientes de manera constante trabajando seis horas al día. Descubre el ritmo de trabajo de tu equipo, los ciclos trabajo-descanso son muy importantes en los equipos de trabajo.

8. Usarás herramientas de manejo de proyectos

No sé cuantas veces he recomendado a los líderes de proyecto que instalen y aprenda a usar PHProjekt, incluso se los he instalado pero por alguna razón en México las herramientas de control de proyectos se consideran inútiles o superfluas. Tener concentrados la documentación, los contactos, los TO-DO y los calendarios en un sólo programa es fundamental.

9. Reconocerás el éxito

Si alguien hizo algo bien reconocelo públicamente. Si los miembros del equipo trabajan bien se les puede premiar enviandolos a casa temprano o dandoles un lunes libre.

10. No tolerarás trabajo hecho "al aventón"

No seas indulgente y manten un buen nivel de calidad.

Tomado de http://www.mononeurona.org/index.php?idnew=759