I'm back! (sort of)

Bas Wijnen wijnen at debian.org
Sun Jan 22 05:45:24 EST 2012

Hash: SHA1

Hi Jane,

On 22-01-12 11:00, Jane Andreas wrote:
> Ok, so this has been a solo thread for a while, but yet another
> thing has happened!

It's so nice that problems get solved by talking about them, even if
you get no answer. :-D

> I fixed sound by running 'alsa reload' and that has fixed the sound
> across 3 reboots now.

alsa reload just restores the mixer settings, so it must have been
possible by turning the right knob as well. Maybe the 'bypass audio
mixer' :-)

> Also, I discovered that the 'bypass audio mixer' option or
> something like that has to be enabled to hear sound. Might this be
> why the volume controls in alsamixer do not seem to work right? I
> found the same in OpenWRT when trying to use alsamixer from a
> console. So when master volume is at 00, you can still hear sound.
> There does seem to be a difference between, 100, 66, 33, and 0 but
> it seems off.

Page 301 of the programmer's manual has a diagram which explains this.
In short (things not relevant for Ben left out):

On the left, there is the microphone input, which has a volume control.
The microphone is lead into an ADC so the digitized sound can be used
(recorded) by the CPU.
A different signal can be sent from the CPU to the codec.
(for some reason the codec->cpu and cpu->codec are drawn as one block.
I think they are very separate from the sound driver's point of view,
Now for the interesting parts:
The output of the DAC (sound from the cpu) can be switched off.
Then it is mixed with a bypass which comes directly from the
microphone (which can also be switched off).
Then there's a volume control.
The output of that goes to the speaker and audio jack.

So the controls that the codec provides are:
- - record volume
- - playback volume
- - bypass from microphone to output enable/disable
- - DAC output enable/disable

You will usually not want the microphone signal to be audible on your
output, so the first switch will be off. The second should (almost)
always be on, though, otherwise you will not hear any sound that is
played by the system.

> As for the 'dirty' sound for some reason it sounds a little better,
> and not bad at all through headphones, but there is a tick that can
> be heard about every second that is not part of the sound file (I
> verified by playing the files on another computer). If it could be
> fixed in OpenWRT, it should be possible in Debian Sid, at least I
> hope.

I have not yet started to work on sound in Iris, so I can't say much
about it. The only thing I can say is that when I do, I expect to be
able to answer the question whether this is an unavoidable hardware
problem. I sure hope it isn't.

> I remembered the specific message I get at boot time about the
> sound module that cannot load. It is: [17.490000] No device for DAI
> jz4740-i2s

That is no problem at all. The SoC supports both an AC97 and I2S
codec. An AC97 codec is implemented on-chip, I2S is not. Since the Ben
doesn't have an external codec, I2S is indeed not present. This is no
problem, because the internal (AC97) codec is used.

Version: GnuPG v1.4.11 (GNU/Linux)


More information about the discussion mailing list