Linux-audio-user February 2013

linux-audio-user@lists.linuxaudio.org

142 participants
178 discussions

by Daniel Worth

fter much work and the help of a great mixing engineer, Mr. Rich Wielgosz<http://richwielgosz.com/>, I've completed, and released the first track to my Album, "Apathetic". It's called "Gun Slinger" and was inspired by listening to popular rock tunes about the wild west and thinking, "most of these guys grew up on the coast and have never, ever, ridden a horse, I on the other hand have actually worked as a wrangler!" So, I sat down and hammered out a song over the top of a riff I'd been messing with. The track ended up with a few guitar parts with a touch of mandolin, some tasty slide guitar, and a little tambourine. You can hear and purchase the tune at http://danielworth.bandcamp.com with more options to come. I'm using the money raised from my songs to help fund my "500 Year Farm<http://pipemanmusic.blogspot.com/2013/02/500-year-farm.html> ". This song is recorded and mixed 100% on Linux using, Ardour2, Mixbus and LinuxDSP plugins. It's also being released CCBYSANC. Thanks to everyone for supporting me. -- Daniel Worth <http://danielworth.bandcamp.com>

13 years

[LAU] Jackd ... add device

by Bob van der Poel

Okay, I've got jackd working with my usb audio device and audacity. And, yes, recording works very nicely. Thanks for the help! Now, I want to plug in a usb microphone in addition to the other device already running. So, the question becomes: How do I add a 2nd device to an already running jackd? Or do I need to tell jack when it starts to use 2 devices (again, how?). And, will audacity catch on to this? -- **** Listen to my CD at http://www.mellowood.ca/music/cedars **** Bob van der Poel ** Wynndel, British Columbia, CANADA ** EMAIL: bob(a)mellowood.ca WWW: http://www.mellowood.ca

13 years

[LAU] Mudita24 release 1.1.0

by Tim E. Real

Hello. I finally rolled an archive. This is for the benefit of ye kind packagers out there, and everyone, as I notice the version in Ubuntu for example is still the old version which has broken alsactrl profile support - can't save/load profiles. There has been no changes to code for a while, except that I just now removed the SVN version from the About page. However, the most recent major changes from a while ago are important, such as profile fixes, and are not in the last release, so it is important to get this release out there. Mudita24 is a modification of the Linux alsa-tools' envy24control(1): an application controlling the digital mixer, channel gains and other hardware settings for sound cards based on the VIA Ice1712 chipset aka Envy24. Project home page: http://code.google.com/p/mudita24/ Download source code: http://mudita24.googlecode.com/files/mudita24-1.1.0.tar.gz Let us know if any problems. Thanks. Tim. The Mudita24 project. The MusE project.

13 years

[LAU] Audio streaming work flow

by Len Ovens

I have been fooling around with an Internet radio station setup. Just to see what kinds of trouble might show up. There seem to be two sides to broadcasting software. Audio and admin. I don't know if I can really cover the admin side well, both rivendell and airtime seem to work for that. For that matter I have heard of some people using windows apps for doing admin and playlist creation while using Linux for audio streaming. I will cover the audio part for now. Audio is divided into two parts, studio and server. A number of people use a streaming service rather than their own server because most people have a dynamic IP and so name service is problematic. It is often cheaper to use a streaming service. In any case the server side install seems to be trivial, install icecast2, configure and run. I found that part easy. I set it up on a 10 year old 1.2Ghz Celeron box with Ubuntu Server installed. Quick and easy, basically set up the passwords, enable and start the init.d/icecast2 script. Done. The studio side takes a bit more. I will note here that the studio side setup also makes a good podcast recorder. I am not so sure about live DJ work as many live DJs consider video a large part of their show. I don't know if they would consider the video part as truly separate or expect to have one application that does it all. The response I have gotten to mixxx is that it is "not ready" for prime time use. My personal experience is that: a) it doesn't like the open nvidia driver (crashed xorg on me). b) it's window is too big for at least one of my screens (netbook). I think the first problem is known and may even be fixed by now. But the second is more troubling. Podcast recording or remote broadcast might well want to be done on a small screen computer like a netbook or notepad. The window is not even shrinkable to screen size with scroll-bars. Though once the user got used to kb shortcuts that might not be an issue. IDJC seems to be much better. It is the recommended studio solution for airtime and interfaces well with jack. That is what I used for my setup and at least one of our users uses it for their internet radio station as well. It is small enough to be used on any screen... well maybe not a smart phone :) It allows the unattended streaming of prerecorded content as well as mixing live audio with that. All audio content (including MP3s, OGGs etc.) are decoded to audio at the rate jack is running and remixed with whatever audio the users wishes to add. It has dedicated jack ports for VOIP or landline audio available. It has jack ports for insert purposes after mixing and before streaming. This allows the use of a compressor or eq or even outboard equipment. This is also the place to get audio out for live use or live broadcast (think transmitter, though I would think it may go through some other stuff before that). So far great. There is an online setup and use guide for IDJC that covers about everything. The last bit is still the roughest. Integration of desktop sounds with jack. The most common use for this is VOIP generally skype, though the problem is the same with almost all of these kinds of apps. The most common thing is doing remote interviews and the most common work around is to route audio outside the computer via pulse and then back in though audio ports. The PA-jack bridge is getting better, but has two limitations at this time. The PA that ships is 2.*, the new one I can find is 3.0 and both of these have the same problem. The first is a bug where jack will not start while PA is streaming. There is a fix, but it is not in any repo yet... there is also a workaround... but that is not easy to set for install. The second problem for those with a sound card with more than two ports, is that PA defaults to as many ports as the physical device has. The more ports PA has to deal with the more CPU it uses... with an ICE1712 based audio device that is 12/10. A default of stereo would be better. I am told the version currently in git has the ability to set the number of channels. I have asked for a default of two, but being able to set the number is second best. It is possible to set the PA-jack bridge not to auto connect and the method of doing so should be documented for this workflow. Using a jack session seems ideal with this workflow. The pa bridge can be connected to the correct ports as they appear. The nice thing about using the pa bridge for these things is that once PA is running it is always there unlike many desktop apps that only show up when they are running and therefore have to be manually connected after they connect to the sound server. Some good open conferencing SW that works with Jack and has OSX win clients would be really nice. The other possibility would be to have a logon or mode that is set up just for this work flow. Jack would start first and run as the default sound server. Pulse would be started after with sink and source modules started from script rather than jack detect. These module do allow setting channels. Other audio work flows might benefit from this kind of setup too. Len is out of breath. -- Len Ovens www.OvenWerks.net

