Am 23.05.2019 um 22:28 schrieb Michael Mrozek EvilDragon@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@openpandora.org