To be blunt, I personally would use a dot/bar driver IC designed for this purpose instead, like LM3914. There is even a helpful article at
LearningAboutElectronics, in which an LM3914 is used to display an input voltage (controlled by a potentiometer) between 0 and 5V.
All PIC18F25K80 output pins cannot source or sink enough current to light the LEDs directly. If you use only PORTB and PORTC (and maybe PORTA7 and PORTA6), you can drive the ten leds with under 20mA each, say at 15mA (=0.015A) each or so. (These would be pins 9-18 and 21-28 – so almost all! – on the 28-pin SSOP/SOIC/PDIP package; see the datasheet for other packages pinouts.) For each LED, you'd have a current-limiting resistor; for driving at 5V, 220 Ohm is a very typical choice. (Assuming a typical 2V forward drop in each LED, the current is (5V - 2V)/(220 Ohm) = 0.0136136A ≃ 14mA.)
Using 10 LEDs with 14mA each you source a maximum of 140mA. The PIC can source an absolute maximum of 200mA all pins combined, so the ten LEDs at 14mA each is already a bit much.
However, the LED driver ICs designed for this purpose have current-limited outputs, so they don't need any resistors at all. (Well, you'll need a small potentiometer, or two resistors, to set the current used for each LED, and some resistors and capacitors for the input.)
Of course, there are also LED driver shift registers, like STP16CPC26, which can drive up to 16 LEDs. Again, a small potentiometer (in voltage divider configuration), or two resistors, are used to set the current used for each LED. On the PIC, you use SPI (pin 11 for SCK and pin 13 for SDO, on the 28-pin SSOP/SOIC/PDIP package) – and you can chain more than one STP16CPC26 for more LEDs –, and two additional output pins (any GPIO pins will work): one for latch enable, and one for output disable, common to all STP16CPC26's. So, on the PIC, you only use four pins for any number of LEDs you want to drive. These work fine with 10-LED bargraphs, but you are not limited to "bars", you can control each LED individually.
To recap, I would personally just use an LM3914, probably with an RRIO opamp like OPA348 to amplify the signal to 0-5V range, a Schottky barrier diode with a very low forward voltage at low currents (say, BAT54 or CUS10S30) to clamp negative voltages to 0V via a resistor... maybe a second Schottky to clamp voltages over 5V to Vdd rail, too. Input would be capacitively coupled to the opamp, with the clamping diodes between the capacitor and the opamp, so it'd be quite robust for all kinds of audio inputs, I think.
Is there a specific reason you want to use a PIC18F25K80? Are you writing the code in C or directly in assembly?
If using the PIC is the key, then I'd use two STP16CPC26 and two 10-16 LED bar graphs (for stereo audio!). For the two audio inputs, I'd use the resistor-capacitor circuit I mentioned earlier to shift the input signal range to around 2V, two clamping diodes to limit the swing between 0V and Vdd, followed possibly by a OPA2348 or similar dual opamp to buffer the input voltage. (The ADC on the PIC wants less than 2.5k input impedance; the opamp has two inputs in unity gain configuration, providing a low impedance outputs for the PICs ADC.) The opamp may be overkill, as the ADC really does not need more than 5 useful bits (0-31). But I like overkill. The software would again find peaks (ADC minimum and maximum) in each chunk spanning about 0.001 to 0.003 seconds (1 to 3 ms) at say around 10000 samples/second sample rate. In each chunk, the difference between minimum and maximum is used to update the VU meter state. (I already talked about the details on that.)
(There are different visual ways for LED bar VU meters to work. Some are just a continuous bar, some have the peak LED decay slower (so that the bar often has a space and then a single LED); the bar can be centered instead of starting at the bottom or top; and so on. I guess this part would be fun to experiment with.)
So, can you use an STP16CPC26 or similar to drive the LED bar? Or do you need to drive individual LEDs from the PIC directly?
It is difficult to help you, because you provide so little information on your problem. You say what you want to achieve, but almost nothing about the limitations or requirements you have; this makes helping you difficult. I recommend you read Eric S. Raymonds
How To Ask Questions The Smart Way; there are several translations of it there, too. It has an emphasis on Open Source, but most of it applies to all sort of technical projects; it's a very useful guide. If you were to ask your questions in the way recommended in that guide, you'd probably get more answers than from just me; I'm just another hobbyist, and there are lots of experts here. The experts just don't have the time to try and guess what exactly you are asking, you see, that's why
how you ask a question matters.