Audio (video) - Kindle. Getting it up and running, Code level.

[twobob]

THIS PAGE CONTAINS SEVERAL OUTPUTS OF THE DETAILS OF THE CARD VIA ALSA
AND LINK TO MORE AUDIO RESOURCES.

( and a note about ssh )
================================================== =======
Threads continued:

well happy days. kekekekeke Other than for some mysterious reason I can't get ANYTHING to launch on my K3 this morning ho, Also MyTs now won't start up. Not a great start to the morning.

[twobob]

TIP: If you are SSH'ing and your key has changed (This can be caused by your router updating amongst other, less secure, reasons)

You would recieve a big obvious warning from SSH
including "Kindles host key changed"

one solution is (allegedly): ssh-keygen -r {IP-Address}
For some reason this didn't work for me. (the command completed but I got an extra whitespace line in my file so...)

or simply vi /wherever/.ssh/known_hosts and (press) dd on the offending line and then (escape) :wq! to get out.
(That's what I did.)

also: sed -i ’{IP-Address}d’ /wherever/.ssh/known_hosts should do the trick (if you have sed)

Hope that helps.

[twobob]

Latest Diagnostic output

[root@kindle opt]# ./TellMeStuff
Device: hw (type: HW)
Access types: MMAP_INTERLEAVED RW_INTERLEAVED
Formats: S16_LE S24_LE S20_3LE
Channels: 2
Sample rates: 8000 11025 16000 22050 32000 44100 48000
Interrupt interval: 166-512000 us
Buffer size: 333-2048000 us
[root@kindle opt]#

[twobob]

TO REITERATE: For the interested:

/usr/share/alsa.conf declares hw, plughw, shm, tee, file and null on the pcm level. so those are the names we will be accessing via our code.

it also defines hwdep.default and hwdep.hw which I will try to have a look at at some point.

[root@kindle /dev]# cat /proc/asound/cards
0 [mx35luigi ]: WM8960 - mx35luigi
mx35luigi (WM8960)

Simple mixer control 'Headphone',0
  Capabilities: pvolume
  Playback channels: Front Left - Front Right
  Limits: Playback 0 - 127
  Mono:
  Front Left: Playback 0 [0%]
  Front Right: Playback 16 [13%]

Simple mixer control 'Headphone Playback ZC',0
  Capabilities: pswitch
  Playback channels: Front Left - Front Right
  Mono:
  Front Left: Playback [off]
  Front Right: Playback [off]

Simple mixer control 'PCM Playback -6dB',0
  Capabilities: pswitch pswitch-joined
  Playback channels: Mono
  Mono: Playback [off]

Simple mixer control 'Playback',0
  Capabilities: volume
  Playback channels: Front Left - Front Right
  Capture channels: Front Left - Front Right
  Limits: 0 - 255
  Front Left: 243 [95%]
  Front Right: 243 [95%]

Simple mixer control 'Playback De-emphasis',0
  Capabilities: enum
  Items: 'None' '32Khz' '44.1Khz' '48Khz'
  Item0: 'None'

Simple mixer control 'Capture',0
  Capabilities: cvolume cswitch
  Capture channels: Front Left - Front Right
  Limits: Capture 0 - 63
  Front Left: Capture 23 [37%] [off]
  Front Right: Capture 23 [37%] [off]

Simple mixer control 'Capture Volume ZC',0
  Capabilities: pswitch
  Playback channels: Front Left - Front Right
  Mono:
  Front Left: Playback [off]
  Front Right: Playback [off]

Simple mixer control '3D',0
  Capabilities: volume volume-joined pswitch pswitch-joined
  Playback channels: Mono
  Capture channels: Mono
  Limits: 0 - 15
  Mono: 0 [0%] Playback [off]

Simple mixer control '3D Filter Lower Cut-Off',0
  Capabilities: enum
  Items: 'Low' 'High'
  Item0: 'Low'

Simple mixer control '3D Filter Upper Cut-Off',0
  Capabilities: enum
  Items: 'High' 'Low'
  Item0: 'High'

Simple mixer control 'ADC High Pass Filter',0
  Capabilities: pswitch pswitch-joined
  Playback channels: Mono
  Mono: Playback [off]

Simple mixer control 'ADC PCM',0
  Capabilities: cvolume
  Capture channels: Front Left - Front Right
  Limits: Capture 0 - 127
  Front Left: Capture 0 [0%]
  Front Right: Capture 0 [0%]

Simple mixer control 'ADC Polarity',0
  Capabilities: enum
  Items: 'No Inversion' 'Left Inverted' 'Right Inverted' 'Stereo Inversion'
  Item0: 'No Inversion'

Simple mixer control 'ALC Attack',0
  Capabilities: volume volume-joined
  Playback channels: Mono
  Capture channels: Mono
  Limits: 0 - 15
  Mono: 2 [13%]

Simple mixer control 'ALC Decay',0
  Capabilities: volume volume-joined
  Playback channels: Mono
  Capture channels: Mono
  Limits: 0 - 15
  Mono: 3 [20%]

Simple mixer control 'ALC Function',0
  Capabilities: enum
  Items: 'Off' 'Right' 'Left' 'Stereo'
  Item0: 'Off'

Simple mixer control 'ALC Hold Time',0
  Capabilities: volume volume-joined
  Playback channels: Mono
  Capture channels: Mono
  Limits: 0 - 15
  Mono: 0 [0%]

Simple mixer control 'ALC Max Gain',0
  Capabilities: volume volume-joined
  Playback channels: Mono
  Capture channels: Mono
  Limits: 0 - 7
  Mono: 7 [100%]

Simple mixer control 'ALC Min Gain',0
  Capabilities: volume volume-joined
  Playback channels: Mono
  Capture channels: Mono
  Limits: 0 - 7
  Mono: 0 [0%]

Simple mixer control 'ALC Mode',0
  Capabilities: enum
  Items: 'ALC' 'Limiter'
  Item0: 'ALC'

Simple mixer control 'ALC Target',0
  Capabilities: volume volume-joined
  Playback channels: Mono
  Capture channels: Mono
  Limits: 0 - 15
  Mono: 4 [27%]

Simple mixer control 'DAC Polarity',0
  Capabilities: enum
  Items: 'No Inversion' 'Left Inverted' 'Right Inverted' 'Stereo Inversion'
  Item0: 'No Inversion'

Simple mixer control 'Left Output Mixer Boost Bypass',0
  Capabilities: volume volume-joined
  Playback channels: Mono
  Capture channels: Mono
  Limits: 0 - 7
  Mono: 2 [29%]

Simple mixer control 'Left Output Mixer LINPUT3',0
  Capabilities: volume volume-joined
  Playback channels: Mono
  Capture channels: Mono
  Limits: 0 - 7
  Mono: 2 [29%]

Simple mixer control 'Noise Gate',0
  Capabilities: pswitch pswitch-joined
  Playback channels: Mono
  Mono: Playback [off]

Simple mixer control 'Noise Gate Threshold',0
  Capabilities: volume volume-joined
  Playback channels: Mono
  Capture channels: Mono
  Limits: 0 - 31
  Mono: 0 [0%]

Simple mixer control 'Right Output Mixer Boost Bypass',0
  Capabilities: volume volume-joined
  Playback channels: Mono
  Capture channels: Mono
  Limits: 0 - 7
  Mono: 2 [29%]

Simple mixer control 'Right Output Mixer RINPUT3',0
  Capabilities: volume volume-joined
  Playback channels: Mono
  Capture channels: Mono
  Limits: 0 - 7
  Mono: 2 [29%]

Simple mixer control 'Speaker',0
  Capabilities: pvolume
  Playback channels: Front Left - Front Right
  Limits: Playback 0 - 127
  Mono:
  Front Left: Playback 0 [0%]
  Front Right: Playback 16 [13%]

Simple mixer control 'Speaker AC',0
  Capabilities: volume volume-joined
  Playback channels: Mono
  Capture channels: Mono
  Limits: 0 - 5
  Mono: 0 [0%]

Simple mixer control 'Speaker DC',0
  Capabilities: volume volume-joined
  Playback channels: Mono
  Capture channels: Mono
  Limits: 0 - 5
  Mono: 0 [0%]

Simple mixer control 'Speaker Playback ZC',0
  Capabilities: pswitch
  Playback channels: Front Left - Front Right
  Mono:
  Front Left: Playback [off]
  Front Right: Playback [off]

So its an Alsa-sound installation with some interesting bits and bats of settable params.

Specifically: Access to some basic 3D audio emulation and potentially some filtering
(By all accounts this often does nothing)

Automated Volume leveling and some fancy ADSR enums around it
Also uses some sort of target function which looks intriguing
(which could serve as a compressor limiter expander possibly mis-used correctly)

Settings for ADC / DAC inversion with single side inversion
(that may allow for phase effect tricks such as cancellation to be done without code)
Mic Boost is included which may actually come in handy. no doubt horrible.

A mono volume-joined noise gate - which is a nice bonus.

It is unclear if we will be able to access these features

http://tldp.org/HOWTO/Alsa-sound-6.html has a run down of much of info I have re-covered here.

the alsamixer and alsactl apps are also present.

[twobob]

HW device
The hw device description uses the hw plugin. The three arguments (in order: CARD,DEV,SUBDEV) specify card number or identifier, device number and subdevice number (-1 means any).

Example:

hw
hw:0
hw:0,0
hw:supersonic,1
hw:soundwave,1,2
hw:DEV=1,CARD=soundwave,SUBDEV=2

Plug->HW device
The plughw device description uses the plug plugin and hw plugin as slave. The arguments are same as for hw device.

Example:

plughw
plughw:0
plughw:0,0
plughw:supersonic,1
plughw:soundwave,1,2
plughw:DEV=1,CARD=soundwave,SUBDEV=2

Shared memory device
The shm device uses the shm plugin. The two arguments (in order: SOCKET,PCM) specify UNIX socket name (for example /tmp/alsa.socket) for server communication and server's PCM name.

Example:

shm:'/tmp/alsa.sock',default
shm:SOCKET='/tmp/alsa.sock',PCM=default

Tee device
The tee device stores contents of a stream to given file plus transfers it to given slave plugin. The three arguments (in order: SLAVE,FILE,FORMAT) specify slave plugin, filename and file format.

Example:

tee:hw,'/tmp/out.raw',raw

File device
The file device is file plugin with null plugin as slave. The arguments (in order: FILE,FORMAT) specify filename and file format.

Example:

file:'/tmp/out.raw',raw

Null device
The null device is null plugin.

This device has not any arguments.

Elided from http://www.alsa-project.org/alsa-doc/alsa-lib/pcm.html

[NiLuJe]

@twobob: Did you update USBNet and switch to OpenSSH? if you did, then, yeah, the keys changed (well, technically, OpenSSH uses a *different* key, dropbear still uses the same). Or did you just use another IP for the kindle, one that happened to have another key bound to on your local box? What's the fingerprint of the new key shown in the warning?

[twobob]

Originally Posted by NiLuJe

@twobob: Did you update USBNet and switch to OpenSSH? if you did, then, yeah, the keys changed (well, technically, OpenSSH uses a *different* key, dropbear still uses the same). Or did you just use another IP for the kindle, one that happened to have another key bound to on your local box? What's the fingerprint of the new key shown in the warning?

I use OpenSSH, not dropbear Auth. Kindle is fixed IP from the Router (DHCP fixed on kindle).

From my Router logs I see my internet provider updated the software on my router last night remotely.

I think that covers it. I'm like 99% sure it's because they foobarred my router
I'm in via SSH now. Thanks very much

[twobob]

Useful Links for Sound:

0.0) A simple blow-by-blow end users guide to setting up the non-programmatic parts of alsa
http://www.linuxjournal.com/node/8234/print
(Helpful for the alsa.conf and.rc constructs syntax, easy to read, non technical)

