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

[H. Nikolaus Schaller]

> Am 23.05.2019 um 22:28 schrieb Michael Mrozek <EvilDragon at openpandora.org>:
> 
> On Do, 2019-05-23 at 19:26 +0200, H. Nikolaus Schaller wrote:
> 
> Hi,
> 
>>> 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,

Ah, that is the missing bit of information!

I thought that it is completely broken and wondered because it works
for me with 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
> ALSA).
> 
>>> 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 :)

I am not sure if it can be implemented that way at all. Here, the system
architecture of OMAP + AESS + TWL + how the bluetooth chip is connected
dictates.

We have the same architecture in the GTA04 and so far nobody came up
with a solution like you expect.

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

I have no idea if and how that can be done.

> 
>> Because they are independent drivers sitting inactively around.
> 
> Then blacklisting them should be easy.

If ALSA supports blacklisting of sound cards?

> 
>>>> 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
> whatever.
> 
> 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.

Still, what is the difference? IMHO just wording.

> 
> 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.

Yes, I agree with you. It should be done differently.

But it does not seem that anyone has written such a different driver.

> 
>>> 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 original author probably did not know your opinion when he wrote it
more than 5 years ago...

> 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.

Yes, you are right in your analysis: They follow the interface of the chip and not the use case.

But that is the current state.

> 
>> 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?

That is something I do not know an answer since I have no experience
with ALSA rewiring, channel doubling etc.

> 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 :)

The question is how you deine "working audio output". It is working,
but not to your mental model of how it should be solved.

> 
>> 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?

Channel 1 2 3 4. That is all what you can get from any existing twl6040
driver. If you want something different, a new driver has to be written
from scratch.

If you look into the /root/twl script (it appears that you have not
done) it does:

AUDIODEV="hw:$NUM,0" play ${FORMAT:+-t} ${FORMAT:+$FORMAT} -v 0.98 $FILE $REMIX

with REMIX set to either

REMIX_MONO="remix 1 1 1 1"
REMIX_STEREO="remix 1 2 1 2"

Which means stereo is going to 1+3 and 2+4 and mono is going to 1+2+3+4.

> 
>> 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
> Deutschland
> Tel.: 0841 / 990 5548
> http://www.openpandora.de/
> HRB 4879, Amtsgericht Ingolstadt
> -----------------------
> eMail: mrozek at openpandora.org
>