21 Jul
2010
21 Jul
'10
2:24 a.m.
Hi all, i'm new to this list.
I'd like to ask some advice about a small multitrack recorder program i
wrote, and have been using for some time. Basically, what it does is to:
- simultaneously capture sound from several consumer-grade soundcards.
- use libsamplerate to stretch the audio streams, re-syncing them to the
one chosen as "master". The stretch ratio is continuously re-calculated
to make the overall frame count of the stretched stream match the
overall frame count of the master.
- write the "corrected" streams plus the "master" stream to parallel
.wav files using libsndfile.
The purpose is the same as the quite famous "El-Cheapo Howto" (
http://quicktoots.linuxaudio.org/toots/el-cheapo ), just with no
soldering involved :-)
Of course, i know the solution is far from perfect, but i use it to
record some friends of mine who play in a blues/punk band, and the
result is not that bad.
Now, the question is: do you think this piece of code can be of any
interest for someone out there?
Do you think i should i publish it on an open source repository ? Or
maybe there's already some other software i'm not aware of, that does
the same thing?
thanks for your patience, please excuse my bad english.
bye
alberto
21 Jul
21 Jul
4:45 a.m.
On 07/21/2010 10:24 AM, rom wrote:
Hi all, i'm new to this list.
I'd like to ask some advice about a small multitrack recorder program i
wrote, and have been using for some time. Basically, what it does is to:
- simultaneously capture sound from several consumer-grade soundcards.
- use libsamplerate to stretch the audio streams, re-syncing them to the
one chosen as "master". The stretch ratio is continuously re-calculated
to make the overall frame count of the stretched stream match the
overall frame count of the master.
- write the "corrected" streams plus the "master" stream to parallel
.wav files using libsndfile.
The purpose is the same as the quite famous "El-Cheapo Howto" (
http://quicktoots.linuxaudio.org/toots/el-cheapo ), just with no
soldering involved :-)
Of course, i know the solution is far from perfect, but i use it to
record some friends of mine who play in a blues/punk band, and the
result is not that bad.
Now, the question is: do you think this piece of code can be of any
interest for someone out there?
Do you think i should i publish it on an open source repository ? Or
maybe there's already some other software i'm not aware of, that does
the same thing?
Absolutely a very useful addition to the toolset. Please do release it.
thanks for your patience, please excuse my bad
english.
bye
alberto
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev(a)lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev
--
Patrick Shirkey
Boost Hardware Ltd
9:45 a.m.
On Wednesday 21 July 2010 04:45:56 Patrick Shirkey wrote:
On 07/21/2010 10:24 AM, rom wrote:
Altough I fear a new round of discussions about clock-syncing coming up.
So please, if you create homepage for the app, state the problem and the fact
that your (nice!) app is not a solution but only a patch to the problem...
Otherwise it might well be that people complain to you about their recordings
sounding less good then with a real multichannel device. And people
complaining here that with apps like yours, the market for multichannel
devices should be dry within weeks...
Have fun and keep on hacking,
Arnold
Hi all, i'm new to this list.
I'd like to ask some advice about a small multitrack recorder program i
wrote, and have been using for some time. Basically, what it does is to:
- simultaneously capture sound from several consumer-grade soundcards.
- use libsamplerate to stretch the audio streams, re-syncing them to the
one chosen as "master". The stretch ratio is continuously re-calculated
to make the overall frame count of the stretched stream match the
overall frame count of the master.
- write the "corrected" streams plus the "master" stream to parallel
.wav files using libsndfile.
The purpose is the same as the quite famous "El-Cheapo Howto" (
http://quicktoots.linuxaudio.org/toots/el-cheapo ), just with no
soldering involved :-)
Of course, i know the solution is far from perfect, but i use it to
record some friends of mine who play in a blues/punk band, and the
result is not that bad.
Now, the question is: do you think this piece of code can be of any
interest for someone out there?
Do you think i should i publish it on an open source repository ? Or
maybe there's already some other software i'm not aware of, that does
the same thing?
Absolutely a very useful addition to the toolset. Please do release it.
11:10 a.m.
On 21/07/10 09:43, Arnold Krille wrote:
So please, if you create homepage for the app, state
the problem and the fact
that your (nice!) app is not a solution but only a patch to the problem...
:-D eheh, yes yes i will... i can even provide a sample recording that
clearly shows the problems of this approach: basically, wiring all the
inputs to the same white noise signal and recording it, shows some
random phase shifts in the mixdown, and the hi freqs just sound bad.
But, when i record from independent mics, actually crappy mics (cheap
electret cartridges), in a room with lots of reverb, and lots of other
problems, that problem seems less evident.
Anyway, now i'll try to use that "alsa_in" tool that Adrian mentioned
before; if it has the same functionality, i'll use that instead. It's
strange, there doesn't seem to be very much information about it...
thanks for pointing out.
Thank you all for the replies
Alberto
22 Jul
22 Jul
12:58 a.m.
On Wed, Jul 21, 2010 at 11:10:07AM +0200, rom wrote:
On 21/07/10 09:43, Arnold Krille wrote:
libsamplerate doesnt like a constantly changing resample coefficient.
that gives quite some noise in the high freqs.
the algorithm in alsa_in obtains a pretty constant coeff after a few
seconds.
the phase offset continues to drift around a bit, but not so much.
So please, if you create homepage for the app,
state the problem and the fact
that your (nice!) app is not a solution but only a patch to the problem...
:-D eheh, yes yes i will... i can even provide a sample recording that
clearly shows the problems of this approach: basically, wiring all the
inputs to the same white noise signal and recording it, shows some
random phase shifts in the mixdown, and the hi freqs just sound bad. But, when i record from independent mics, actually
crappy mics (cheap
electret cartridges), in a room with lots of reverb, and lots of other
problems, that problem seems less evident.
Anyway, now i'll try to use that "alsa_in" tool that Adrian mentioned
before; if it has the same functionality, i'll use that instead. It's
strange, there doesn't seem to be very much information about it...
yeah... alsa_in and alsa_out are pretty much ignored.
thanks for pointing out.
theoretically your tool could achieve better sound quality than alsa_in,
because it doesnt need to be realtime. (it could also do perfect phase
alignment)
so the basic question is, if you are still motivated to continue working
on it, when alsa_in provides you with a realtime capable solution, which
seems to be better than your current implementation.
Thank you all for the replies
Alberto
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev(a)lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev
--
torben Hohn
12:39 p.m.
Hi, last night i finally managed to try jackd+alsa_in and yes, it works!
I used an intermittent beep as a test signal. One thing i've noticed, is
that the master stream is about 450-500 frames early in respect to the
slave streams, while the gap among the 3 slave streams is within 35-40
frames. I'll try to tune things up a bit, and see if it get better.
theoretically your tool could achieve better sound
quality than alsa_in,
because it doesnt need to be realtime. (it could also do perfect phase
alignment)
...hmm, it would require some serious math skills that i don't have :-(
And moreover, i don't think it would make much sense to seek for sound
quality in this context.
It is enough to be able to get something barely decent, using only some
junk computer parts that were laying around in your attic (...the first
version was able to record 4 channels on a Pentium 166 with 24MB of ram
:-D )
so the basic question is, if you are still motivated
to continue working
on it
yeah, actually, i had already stopped working on the core functionality
of my program because it was just good enough for my purpose. Now that i
know of the existence of alsa_in, i don't think i'm going to release a
new project to confuse people even more.
Instead, now i was wondering if it could be useful to move the alsa_in
functionality to a lower level, like an alsa plugin. But from what you
said, i guess the alsa_in algorithm prefers the "always-on" behaviour of
jack (it starts capturing immediately as you start the daemon), instead
of the start-stop behaviour of a typical pure-alsa recording
application. So, i think the answer is no, and alsa_in is simply the
perfect tool i've never heard of before! Aaargh :-D
(...well, i started putting together my program in dec-2008, so maybe it
just wasn't there at the time...)
thanks very much to all of you.
i'll see if i can create some documentation to make that
"alsa_in/alsa_out" tools less ignored, instead of releasing a new
software. Obviously, with all the proper disclaimers stating that it's
not a substitute for a real multitrack ;-)
bye
alberto
1:52 p.m.
On Thu, Jul 22, 2010 at 6:39 AM, rom <aldrop8(a)gmail.com> wrote:
i'll see if i can create some documentation to
make that
"alsa_in/alsa_out" tools less ignored, instead of releasing a new
software. Obviously, with all the proper disclaimers stating that it's
not a substitute for a real multitrack ;-)
well, true, but since it all works seamlessly with any JACK-enabled
multitrack, it basically isn't a substitute, it just is.
21 Jul
21 Jul
9:18 a.m.
On Wed, Jul 21, 2010 at 02:24:09AM +0200, rom wrote:
I'd like to ask some advice about a small
multitrack recorder program i
wrote, and have been using for some time. Basically, what it does is to:
- simultaneously capture sound from several consumer-grade soundcards.
- use libsamplerate to stretch the audio streams, re-syncing them to the
one chosen as "master". The stretch ratio is continuously re-calculated
to make the overall frame count of the stretched stream match the
overall frame count of the master.
- write the "corrected" streams plus the "master" stream to parallel
.wav files using libsndfile.
You basically reinvented jackd with additional alsa_in and jack_capture
or whatever recording tool (ardour?) a user intends to use.
Just a quick walk-through:
$ jackd -d alsa -d hw:0 --> fire up jackd on first card
$ alsa_in -d hw:1 --> add second card
$ alsa_in -d hw:2 --> add third card a.s.o.
Then, use any jack capture client you want, including jackrec,
jack_capture and ardour, just to name a few.
HTH
--
mail: adi(a)thur.de http://adi.thur.de PGP/GPG: key via keyserver
1:48 p.m.
On Wednesday 21 July 2010 03:17:56 Adrian Knoth wrote:
On Wed, Jul 21, 2010 at 02:24:09AM +0200, rom wrote:
This deals with the clock sync issue as is?
I'd like to ask some advice about a small
multitrack recorder program i
wrote, and have been using for some time. Basically, what it does is to:
- simultaneously capture sound from several consumer-grade soundcards.
- use libsamplerate to stretch the audio streams, re-syncing them to the
one chosen as "master". The stretch ratio is continuously re-calculated
to make the overall frame count of the stretched stream match the
overall frame count of the master.
- write the "corrected" streams plus the "master" stream to parallel
.wav files using libsndfile.
You basically reinvented jackd with additional alsa_in and jack_capture
or whatever recording tool (ardour?) a user intends to use.
Just a quick walk-through:
$ jackd -d alsa -d hw:0 --> fire up jackd on first card
$ alsa_in -d hw:1 --> add second card
$ alsa_in -d hw:2 --> add third card a.s.o.
Then, use any jack capture client you want, including jackrec,
jack_capture and ardour, just to name a few.
HTH
drew
1:49 p.m.
On Wed, Jul 21, 2010 at 7:48 AM, drew Roberts <zotz(a)100jamz.com> wrote:
yep.
$ jackd -d
alsa -d hw:0 --> fire up jackd on first card
$ alsa_in -d hw:1 --> add second card
$ alsa_in -d hw:2 --> add third card a.s.o.
Then, use any jack capture client you want, including jackrec,
jack_capture and ardour, just to name a few.
This deals with the clock sync issue as is? 
4:27 p.m.
> $ jackd
-d alsa -d hw:0 --> fire up
jackd on first card
> $ alsa_in -d hw:1 --> add second card
> $ alsa_in -d hw:2 --> add third card
a.s.o.
>
> Then, use any jack capture client you want,
including jackrec,
jack_capture and ardour, just to name a few.
This deals with the clock sync issue as is?
5050
days inactive
5051
days old
linux-audio-dev@lists.linuxaudio.org
10 comments
8 participants
participants (8)
-
Adrian Knoth -
Arnold Krille -
drew Roberts -
James Warden -
Patrick Shirkey -
Paul Davis -
rom -
torbenh