0.00) The technical version of the above article by the same people
http://www.linuxjournal.com/node/6735/print

0) A huge and outdated list of things we might want to dig through
http://www.clug.in-chemnitz.de/vortr...soundapps.html

0.2) The outrageously out-of-date http://linux-sound.org/ (REALLY needs a haircut)

0.5) Two very complete and highly obscure alsa init programs
http://alumnos.elo.utfsm.cl/~yanez/a...mple-programs/

1) Salsa: The small ALSA:
http://www.alsa-project.org/main/ind.../SALSA-Library

2) Notes on X-compiling Alsa (adjust to your flavour)
http://omappedia.org/wiki/ALSA_Setup#ALSA_library

3) http://www.alsa-project.org/main/index.php/DevEmbedded
Excerpt: Clearly you need to check what you actually NEED for your device

building the minimal alsa library.

--disable-aload disable reading /dev/aload*
--disable-mixer Disable the mixer component
--disable-pcm Disable the PCM component
--disable-rawmidi Disable the raw MIDI component
--disable-hwdep Disable the hwdep component
--disable-seq Disable the sequencer component
--disable-instr Disable the instrument component
--disable-alisp Disable the alisp component
--with-pcm-plugins=<list> Build PCM plugins

Note that only hw plugin is important for pcm if applications will do all conversions itself.
for example:

