Audio/sensor input on XO-1 (was: Re: schematic for olpc)

[Sascha Silbe]

Excerpts from Michael Shiloh's message of Tue Jun 08 04:59:43 +0000 2010:

> Do you know the state of the Measure project? Their goals seem very 
> close to mine.
I've been working to fix the most important issues, but the code is
obscure, undocumented and not well-understood by the people currently
working on it (i.e. Walter and me). In other words: it needs a rewrite.

My original plan was to utilize topology and gain information from the
audio driver so Measure can automatically derive the voltage on most
hardware, but the current audio driver framework on Linux is too limited:


=== Begin quote ===
On Wed, May 12, 2010 at 09:01:10PM +0200, Sascha Silbe wrote:

> a) utilizing mixer dB values where available (might need gstreamer  
> patches) to calculate actual voltages,

OK, scratch that. ALSA sucks. From [1]:

    * the dB scale is is almost useless. dB is a relative scale and ALSA 
didn't define what the reference level is. All mixer controls on all 
sound drivers use different reference levels. Hence the dB scale is not 
any more useful than that they are pretty to look at and make you feel 
like oh-i-am-such-a-guru-i-look-at-dB-levels.

    * It's not possible to know the inter-relation of ctls (except single=
 
switch/track couple), and the relation with actual devices: internal 
mic, loudspeaker, laptop red jack, rear green jack, usb headset mike (or 
at least, this is quite tricky, or not well exposed)

    * There's no way to detect whether a snd_smixer element is 
implemented in software or not. Thus writing an application that uses 
the PCM device hw: (or front:, surround51:, ...) and the smixer/mixer 
interfaces at the same time with sensible behaviour is impossible. 
Because for those devices software volume adjustments don't take place, 
and thus the controls we find are useless.

    * There is no way to find the right mixer device for a PCM device. 
There is no way to find which one is the right mixer track to use to 
control input and output PCM volume, other then guessing by the name.


So all we can do is:

1. Detect specific hardware (namely XO-1 and XO-1.5), set secondary 
controls to predefined values and use hardcoded sample value -> voltage 
conversion.

2. Save + restore mixer settings across Stop / resume. Rely on the user 
to adjust the mixer controls prior to starting a new session. With some 
luck the defaults set by alsa-utils are sufficient.

3. Add UI for calibrating the setup (on unknown hardware). Let the user 
hook up hardware that generates a signal with known voltage levels 
(peak-to-peak), sample for a second and generate conversion factors from 
min/max values.


[1] http://pulseaudio.org/wiki/AlsaIssues
=== End quote ===

Most of this applies only to running Measure on non-XOs. What does apply
to XOs is the UI I'd like the rewrite to have:

=== Begin quote ===
  b) looking more like a "traditional" / "real" oscilloscope
  c) supporting more features from "traditional" oscilloscopes, e.g. XY
  mode (XO-1.5 + non-XOs only since XO-1 has just a mono input).
=== End quote ===

Sascha

-- 
http://sascha.silbe.org/
http://www.infra-silbe.de/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://lists.laptop.org/pipermail/devel/attachments/20100608/de67eb0b/attachment.sig>