From alsa-devel-owner@alsa.jcu.cz  Tue Jan  5 21:51:55 1999
Received: from mail.alphalink.com.au (mail03.alphalink.com.au [203.24.205.7] (may be forged))
	by marvin.jcu.cz (8.9.1a/8.9.1) with ESMTP id VAA03161
	for <alsa-devel@alsa.jcu.cz>; Tue, 5 Jan 1999 21:48:39 +0100
Received: from alphalink.com.au (IDENT:andrew@ppp60-3-Melbourne.alphalink.com.au [203.62.181.60]) by mail.alphalink.com.au (8.9.2/8.6.9) with ESMTP id HAA27978; Wed, 6 Jan 1999 07:43:36 +1100 (EST)
Message-ID: <369278EA.54FD96DD@alphalink.com.au>
Date: Wed, 06 Jan 1999 07:41:14 +1100
From: Andrew Clausen <clausen@alphalink.com.au>
MIME-Version: 1.0
To: alsa-devel@alsa.jcu.cz,
        "audiotechque@fmc-container.mach.uni-karlsruhe.de" <audiotechque@fmc-container.mach.uni-karlsruhe.de>
Subject: Re: Recording and PSL
References: <19990105141640Z6968-2281+1422@nic.funet.fi>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Reply-To: alsa-devel@alsa.jcu.cz
Sender: alsa-devel-owner@alsa.jcu.cz
Precedence: list

Juhana K Kouhia wrote:

> >From:  Andrew Clausen <clausen@alphalink.com.au>
> >
> >> the recording performance. Perhaps, by enlarging the recording fragment
> >> size (which is purposedly put to 1/4 of what it is normally) because
> >> then we get less A/D interrupts.
> >
> >But that also increases latency.  Pain in the arse, isn't it?
>
> Hmm.. the fragment size is 4 times larger when playing. Does that count
> for latency much more? When we need latency we are mostly doing fullduplex
> recording and playing after applying some effect. At most we simultanously
> play audiofiles. Reading files from disk is not that big problem because
> the disk reading operation is more uniform within the time, correct?

Also, if you've say got a midi keyboard connected up, and you've got a synth
program, you want the notes to come out when you press them....

> We seems to have two different recording purposes: (i) realtime audio,
> and (ii) plain recording to disk.
>
> The latency in recording to disk is meaningless. Since we want succeed
> in recording we want to only record and not do any effects --- those can
> be made during the play or in non-realtime.

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.

> So, does the increasing of the recording fragment size help?

It should, but I'm surprised there are problems, anyway.

> I have started to write an introductory document to audio recording
> (playing). I will post it here too because there are many question.
> Are there already documentation available on fine details of audio
> recording (playing)? I looked at ALSA driver docs but they were quite
> rough, higher level talk. They didn't tell much about buffers, IRQs,
> etc. If there are no that level documents, you may want to wait my
> questions before explaning.
>
> >ALSA doesn't (afaik) support mmap, but OSS does.
>
> To the wishlist. I will eventually look at the code but I can't promise
> any results. We need it because memory mapping speeds up the recording.

How significant is the speed-up?

> >What do you mean by one stream in interlaced form?  I've never thought of
> >that.  PSL can't do it (my objective was to split up streams, not join
> >them...) - but it wouldn't be very hard to add support.  Why do you want to
> >do it?
>
> I do the recording by reading audio in N samples chunks with read().
> 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 assuming the audiocard itself puts the stereo samples to left/right
> interlaced format. If we record with 8 audiocards, then we should not
> interlace all 16 channel samples. Instead, I will interlace all chunks
> of N samples in my program. The resulting audiofile is then quite
> non-standard but I already have my own audiofile format which we could
> use for this. An audio software should support my format because
> interlacing audio afterwards requires an extra disk space.

I follow you now.   Yep - sounds like a good idea to me.

> I guess this doesn't concern ALSA unless it try to join multiple audio
> channels. Also, recording with PSL so that PSL splits the stereo channels
> is quite inefficient.

Is it?  Can you prove it to me?  What's a good way of benchmarking it?
CPU time isn't a useful measure I guess, because its more IO (including memory
IO).

There's a separate function for each conversion type, and gcc with
optimizations is pretty good.  I haven't really done any extensive benchmarking
with it, but I've had no problems writing simple full duplex filters.

Note:  for everyone watching this out there, you can get psl at
www.alphalink.com.au/~clausen

Andrew Clausen