./configure --disable-aload --disable-mixer --disable-rawmidi
--disable-hwdep --disable-seq --disable-instr --disable-alisp
--with-pcm-plugins=hw
# also you could:
strip -g --remove-section=.comment --remove-section=.note libasound.so
# however don't strip statics AIUI.

4) http://www.alsa-project.org/main/ind...Developer_Zone
or http://home.roadrunner.com/~jgglatt/tech/aplay.htm are great resources for getting going
or the very basic http://superuser.com/questions/35727...configure-alsa
or the more technical http://www.sabi.co.uk/Notes/linuxSoundALSA.html
and the more esoteric test area http://tldp.org/HOWTO/Alsa-sound-6.html
or the almost complete full-duplex example:
http://www.saunalahti.fi/~s7l/blog/2...0Duplex%20ALSA
or http://www.suse.de/~mana/alsa090_howto.html#sect03 isn't bad either

5) alsactl tip: If alsactl is available, you can adjust input/output/level values to your liking and execute: alsactl -f settings.alsa store and, reversely alsactl -f settings.alsa restore on startup.

6) Notes on PCM Latency

frames should be the number of frames (samples) you want to write from the buffer. Your system's sound driver will start transferring those samples to the sound card right away, and they will be played at a constant rate.

The latency is introduced in several places. There's latency from the data buffered by the driver while waiting to be transferred to the card. There's at least one buffer full of data that's being transferred to the card at any given moment, and there's buffering on the application side, which is what you seem to be concerned about.

