[Letux-kernel] ***UNCHECKED*** Re: Fixing Audio driver

Michael Mrozek EvilDragon at openpandora.org
Thu May 23 22:28:02 CEST 2019

On Do, 2019-05-23 at 19:26 +0200, H. Nikolaus Schaller wrote:


> > aTc made a quick test yesterday playing audio with software mixing
> > through the headset - and it took 1,5% CPU power.
> That is not really much and shows how powerful the OMAP5 is.

Yes, and that AESS is at least not that important in regards of power
saving (at least for the moment)

> > So software mixing is not as bad as I feared and it would be good
> > enough for the beginning.
> I know, because that was working for quite some time. I just can't
> tell you why it is currently broken for you. Or with 5.1/5.2 kernels.

Software mixing is not broken.
When we access the specific device using ALSA, it works - but our
installation uses PulseAudio, and that probably checks all existing
ALSA devices and then causes the kernel lock.

Well, that, and that weird mapping. But the headset works fine (with

> > We don't need any advanced Bluetooth, LTE-Modem or other features
> > at the beginning, those can always be delivered later.
> They do not harm if we find out why handsfree audio is broken for
> you.

No, they don't cause any harm for fixing the audio issue, but for the
normal release OS, I don't want to have any not-working devices around.
That OS is meant for normal users, so Bluetooth controls should only
appear when a bluetooth headset is paired - the way it works on every
normal system, be it Linux, Windows, MacOS or Android :)

So for the moment, they can stay, but for the release we should either
disable or fix them :)

> Because they are independent drivers sitting inactively around.

Then blacklisting them should be easy.

> > > As far as I understand you need AESS to make it different. So we
> > > either have the channel 3+4 thing or have to fix AESS. No way
> > > through the middle...
> > That wouldn't make any sense in my opinion.
> > According to the TWL6040 feature list, the chip has multiple stereo
> > outputs - not one output with four channels.
> That may be a matter of wording and perspective. 2 stereo channels
> may be seen as four outputs with 1 channel. Or one output with 4
> channels. It is always 4 wires to 4 speakers.

I am well aware that on a hardware level, everything can be seen as
single output.

That's the same for every audio card out there, Stereo, Multichannel or

And then you've got a driver - and one of the tasks of a driver is to
map these channels properly to their respective devices.

Here's an excerpt from TIs official feature list:

* Four Audio Digital-to-Analog Converter (DAC) Channels
* Stereo Capless Headphone Drivers
* Stereo 8 Ω, 1.5 W per Channel Speaker Drivers
* Differential Earpiece Driver
* Stereo Line-Out

Yes, it has four DACs - but the feature clearly says "Stereo Speaker",
"Stereo Line Out" and "Stereo Headphone Drivers"-

It does not say "Four channel analog output", even though it would be
correct for the hardware level, but the typical use case is Stereo out.

And even in the block diagram of the TWL6040, the output lines are
marked with L and R (HSL and HSR as well as HFL and HFR).

So it's pretty clear that the chip has been designed to provide Strero
Output and not 4-Channel output.

The job of the driver should be to take care of the proper routing and
provide proper output devices for ALSA.

Well, and that would be stereo channel devices, not one device with
four channels.

If the driver does that, it's either incomplete or has a bug, but it's
not following the meant usecase or feature list of the chip.

> > So why should the speakers be channel 3 and 4? 
> Because data is sent from the OMAP5 to the twl6040 in PCM packets
> over a single PCM interface.
> And as far as I know the PCM is hard formatted with 4 channels. The
> twl6040 takes this PCM stream, splits it up and sends it to the 2
> audio DACs for Headset and 2 for Handsfree speakers. This mapping
> can not be modified.

That would be very weird in my opinion. The communication stream
between the OMAP5 and TWL shouldn't affect that, as the driver is for
the TWL, and the TWL splits the stream up to single DACs.

It's no different when using a USB soundcard: The PC provides all
channels in one stream, but there are USB soundcards with multiple
output devices, and the driver manages this as well.

> And the twl4030 drivers simply maps that to Linux user space as a
> single sound card with 4 channels. No other magic behind.

Then the TWL drivers wouldn't be doing their job and they wouldn't
follow the use case of the chip.

> The tables you find in the code define the amixer controls and
> handsfree is for gain/loudness control. But there is none to change
> the channel mapping because the twl6040 driver can't do that (without
> ABE extensions and AESS).

Well, I know from my own experiments with ALSA that you can even
reroute streams directly in ALSA.

You can, for example, use two stereo outputs and create one
multichannel device. You can then play 4-channel audio files and they
will be properly mapped to the two stereo outputs.

You can also completely rewire multichannel outputs, double channels or
remap them and create virtual output devices - all without changing the
driver, just with soft remapping.

So why shouldn't it be possible to remap them here and create proper
devices in ALSA?

I don't care whether this is being done within the driver or by using a
specific ALSA setup, but the user should simply have working audio
output :)

> I just took some minutes (well more) and installed letux-4.19.44 on
> the 2GB Pyra.
> And for me, sound works!
> Well, not optimal , but it works. When playing an MP3 I get noise
> after ca. 10 seconds. But before that, music is crisp and loud and
> volumed damon works as expected. This was better with some older
> kernel, so it is a pure software issue.

So.. sound is mapped to a proper device or channel 1 and 2?

> So it is "just" the idle/clock bug to be fixed. And not a fundamental
> issue like you seem to believe. Of course such a simple idle/clock
> bug may need a lot of time to identify and fix. 
> Or there is something in PyraOS which interfere
>  with this basic setup and makes it non-operating.

Well, yes. PulseAudio locks up because of the broken devices :D

Mit freundlichen Grüßen,

Michael Mrozek

OpenPandora GmbH
Geschäftsführer: Michael Mrozek

Schäffbräustr. 11
85049 Ingolstadt
Tel.: 0841 / 990 5548
HRB 4879, Amtsgericht Ingolstadt
eMail: mrozek at openpandora.org

More information about the Letux-kernel mailing list