About "Digital Audio":
Before 2013, most FM radio audio on Android phones was "mostly analog"*. FM audio bypassed the digital audio chain and was injected in the final stages, after the final D->A conversions.
FM audio was a special path that did not follow the same rules as every other source of audio on Android. Hundreds if times I've heard "... but it works fine with music players etc." and I explained how FM is different. Fm audio usually can not be equalized or modified with effects. It usually can not be recorded, visualized, or routed to BT headsets.
Besides lacking these digital audio features, "non-digital"** FM audio is difficult to do on AOSP ROMs. AOSP usually does not use the stock audio libraries that contain support for FM. This has been a never ending source of grief and work for me; I spend at least 50% of my development time on audio issues as a result.
Basically, Spirit will use SU/root low level functions to set up the audio hardware for FM, via kernel device driver commands for ALSA or earlier APIs. But the ROM audio library has no idea that FM is running. This can often result in conflicts that break audio, especially during audio notifications. On some popular older devices, such as HTC Desire HD, I had to create a hack that resets the entire audio system when FM is turned off. And users just have to live with the fact that audio notifications break audio, at least until FM is turned off or the device is rebooted.
There were many other problems, including a need to continuously loop a silent audio file, to convince the audio libraries that music was playing. Otherwise, volume control was lost, among other things.
This was rarely a problem on CM7 ROMs that included a CM FM app, because the audio libraries supported FM. But most CM9 ICS and later ROMs dropped support for FM. I considered making code contributions to CM and other ROMs to fix this problem the proper way, in the audio libraries. But I concluded this would take all of my time, may create personal conflicts and might never cover the majority of ROMs anyway.
*"Mostly" analog: Surprisingly, just about every FM chip does internal signal processing digitally, after the initial A->D conversions, Frustratingly, virtually every 2012- phone did not use digital outputs, where they existed, but converted the Digital left and right audio back to analog.
"Non-digital"**: I do not use this term to strictly mean "Analog". I use it to mean a method to enable FM audio that stock OEM FM apps use, and that Spirit1 uses, when not using one of the "Digital..." Audio-> Method settings. At the chip level, the audio may be digital, as is the case when using Qualcomm FM/combo chips with Qualcomm WCD9310 or compatible audio chips.
Spirit's Digital Audio Solution:
A digital solution to most of these problems was envisioned in late 2012, and resulted in the 1st prototype alpha releases of Spirit2 in early 2013. Spirit2 was digital only and this proved to be a much easier way to do FM audio, with few problems. When it became clear how much more work was needed to complete Spirit2, and given that Spirit1 continued to sell well enough to live, digital audio was "back ported" to Spirit1.
Here's how it works: Instead of just sending a few commands to the audio drivers, Digital audio mode sends different commands to enable digital, then continuously reads the ALSA PCM channel. All audio data read is then written to the Android Audiotrack API, the same as most streaming apps do. A streaming app reads from the network; but Spirit reads from the FM/audio chip.
The main disadvantage of this digital audio method is higher CPU and battery consumption. OTOH, "non-digital" audio on most AOSP ROMs required a constantly looping silent audio file anyway, so the difference is minimized.
Another digital disadvantage is that some devices can experience brief audio drop-outs. This does not affect Samsung devices. Full and partial workarounds include modifying CPU frequency or kernel scheduler. Tuning and investigative work is ongoing.
There are also challenges for speaker mode. The current support is experimental and does not work on all devices. But the current code is much cleaner and much more robust than Spirit1 non-digital audio, which can have issues during phone call interruptions. Volume control can also be unusual over speaker. The reason for these problems is that Android is designed to switch to speaker only when the wired headset is unplugged. But FM is unique: the wired headset is used for the antenna. A workaround for motion-less devices: remove the wired headset plug just enough to switch to speaker, but not enough to lose the antenna affect.
But the advantages of this form of digital audio are HUGE, IMO. They have allowed me to provide all the audio features people had been asking for: recording, equalization, effects, A2DP BT headset and visualizers.
AND it allowed me to minimize the MANY FM specific audio problems with much smaller, better designed and better written code, with a minimum of special cases. The Spirit1 audio (and other) code is a huge mess and can never be re-written IMO.
Audio dropouts on non-Samsung devices made me consider non-digital audio methods in Spirit2, despite the work and complications that would create. But a variety of fixes and re-tuning has improved audio, workarounds have been identified and work is ongoing.
The advantages of digital only are too great IMO to "pollute" Spirit2 code with non-digital audio. I've even removed previous non-official support for stock Sony devices in order to concentrate on digital audio that is as flawless as possible.
Samsung devices only rarely have audio drop-outs. I've only seen this on the oldest, now "vintage" original Galaxy S GT-I9000, and only when recording, at the same time that the equalizer, effects and the visualizer are all running. The old single core CPU gets close enough to it's processing limit that very occasional ticks may be heard, but the recording is usually fine.
LG G2 and Moto G are working pretty well now. The worst affected are the HTC One and the HTC OneXL/S/Evo 4G LTE, or other Qualcomm FM+audio devices. Further tuning and investigation is ongoing, but these things can minimize the problem:
- Don't record.
- Turn screen off.
- Disable visualizers or any other app or service that might be using CPU resources.
- Disable equalizer or other audio effects. Bass-boost and EQ alone don't seem too bad.
- Raise CPU minimum and/or maximum frequency (Only if you understand the risks of CPU burnout.)
- Change CPU scheduler: Performance risks CPU failure; Interactive or Pegasusq may be better.