13 years

[LAU] LAC 2013: the Linux Audio Conference - Deadline Extension

by Florian Hollerweger

sorry for >< please >> << Hi all, The Linux Audio Conference submission deadline has been extended! It is now February 17th, 2013 (23:59 HAST). So, if you were considering to submit a paper but couldn't make up your mind yet, here is your chance to become active! Never forget that this conference lives through the people participating in it. FEBRUARY 17th is the new deadline for all submission types: papers, music, installations, workshop proposals. Check out the link below more info: http://lac.linuxaudio.org/2013/participation Please spread this information to anyone who might be interested. If you have any questions, drop us a line at lac(a)linuxaudio.org We are looking forward to seeing you in Graz in May! Thanks and happy last-minute music-and-paper-submissions, the LAC2013 organization team --- LAC 2013: the Linux Audio Conference May 9-12, 2013 @ IEM, Graz/Austria lac(a)linuxaudio.org http://lac.iem.at

13 years

[LAU] slowing down sysex dumps

by Brent Busby

Usually when I want to send a sysex dump to a keyboard, I use the amidi command from the shell, and it works fantastic. However, one of my keyboards is a Siel DK600, which is one of those synthesizers made at the dawn of time (or the dawn of Midi) that just barely knows what sysex is. It sounds beautiful, but Midi is not its high point. Is there anything you can do on Linux to transmit a sysex file more slowly? I'm not sure, but I think it may help if the data wasn't coming in so fast. The DK600 was originally designed to only receive sysex from other products made by the same company, so they may have had an assumption that the transmitter would have a slow CPU. -- + Brent A. Busby + "We've all heard that a million monkeys + Sr. UNIX Systems Admin + banging on a million typewriters will + University of Chicago + eventually reproduce the entire works of + James Franck Institute + Shakespeare. Now, thanks to the Internet, + Materials Research Ctr + we know this is not true." -Robert Wilensky

13 years

[LAU] preparing a vmpk release with bug fixes

by Pedro Lopez-Cabanillas

Hi, I'm preparing a new vmpk release (0.5.1) containing fixes for all the bugs collected so far since the release 0.5.0 last summer. Which is this one alone: http://sourceforge.net/tracker/?func=detail&aid=3599827&group_id=236429&ati… That bug, reported by a FreeBSD user, is already fixed in svn revision #372. If somebody is aware of more bugs, please report them ASAP if you want to see them fixed soon. Regards, Pedro

13 years

[LAU] Sample rate vs. SNR

by Len Ovens

Just looking through TI's ADCs 96k and up. Any on chip audio circuitry (level controls etc.) seems to lower SNR (101 db typ.) which is no surprise. But what I did find interesting is that even 96k and 192k devices seem to optimized for 48k. So the spec of 112db SNR would be true for 48k, but by the time it gets to 96k that is down 3db (noise floor up 3db) and at 192k... not even listed. So 192k is snake oil anyway, I'm not concerned, though I will say the 192k device has better performance at 48K, much smoother frequency response. My question is about the 48k vs. 96k. 96k would allow lower latency and better in band frequency response, but worse noise. Is it worth the extra disk space and cpu load for recording? Or would it be better to record at 48K and use 96K for live use where latency is more important than noise floor? What is the best SNR I am practically going to find from mic to converter? Does it matter if the ADC is 101 db SNR or 112 db SNR? -- Len Ovens www.OvenWerks.net

13 years

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

Linux-audio-user February 2013