juj / fbcp-ili9341

A blazing fast display driver for SPI-based LCD displays for Raspberry Pi A, B, 2, 3, 4 and Zero
MIT License
1.61k stars 268 forks source link

I2S Audio Controllers over GPIO? #22

Closed jpete24 closed 6 years ago

jpete24 commented 6 years ago

I'm trying to build a device that uses I2S audio, however the software side of this requires that we use a dtoverlay to accomplish the driver loadout for the DAC. Do you have any suggestions for how to get around this as whenever I try to run this on a Retropie, it loads up to the main Retropie menu, but crashes when trying to load up the emulator and the sound fires up.

Scroll down to "Add Device Tree overlay" https://learn.adafruit.com/adafruit-i2s-stereo-decoder-uda1334a/raspberry-pi-usage

dtoverlay=hifiberry-dac dtoverlay=i2s-mmap

Any thoughts on how we could incorporate this?

juj commented 6 years ago

Try checking out if this might be a DMA channel conflict. That is, build with -DUSE_DMA_TRANSFERS=OFF CMake option and see if that avoids the conflict. fbcp-ili9341 does not use I2S so from that perspective the coast should be clear.

jpete24 commented 6 years ago

I’m using a Pi Zero W though. Won’t that cause issues because it is a single core processor? I’ll give it a shot tonight and see if that makes a difference though.

jpete24 commented 6 years ago

Tried turning off DMA transfers...still didn't work. It seems to be only when the device tree overlay triggers the I2S hifiberry-dac command and wants to output audio, then it seems to turn off. It seems to be explicitly an issue with using "dtoverlay" as it only happens when I have that active to use the hifiberry-dac.

juj commented 6 years ago

Disabling DMA is just for troubleshooting problem to source, though certainly not to run by default on the Pi Zero.

I don't know what the dtoverlay might be doing that would conflict. One way to try to observe its operation is to run with the dtoverlays, but with fbcp-ili9341 disabled, and then in console, type

watch -n 0.1 gpio -g readall

and run content that utilizes the I2S audio at where it would be crashing, and try to observe if there are some specific GPIO pins that are toggling at the time. Perhaps that can help identify which GPIO pins it is using.

Do you have any suggestions for how to get around this as whenever I try to run this on a Retropie, it loads up to the main Retropie menu, but crashes when trying to load up the emulator and the sound fires up.

What exactly crashes when this happens? The game emulator, Retropie menu, fbcp-ili9341, the dtoverlay, linux kernel or the whole Pi?

jpete24 commented 6 years ago

Nothing crashes, its like flipping a switch between the audio working and the screen going black, and then once the audio is done playing, the screen comes back. So for example, the screen will work fine when you’re in the retropie main menu, but it uses not audio. As soon as you load up an emulator that uses audio, the audio takes priority and works, but the screen goes black. Once you quit the emulator the audio is done, and the screen comes back.

I truly think it has something to do with the fact that the HiFiBerry uses device tree overlay to address loading the sound card, and fbcp-ILI9341 can’t be used with any dtoverlays.

jpete24 commented 6 years ago

Solved it. Quite the simple oversight. The I2S Amp requires pins #18, #19, and #21. If you look at the PiTFT pinout (https://pinout.xyz/pinout/pitft_plus_35) it also uses GPIO #18 for backlight. If you read the Adafruit description, there is a #18 trace that you can cut on the back of the screen that doesn't ground out the pinout everytime you use it (https://learn.adafruit.com/assets/32029). By cutting this trace, I was able to get the dtoverlay to work without any effect to the screen and fbcp-ili9341 seems to be working great, and audio is working perfect.

juj commented 6 years ago

Great to hear! Closing this as resolved.