To reduce latency on the application side you need to write the smallest buffer that will work for you. If your application performs a DSP task, that's typically one window's worth of data.

There's no advantage in writing small buffers in a loop - just go ahead and write everything in one go - but there's an important point to understand: to minimize latency, your application should write to the driver no faster than the driver is writing data to the sound card, or you'll end up piling up more data and accumulating more and more latency.

7) How to select an ALSA sound card and have concurrent, simultaneus playback using dmix
http://ptspts.blogspot.co.uk/2009/03...-and-have.html

8) Alsa issues help
http://www.alsa-project.org/~valenty...i-HOWTO-7.html

9) Alsa bits and bats
http://www.alsa-project.org/alsa-doc/alsa-lib/pcm.html
http://www.alsa-project.org/alsa-doc.../examples.html

10) The midi Guy
http://home.roadrunner.com/~jgglatt/progs/software.htm
midi http://home.roadrunner.com/~jgglatt/...rawmidplay.htm

11) Ring Buffer:
http://soundprogramming.net/programm..._a_ring_buffer

12) SDL http://www.libsdl.org/download-1.2.php

13) x-compiling Gstreamer for kindle (Incomplete)
http://www.mobileread.mobi/forums/sh...d.php?t=119284

14) A cool read for embedded linux - outdated I believe as ever.
Audio in Embedded linux systems

ADVANCED MATHS AND SOUND CONCEPTS:

15) Some serious reading for the big folks http://www.dspguru.com/dsp/tricks/sine_tone_generator

