i really need a way to route audio - with an arduino

The fundamental requirement of CCrooked was as above, using a servo etc would be fun and that's fair enough, but it's not the best way to do it.

As mentioned relays are the simplest and arguably the best way, special audio switching chips come equal first probably, but for a one-off home project just get a relay, write 5 lines of code and job done.

Use a latching relay and you don't even have to constantly hold the current with the Arduino pin.

Is it possible to remove the knob and do that function with the arduino?

Sure, remove the knob from the device and the Atmega328 from the Arduino. Then glue the 328 to the pot shaft, pins down so it's more comfortable to grasp.  

Sorry, couldn't resist.

As mentioned you could use a servo although it's very difficult to imagine why you would, unless you want to simulate those cool mixing decks where the manual controls move by themselves.

Neither the Arduino nor the LEDs need you to provide a regulated power supply, the Arduino because it has an on-board regulator, the LEDs because they don't really care as long as there is "enough" volts.

RS485 will do 75' easily depending on the bit rate and you have two wires for it. So you could multi-drop all the Arduinos and come up with a protocol, normally this would mean a master that polls the slaves. 485 should not be used in a star topology, it should be a bus with short "stubs" to each node. It also needs line termination.

LIN transceivers only need 1 wire and are rated at 40m but should do better. LIN is not balanced but still very noise immune.

I2C is not intended for long runs like that but I don't know much about it, with drivers and/or slower rates it would probably work.

Whatever you do, if the application is important you'll have to come up with a protocol to handle errors etc. That's the hard part.

Wireless has it's place but a wire is always more reliable and cheaper if you have access to run the lines.

Do the three wires have to carry power as well?

Assuming you are just playing for the moment, just solder a few wires to the header and poke them into the breadboard/Arduino connector.

I think that we all need to take baby steps before we can run

True, I'm re-learning how to run after a decade away from any serious embedded electronics.

Seems like an odd way to control LEDs from an Arduino.

Reckon, what's with the digital to analogue to digital? Do you happen to have a drawer full of 3914s and no shift registers?

It escapes me why uP companies don't put a decent Analog output on their chips.

Yeah, there must be a good reason, the Xmega chips have a DAC but that's the only one I can think of off hand.

I will be needing to use the ADC and PWM outputs, so if I need additional support components for those operations, I would appreciate any advice on that as well.

In general no special handling of any IO is required it you're just dicking around on a breadboard.

Inputs like ADCs will need the voltage reduced if > 5v.

Outputs will need buffering (say with a transistor) if driving something too heavy for the 328, ie > 20mA.

As far as I know it should run, but you will have to recreate the same "environment".

Have you got a crystal and decoupling caps? I think that's all that should be needed.

[serial in]

I could not find anyting concerning a serial input in the datasheet.

DSA and DSB are your serial inputs.

Does this chip support this function?

It better, it's a serial in shift register  

And if it does, when I connect it to Q7 not Q4, will it work?

Yep.

Note that this SR does not latch the data, so as you are shifting your bits in they will ripple through all the outputs, this is not normally desirable, your displays will flicker all over the place when you update. If you are updating regularly this may make the display unreadable.

The slaves will be hosting rfid readers on the serial receive line

If you you only need Rx for the rfids you could bit-bang that and use the UART for your comms to the master.

@vinhtvu2

Are you only wanting to have two Arduinos? You say different rooms but not how many Arduinos.

I ask because connecting the hardware is almost trivial, but if there's more than 2 Arduinos talking on the wire you will have software issues.

If the bus error persists however (e.g. a client pulls SDA low) communication may still not be possible

It's a totally different protocol but that's why some LIN transceivers force the Tx line to a recessive level after a certain amount of time, regardless of what the local uC is transmitting.