It depends on many details symmetric/assymetric, cipher, mode of operation, scenario of encryption, types of attacks you want to defend). I'll try to cover the most common scenarios:
One usually don't use encryption alone. It often needs to be used together with authentication. The task of the authentication is to detect unauthorized modification. So, when decrypting, you need to perform error correction before you verify if the message has not been altered. In such case, you can use any error code correction you want. Encrypted data will look usually as a random data. (It has to look as some random data if encryption is secure and it does not inflate the data much.) Remember, you have to properly recover all the data. If you don't, you can't securely recover anything.
For symmetric encryption, the process will likely be encrypt-then-authenticate-then-use-ECC. For asymmetric, it gets a bit more tricky, but using ECC will be the last step.
In rare cases, you don't need authentication. That is, you assume that attacker cannot modify the data. This might be OK for data at rest, but probably not for data in transit. This might allow you to apply error correction codes before applying encryption (under some circumstances), but this seems to be a tricky area with high likelihood of mistakes. And I don't see any advantages of this approach.
Notes for secure voice:
First, I suggest finding an existing protocol+implementation and wrapping it in error correction (if not already contained). This can prevent many design and implementation hassles. There are some protocols (IIRC: ZRTP and SRTP, or DTLS if you prefer lower level). I don't know them in detail and I have no idea if they fit your needs, but it is IMHO worth checking.
If this is not possible, you have to properly manage mode of operation, IVs, replay attacks and so on.
On authentication: I know two kinds of attacks that can arise from missing authentication:
a. Modification of the data by attacker.
b. Error-based side channels.
While I admit that some attacks might be hard in your case, I would not dare to consider them as impossible. Such design looks fragile. Some seemingly innocent modification can break previously secure protocol. Moreover, some factors that can make harder attacks (a) makes easier attacks (b) and vice versa:
- Stream ciphers (and stream modes of operation) can mitigate some error-based side channels, but they make it easier to modify the plaintext.
- Ironically, ability to predictably modify the plaintext introduces a different kind of side channels.
- Uncompressed PCM audio is easy to modify (if it is not authenticated) and read using (if you use crypto in some wrong ways, e.g., IV reuse) xor attacks on stream ciphers. On the other hand, compressed audio without authentication might introduce some error-based side channels (that uncompressed audio would survive).
In short, proper authentication makes whole threat model much easier.
If you are scared about some details, it might be actually a good reason to consider existing protocols over a custom solution.