From alsa-devel-owner@alsa.jcu.cz  Thu Jan  7 11:12:57 1999
Received: from nic.funet.fi (nic.funet.fi [128.214.248.6])
	by marvin.jcu.cz (8.9.1a/8.9.1) with ESMTP id LAA04082
	for <alsa-devel@alsa.jcu.cz>; Thu, 7 Jan 1999 11:12:08 +0100
Received: from localhost (user: 'kouhia', uid#241) by nic.funet.fi id <20343-2277>; Thu, 7 Jan 1999 12:11:54 +0200
From: Juhana Sadeharju <kouhia@nic.funet.fi>
To: alsa-devel@alsa.jcu.cz, audiotechque@fmc-container.mach.uni-karlsruhe.de
In-reply-to: <369278EA.54FD96DD@alphalink.com.au> (message from Andrew Clausen
	on Wed, 06 Jan 1999 07:41:14 +1100)
Subject: Re: Recording and PSL
Message-Id: <19990107101156Z20343-2277+1673@nic.funet.fi>
Date: 	Thu, 7 Jan 1999 12:11:54 +0200
Reply-To: alsa-devel@alsa.jcu.cz
Sender: alsa-devel-owner@alsa.jcu.cz
Precedence: list

>From:	Andrew Clausen <clausen@alphalink.com.au>
>
>Yep.  But its probably common for people to record against other tracks (eg
>drum track) to keep in time.  This is obviously full-duplex.  They may even
>want to hear themselves.  I think most musicians think this is a must.

Right. But multitrack recorder could be used to record live performances.
Then it is recording only.

I think the one copy from kernel space to user space will count when
we use computer as realtime effect box only. We could forget the memory
mapping when we play or record with disk since the disks might be the
main bottleneck then.

>> So, does the increasing of the recording fragment size help?
>
>It should, but I'm surprised there are problems, anyway.

Me too. You could check you system by recording a sinus signal from
a synth. Just in case...

We could think what kind of audio test we could provide for users. Since
ALSA can tell if overruns happened, no any test signal is needed, or?
Since at least my recording program has free parameters to adjust,
the test program could search optimal values.

>> Since we want record as fast as possible, there is no time to join
>> channels or such.
>
>What do you mean by "as fast as possible"?  Is this to avoid breaks in the
>data, or writing falling behind the reading?  I think there'd be *heaps* of
>time to do joining, etc.

I'm not expert on this. Most probably I were wrong
The same applies to my claim:
>> Also, recording with PSL so that PSL splits the stereo channels
>> is quite inefficient.

I guess we could just write a general test program to test if audio
breaks. There could be a plenty of parameters and options to alter:
  -inputs: A/Ds, disk file, multiple files;
  -effects -- a simple effect chain for selected channels;
  -outputs: D/As, disk file, disk files; for selected channels;
  -in writing to disk: full interlacing/buffer interlacing (if no effects)/
   output to separate files (channel grouping);
  -fragment sizes;
  -read()'s buffer size when reading from A/Ds;
  -write()'s buffer size when writing to disk files; assuming read() and
   write() buffer size is the same for A/D and D/A.

Yours,

Juhana

