Hi everybody,
This small email just to say that the new version 1.0 of DidJiX - a live
Linux distribution based on ArchLinux and focused on Mixxx - is available
at http://didjix.blogspot.com <http://didjix.blogspot.fr/>.
Good turn 2013.
Regards, Pascal.
Yesterday I had a small local radio station get in touch with me as they're
looking to switch from Windows to Linux for their streaming server. I'll be
helping them out just as a favour and because it sounds like it could be
fun but I don't really have any experience with the various Linux streaming
solutions so I thought I'd post on here to see if anyone has any tips?
I've not been down to check out their existing setup but I don't think they
want much more than to be able to stream recordings and Skype. I think
Skype lacks JACK support so maybe that will require a bit of messing to get
it to play nicely (if we use a JACK based streaming solution).
Did the OSM podcast guys ever do a write-up/ HOWTO I could read? Any other
good resources for those setting up a small, Linux-based radio station?
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
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
hi fons, hi everyone!
playing with aliki and jconvolver again. i've recorded some sweeps from
a single neumann kh120 loudspeaker into a tetramic. the IRs have been
deconvolved and normalized, and after that their direct part and floor
reflection have been trimmed off.
now when i put those files in jconvolver with a gain of 1 (which is
inserted into a post-fader aux fx bus), the reverb level is way too
high. i see that you always use a gain coefficient of .5 in your
b-format examples - why?
i would like to start with the "correct" reverb level and go from there.
the initial (peak) normalisation was done in ardour. maybe i should have
normalized the initial impulse area to unit energy rather than the
highest peak to unit amplitude, but i'm not quite sure how to accomplish
that. the normalization feature in aliki doesn't seem to do anything, or
i'm misunderstanding something.
below is the config file. ignore the five inputs for now, the level
problem is evident when using just a single input.
any hints would be much appreciated, and yes, as soon as i've listened
through these IRs properly and fixed the config, i'll be happy to share
them with everyone.
best,
jörn
/cd .
#
#
# in out partition maxsize density
# --------------------------------------------------------
/convolver/new 5 4 256 400000 1.0
#
#
# num port name connect to
# -----------------------------------------------
/input/name 1 Input.LL
/input/name 2 Input.L
/input/name 3 Input.M
/input/name 4 Input.R
/input/name 5 Input.RR
#
/output/name 1 Output.W
/output/name 2 Output.X
/output/name 3 Output.Y
/output/name 4 Output.Z
#
#
# in out gain delay offset length chan file
#
-----------------------------------------------------------------------------------
/impulse/read 1 1 1 0 0 0 1 LL.wav
/impulse/read 1 2 1 0 0 0 2 LL.wav
/impulse/read 1 3 1 0 0 0 3 LL.wav
/impulse/read 1 4 1 0 0 0 4 LL.wav
/impulse/read 2 1 1 0 0 0 1 L.wav
/impulse/read 2 2 1 0 0 0 2 L.wav
/impulse/read 2 3 1 0 0 0 3 L.wav
/impulse/read 2 4 1 0 0 0 4 L.wav
/impulse/read 3 1 1 0 0 0 1 M.wav
/impulse/read 3 2 1 0 0 0 2 M.wav
/impulse/read 3 3 1 0 0 0 3 M.wav
/impulse/read 3 4 1 0 0 0 4 M.wav
/impulse/read 4 1 1 0 0 0 1 R.wav
/impulse/read 4 2 1 0 0 0 2 R.wav
/impulse/read 4 3 1 0 0 0 3 R.wav
/impulse/read 4 4 1 0 0 0 4 R.wav
/impulse/read 5 1 1 0 0 0 1 RR.wav
/impulse/read 5 2 1 0 0 0 2 RR.wav
/impulse/read 5 3 1 0 0 0 3 RR.wav
/impulse/read 5 4 1 0 0 0 4 RR.wav
--
Jörn Nettingsmeier
Lortzingstr. 11, 45128 Essen, Tel. +49 177 7937487
Meister für Veranstaltungstechnik (Bühne/Studio)
Tonmeister VDT
http://stackingdwarves.net
Hi,
tl;dr: is there a command line tool where I can give several midi files, and a jack input port for each, and it plays them back in sync?
Preferably with a clean exit when the last file is finished.
long version what I tried so far:
I hacked together a quick python script around jack-smf-player a while ago but that was sub-optimal since I either get a synched start (by using jack transport for all players and sleeping a bit before playback) but no automatic exit, since jack-smf-player can't do auto-exit with jack transport. So I had to loop over all open PIDs and kill them which produced xruns and jack hiccups, it also took long.
Or I got a clean exit, using the play-and-exit mode, but then I got no sync since each player just starts when it is ready. Even syncing them up with python did not help because it is music and every ms delay counts.
Does such an sequencer without a GUI exist?
greetings,
Nils
http://www.nilsgey.de