Hi,
as most here probably know, the Pyra is missing one hardware workaround (OMAP5 Errata 3.5 McPDM Downlink Data Corrupted With TWL604x) which is an inverter on the PCB.
The result is, that the audio stream of the Pyra audio can crash and outputs a loud noise instead of audio (which is pretty bad when you're using headphones, as the noise comes with full volume...)
Once it's in that state, it seems the only way to get it back into normal state is to stop the audio stream completely and restart it.
By removing a resistor on the PCB (which wasn't needed anymore), we managed to get it to work mostly stable - but according to some users, it still happens sometimes (but still too often). It seems to happen more often when the volume is above a certain level and when the CPU is pretty busy.
Based on tests by daveshah, it never seems to happen when the microphone uplink is disabled - but I have no idea how to actually do this for testing (is it enough to disable the microphone in ALSAMixer or do we need some special commands to disable the uplink?)
The reason I want to do more thorough tests now is because I need to start producing the next batch of CPU boards now.
We still have around 300 unpopulated ones. Throwing these away and creating new ones which have the inverter installed would cost roughly 20000 EUR, so pretty costly and I'd like to avoid that if it's not necessary.
However, if we cannot get audio to work reliably (even with the microphone off), then I'd need to replace 500 fully populated CPU boards - which would cost around 100k EUR... so even worse.
As we now have Pyras in the wild and a few users where this is happening every now and then, it's the perfect time to try some ideas and test stuff.
So can someone help me with:
* How do I switch off the microphone uplink for further testing? * Does anyone know if it's possible to add some detection into the driver? So that the driver stops and restarts the stream once it detects corrupted downlink data? That would switch off audio for a short time, but that would be better than the noise we're hearing
Any other ideas? Thanks for your help :)
Am 24.02.2021 um 19:50 schrieb Michael Mrozek EvilDragon@openpandora.org:
Hi,
as most here probably know, the Pyra is missing one hardware workaround (OMAP5 Errata 3.5 McPDM Downlink Data Corrupted With TWL604x) which is an inverter on the PCB.
The result is, that the audio stream of the Pyra audio can crash and outputs a loud noise instead of audio (which is pretty bad when you're using headphones, as the noise comes with full volume...)
Once it's in that state, it seems the only way to get it back into normal state is to stop the audio stream completely and restart it.
By removing a resistor on the PCB (which wasn't needed anymore), we managed to get it to work mostly stable - but according to some users, it still happens sometimes (but still too often). It seems to happen more often when the volume is above a certain level and when the CPU is pretty busy.
Based on tests by daveshah, it never seems to happen when the microphone uplink is disabled - but I have no idea how to actually do this for testing (is it enough to disable the microphone in ALSAMixer or do we need some special commands to disable the uplink?)
The reason I want to do more thorough tests now is because I need to start producing the next batch of CPU boards now.
We still have around 300 unpopulated ones. Throwing these away and creating new ones which have the inverter installed would cost roughly 20000 EUR, so pretty costly and I'd like to avoid that if it's not necessary.
However, if we cannot get audio to work reliably (even with the microphone off), then I'd need to replace 500 fully populated CPU boards - which would cost around 100k EUR... so even worse.
As we now have Pyras in the wild and a few users where this is happening every now and then, it's the perfect time to try some ideas and test stuff.
So can someone help me with:
- How do I switch off the microphone uplink for further testing?
- Does anyone know if it's possible to add some detection into the
driver? So that the driver stops and restarts the stream once it detects corrupted downlink data? That would switch off audio for a short time, but that would be better than the noise we're hearing
That is an interesting idea. Basically it is the McPDM link between OMAP5 and TWL6040. The driver is
https://elixir.bootlin.com/linux/latest/source/sound/soc/ti/omap-mcpdm.c
So I think this is the place to disable the uplink. And to check for stream failure and try a restart.
I have checked and we use this upstream driver untouched.
Any other ideas? Thanks for your help :)
-- Greetings,
Michael Mrozek
OpenPandora GmbH CEO: Michael Mrozek
Schäffbräustr. 11 85049 Ingolstadt Germany Tel.: +49 841 990 5548 http://www.openpandora.de/ HRB 4879, Amtsgericht Ingolstadt
eMail: mrozek@openpandora.org
Kernel mailing list Kernel@pyra-handheld.com http://pyra-handheld.com/cgi-bin/mailman/listinfo/kernel