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>
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
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.
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
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
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
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
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