From alsa-devel-owner@alsa.jcu.cz  Tue Jan  5 15:26:20 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 PAA30125
	for <alsa-devel@alsa.jcu.cz>; Tue, 5 Jan 1999 15:18:47 +0100
Received: from localhost (user: 'kouhia', uid#241) by nic.funet.fi id <6968-2281>; Tue, 5 Jan 1999 16:16:38 +0200
From: Juhana K Kouhia <kouhia@nic.funet.fi>
To: alsa-devel@alsa.jcu.cz
In-reply-to: <36911741.8EE8C86C@alphalink.com.au> (message from Andrew Clausen
	on Tue, 05 Jan 1999 06:32:17 +1100)
Subject: Recording and PSL
Message-Id: <19990105141640Z6968-2281+1422@nic.funet.fi>
Date: 	Tue, 5 Jan 1999 16:16:38 +0200
Reply-To: alsa-devel@alsa.jcu.cz
Sender: alsa-devel-owner@alsa.jcu.cz
Precedence: list

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

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.

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

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.


>> I have a question: if I record from 4 stereo audio cards, how samples
>> are put to one stream in interlaced form? Can ALSA do it? Or is PSL
>> needed? Perhaps it would be most efficient to interlace only the buffers
>> used for reading, i.e., not the samples. Buffers could be read directly
>> to the shared memory buffer.
>
>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.

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

Yours,

Juhana

