From alsa-devel-owner@alsa.jcu.cz  Thu Aug 20 21:50:01 1998
Received: from entry.jcu.cz (perex@entry.jcu.cz [160.217.1.111])
	by marvin.jcu.cz (8.8.8/8.8.8) with SMTP id VAA20941;
	Thu, 20 Aug 1998 21:48:59 +0200
Date: Thu, 20 Aug 1998 21:48:59 +0200 (MET DST)
From: Jaroslav Kysela <perex@jcu.cz>
To: Maximilian Bisani <bisani@kawo2.rwth-aachen.de>
cc: alsa-devel@alsa.jcu.cz
Subject: Re: Detecting ADC Overload
In-Reply-To: <Pine.LNX.3.96.980820194827.231A-100000@phoenix.kawo2.rwth-aachen.de>
Message-ID: <Pine.LNX.3.96.980820213624.3156C-100000@entry.jcu.cz>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=ISO-8859-2
Content-Transfer-Encoding: 8bit
Reply-To: alsa-devel@alsa.jcu.cz
Sender: alsa-devel-owner@alsa.jcu.cz
Precedence: list

On Thu, 20 Aug 1998, Maximilian Bisani wrote:

> 
> Hello!
> 
> Since I am new on this list I would like to express my admiration for what
> you have achieved so far.
> 
> I am currently writting a tiny alsa-native program to automatically adjust
> the mixer setting of the selected recording source, similar to the auto
> rec-level feature of my tape deck.  The method is very simple:  Increase
> the record level until the signal exceeds the permissible input range of
> the ADC (I think this is called "overloading") then drop it slowly
> until no more overloads occur (for several seconds).
> 
> My problem: How do I detect overloading?  From my experiments I found that
> peaks get truncated to a certain maximum value.  When I record with
> SND_PCM_SFMT_S16_LE and SND_PCM_OPEN_RECORD a signal too high gives +32767
> (0x7fff) and a signal too low signal gives -32768 (0x8000), which I had
> expected.  When I switch to SND_PCM_OPEN_DUPLEX (for "after tape
> monitoring") however, the values range from -32640 to +32640 only. 

Very good question. Explain follows.

> So I have three questions:
>  - Is there a better way to detect ADC overloading, than looking for 
>    peak values?
>  - Why are the maximum and minium values different in DUPLEX mode?
>  - If maximum and minimum values are mode (and posibly hardware; btw I
>    have an SB 32 AWE) dependent, shouldnt there be a library function,
>    so that an application such as mine, can find out?

Your problems with different peak values is in your broken hardware. SB16
(+ compatibles) have one channel 8-bit and second 16-bit. Unfortunately
8-bit channels can transfer only 8-bit samples and 16-bit only 16-bit
samples. This means that driver must do conversion from 16-bit -> 8-bit or
8-bit -> 16-bit samples if necessary.

If you open PCM device in duplex mode - for playback is assigned 16-bit
DMA and for record is assigned 8-bit DMA. 8-bit sample is simply converted
to 16-bit by adding 0x80 to lower byte of 16-bit sample. This is why you
get range from -32640 to +32640. You can choose if record channel could
use always 16-bit over /proc/sound/0/sb16 interface (look to INSTALL or
FAQ howto).

With ALSA API you can detect if driver does conversion of samples.
Variable snd_pcm_record_info_t -> flags have flags SND_PCM_RINFO_8BITONLY
and SND_PCM_RINFO_16BITONLY. This flags shows to application driver state.

>P.S. Are you still in need of someone to improve the API documentation?

There is two documentations. One for kernel side of ALSA driver and second
for ALSA C library + ALSA API (aka /usr/include/linux/sound.h). If you
want extend second (from ALSA library package) - none is working on it at
this time.

						Jaroslav 

-----
Jaroslav Kysela <perex@jcu.cz>
Academic Computer Centre, University of South Bohemia
Branisovska 31, C. Budejovice, CZ-370 05 Czech Republic



