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