16) more serious crunching tricks (thanks GM) http://aggregate.org/MAGIC/#Log2%20of%20an%20Integer
I'll update/expand this as I find decent stuff

[twobob]

BUG: (noted at http://elinux.org/RidgeRun_LeopardBoard_SDK_Hints

To Check for this simply run

arecord -D 'plughw' -r 8000 -f S16_LE -c 2 | aplay -D 'plughw'

nothing happens, now try

aplay somefile.wav

THEN (GET READY TO TURN THE VOLUME DOWN)

arecord -D 'plughw' -r 8000 -f S16_LE -c 2 | aplay -D 'plughw'

now you can see the pipe works correctly
This seems to be as the result of a "'division by zero' in kernel error " on other systems so that's probably a good lead.

I think we may have a possible link to a solution (well roughly)

 Solutions to known issues
'division by zero' in kernel error when I try to use ALSA input

This is a known issue that has been discussed on the ASOC mailing list. 
The problem is that the function davinci_pcm_enqueue_dma performs this operations:

data_type = prtd->params->data_type;
count = period_size / data_type;

The first time, data_type is set to zero, so we get the error Division by zero in kernel. 
This is the reason why the pipe arecord | aplay works after running arecord or aplay first.

Apply the Media:Asoc-davinci-pcm.patch 
<http://elinux.org/images/9/95/Asoc-davinci-pcm.patch> 
to the kernel 2.6.29 to resolve this issue.

So I will have a look at that at some point but good to know I have a quick fix for instancing the soundcard, at our command, in full-duplex now at least.

so happy days there.

FULL-DUPLEX is GO (okay with some wangles and a reliant on two native apps but it should pave the way for some interesting piping hey Geekmaster

THIS IS THE REASON THE OTHER VOIP APPLICATION DIDN'T WORK I THINK
I am thinking of making it run through dmix0 now. that may have value.

in the interim. aplay > blank.wav; causes the card to snap out of it, it would seem

[knc1]

Originally Posted by twobob

BUG: (noted at http://elinux.org/RidgeRun_LeopardBoard_SDK_Hints

To Check for this simply run

arecord -D 'plughw' -r 8000 -f S16_LE -c 2 | aplay -D 'plughw'

nothing happens, now try

aplay somefile.wav

THEN (GET READY TO TURN THE VOLUME DOWN)

arecord -D 'plughw' -r 8000 -f S16_LE -c 2 | aplay -D 'plughw'

now you can see the pipe works correctly
This seems to be as the result of a "'division by zero' in kernel error " on other systems so that's probably a good lead.

I think we may have a possible link to a solution (well roughly)

 Solutions to known issues
'division by zero' in kernel error when I try to use ALSA input

This is a known issue that has been discussed on the ASOC mailing list. 
The problem is that the function davinci_pcm_enqueue_dma performs this operations:

data_type = prtd->params->data_type;
count = period_size / data_type;

The first time, data_type is set to zero, so we get the error Division by zero in kernel. 
This is the reason why the pipe arecord | aplay works after running arecord or aplay first.

Apply the Media:Asoc-davinci-pcm.patch 
<http://elinux.org/images/9/95/Asoc-davinci-pcm.patch> 
to the kernel 2.6.29 to resolve this issue.

So I will have a look at that at some point but good to know I have a quick fix for instancing the soundcard, at our command, in full-duplex now at least.

so happy days there.

FULL-DUPLEX is GO (okay with some wangles and a reliant on two native apps but it should pave the way for some interesting piping hey Geekmaster

THIS IS THE REASON THE OTHER VOIP APPLICATION DIDN'T WORK I THINK

Hmm...
Disclaimer: I haven't read the above patch (yet).

That problem should not be "in the kernel" it should be "in the related kernel module".

We don't want to ask users to bspatch their kernel, but a module???
That should be easy, the modules are located in the main file system under /lib/modules.

It ***should*** be possible to re-build the corrected module and just replace it in the system file system image.

BUT ...
Just depending on an execution of "aplay" to "prime the pump" should do for now. (KeK isn't ready to rebuild kernel modules).

[twobob]

Originally Posted by knc1

Hmm... BUT ...
Just depending on an execution of "aplay" to "prime the pump" should do for now. (KeK isn't ready to rebuild kernel modules).

I completely agree. a simply .sh wangle with a mute mono file *i have already made one* should be enough, perhaps even invoking the null device may work. have to test.

Yep on the wait and see what would be best. Happy to report the workaround and a lead on a fix though

I reported the error on the Pjsua thread.
the error seems to sound identical ( and I mean acoustically)
ah well - another headache possibly sorted. : ))

Happy days

=======================

Not sure if relevant. noting for future research
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27363

[twobob]

APLAY FORMATS FOR REFERENCE

By default it seems that aplay uses the -D "default", this provides access to the auto-formatting conversions magickery

it also recognises the -D plughw and -D plughw:0 and plughw:0,0

This gives us a rough idea of the kind of formats we might expect to get working out of the box as it were if we used this device. So worth a dig around.

entered lower case aplay -f {format}

RATES / FORMATS SUPPORTED

Spoiler:

plughw supports from 4k to 192k

hw supports 8k -48k ( a decent surprise I thought)

Spoiler:

WORKING (rate at 8k default, unless otherwise indicated)

Format: U8 Unsigned 8 bit, Rate 8000 Hz, Mono
Format: S16_LE Signed 16 bit Little Endian, Rate 8000 Hz, Mono

Format: CD Signed 16 bit Little Endian, Rate 44100 Hz, Stereo (Note the higher rate)
Format: DAT Signed 16 bit Little Endian, Rate 48000 Hz, Stereo

Format: S24_LE Signed 24 bit Little Endian, Rate 8000 Hz, Mono
Format: S32_LE Signed 32 bit Little Endian, Rate 8000 Hz, Mono

Format: S24_3LE (Signed 24 bit Little Endian in 3bytes, Rate 8000 Hz)

NOT WORKING

Format: U16_LE
Format: S8
Format: U16_BE
Format: S16_BE
Format: S24_BE
Format: U24_LE
Format: U24_BE
Format: S32_BE
Format: U32_LE
Format: U32_BE
Format: FLOAT_LE
Format: FLOAT_BE
Format: FLOAT64_LE
Format: FLOAT64_BE
Format: IEC958_SUBFRAME_LE
Format: MU_LAW
Format: A_LAW
Format: IMA_ADPCM
Format: GSM
Format: SPECIAL

Format: S24_3BE
Format: U24_3LE
Format: U24_3BE
Format: S20_3LE
Format: S20_3BE
Format: U20_3LE
Format: U20_3BE
Format: S18_3LE
Format: S18_3BE
Format: U18_3LE
Format: U18_3BE

Whereas passing it the hardware flag -D hw or it's synonyms hw:0 or hw:0,0 (with the required -c 2 stereo flag, mono is not hw supported)

Reduces us to:

aplay -D {hw-synonym} -c 2 -f {format}

Format: S16_LE
Format: S24_LE
Format: S20_3LE

Which is realistic. This tallies up neatly with our previous HW evidence:

Formats: S16_LE S24_LE S20_3LE
Channels: 2
Sample rates: 8000 11025 16000 22050 32000 44100 48000
Interrupt interval: 166-512000 us
Buffer size: 333-2048000 us

There are no doubt more permutations and shorthands I have missed.
Please feel free to append. This wasn't about underruns or performance, simply establishing current applications alsa compliance and how they make the card work effectively.

Further thoughts:

So aplay is pretty solid.

stracing the playback and init stage might give us some clues so I have done that here
with two different types of file. One mono 44k, and one strereo 22k, To see what aplay decides about playback.

Seemingly the 44k mono causes a poll typed playback, whereas the 22k caused a direct interleaved decision. Full info in the straces attached (somewhat pruned for brevity), it's interesting stuff.

The Alsa init in aplay is particularly thorough and looks like something we really should aim to emulate.

Next steps? Possibly try stracing arecord | aplay and watch how it handles underruns.

[twobob]

Now Dmix is allegedly a good thing.

It would be nice to have to have multiple instances of sound applications all making nice at the same time without all those awkward "Device is Busy" warnings.

By all accounts read so far it as simple as implementing the correct section in the alsa.conf

a brief glimpse at my alsa.conf seems to confirm that the stubs are there for the dmix in

...
# defaults

defaults.pcm.dmix_max_periods 0
defaults.pcm.dmix_max_rate 48000
defaults.pcm.dmix_max_fornat S16_LE
...

so the next step is to see if the pcm has the dmix configured as a slave as per the instructions here:

http://www.alsa-project.org/main/index.php/Asoundrc

dmix

These days we have a native plugin for ALSA called the dmix (direct mixing) plugin. It allows software mixing in an easy to use syntax and without the hassle of installing/understanding a new application first.

A very interesting and potentially extremely useful aspect of this plugin is using it combined with the default plugin name. In theory this means all applications that have native ALSA support will share the sound device. In practice not many applications are able to take advantage of this functionality yet. However if you have time to test and report your findings to the application developers it is worth a try:

pcm.!default {
type plug
slave.pcm "dmixer"
}

pcm.dmixer {
type dmix
ipc_key 1024
slave {
pcm "hw:1,0"
period_time 0
period_size 1024
buffer_size 4096
rate 44100
}
bindings {
0 0
1 1
}
}

ctl.dmixer {
type hw
card 0
}

(To use it with your own name just change the word !default above)

so that's seems relatively straightforward let's see what we have in our alsa.conf...

well there is a reference to it being instantiated but not actually configured:

pcm.dmix cards.pcm.dmix

so it looks like we will have to add the actual config to the alsa.conf either directly or indirectly via alsactl.

The intention is to leave everything that was originally installed on the device intact.
At the very least to restore it to the exact original configuration after we are done.

However since multiple application may need to use this dmix device - outside of the scope of an individual instance of an application - this would seem to need to be a system-wide and permanent change.

So next question: would the intended changes affect the operation of anything on the device currently?

No, it is simply finishing off initialising what is already instanced so in this case I think an exception can be made to the ideal of never touching system files.

Next question: How can we undo any changes we might make?

Alsactl has a store and restore facility that I will make use of to implement an "uninstall". It should be fairly trivial and actually really just a case of simply restoring the image of the original alsa.conf as opposed to any clever -changed-state-rollback wangles. Happy days there then.

More research on that to follow I think.

trying something like

[root@kindle video]# Balsamic test.wav
(with the device internally set to "dmix")

(First the config lookup error

ALSA lib conf.c:3501:(snd_config_hook_load) 
cannot stat file/directory /blah-blah/CodeSourcery/
Sourcery_CodeBench_Lite_for_ARM_GNU_Linux/share/alsa/cards/aliases.conf

Then a reference to dmix being link to device.pcm.dmix and it not working.:

ALSA lib pcm.c:2217:(snd_pcm_open_noupdate) 
Unknown PCM cards.pcm.dmix
Can't open audio dmix: No such file or directory

If the link to the conf is fixed we get:

[root@kindle video]# ./Balsamic test.wav
ALSA lib pcm.c:7431:(snd_pcm_set_params) 
Rate doesn't match (requested 44100Hz, get 0Hz)
Can't set sound parameters: Invalid argument

Which looks like it's not setup. so...

Next step. Alsactl Store and restore (and test just doing the setup by hand)

[twobob]

so.... Let's see if we can get a nice recording dialog going to easily test our input actually does something.

A visual readout would be nice so we shall check it with the arecord -vv -fcd /somewhere/safe/and/useful/blah.wav (optionally set the duration with -d in integers as seconds like: -d 30)



The ##############+'s at the bottom (in the image callout) will dynamically go up and down according to the input level.

What if it doesn't go up and down?
Assuming you didn't edit any files on the device to do with alsa config, since the alsa config is pre-setup on these devices for you, the microphone is broken. Highly unlikely to happen IMHO though.

Also note that devices have differing sound support, if yours has none for example this will not work

[twobob]

Dmix only supports the output stream:

As you can see dmix will only be useful for mixing the DAC section of our card.

ALSA lib pcm_dmix.c:957:(snd_pcm_dmix_open) The dmix plugin supports only playback stream

It can be referenced via device dmix0 seemingly