Electronic – arduino – Why won’t the arduino board read an analog pin correctly

Yes, this is possible. See this AVR-as-RFID project for an example, which explains:

The coil actually powers the AVR through two of its I/O pins. Nearly every chip out there has clamping diodes on its I/O pins, which prevent voltages on that pin from rising above the chip’s supply voltage or sinking below ground. These diodes are useful for arresting static discharge.When you first hold the RFID tag up to a reader, the chip has no power- the supply voltage is zero. When the coil starts to pick up power from the RFID reader, these two I/O pins are presented with a sine wave, a few volts in amplitude. Anywhere that sine wave exceeds the supply voltage, some energy is diverted from the coil to the chip’s supply rails, via the clamping diode. The end result is that the chip is powered, and the coil’s sine wave is truncated. The top and bottom of the sine have been chopped off, and it looks a lot more like a square wave now.

So the clamping diodes, intended to protect your AVR from overvoltage, are conducting current from the input pin to the supply rail, powering the rest of the AVR.

This will most certainly add delays as you are polling the pin in a blocking loop

while (digitalRead(RCpin) == LOW) { // count how long it takes to rise up to HIGH
reading++;      // increment to keep track of time 

if (reading == 30000) {
  // if we got this far, the resistance is so high
  // its likely that nothing is connected! 
  break;           // leave the loop
}

Assuming that your compiler can optimize the code extremely efficiently this loop would take something like 4 lines of code to execute since you have to read the pin, then compare it to a value, then branch based on the outcome (I would be very impressed if you could get this few instructions). Further assume that each one of those instructions takes only 1 clock cycle to execute (this is also probably going to take more, but it helps to bound the problem). This routine could take at most:

\$MaxRoutineTime = LoopIterations \times \frac{Instructions}{LoopIteration} \times \frac{Seconds}{Instructions}\$

\$MaxRoutineTime = 30,000 \space Iterations\times \frac{4 \space Instructions} {LoopIteration} \times \frac{Seconds}{8,000,000 \space Instructions}\$

\$MaxRoutineTime = 15 \space mS\$

but I assume it will take a little more than that because of the aforementioned allowances.

The reason it does not add delays when using an ADC is because the peripheral can be setup to generate interrupts and you will only be notified when the ADC reading is complete. The time it takes the ADC to complete a measurement is a finite number of clock cycles, so the app note you're referencing is pointing out that if you slow your clock speed, though the ADC will still take the same number of clock cycles to complete a measurement, your measurement will take longer because the clock is slower.

Edit

At first glance from your picture, combined with the fact that you mentioned audio, I thought you were measuring a microphone input. However, it appears that you're just using a Force Sensitive Resistor (FSR) which is just a pressure sensor. If you don't need to know the amount of pressure, only that it was pushed, you don't have to go through all the trouble of finding the exact reading. You can simply use any interrupt-generating, digital input if you pick the correct resistor value (in place of the capacitor). You will simply set a digital pin to generate interrupts on rising edges and pick a resistor that will give you a state change (low/high) with the desired amount of force for your touch. Then you'll know each time the FSR was pushed and can handle it in an un-blocking fashioner, introducing the least latency possible.