A simple mod maybe, for the person designing a revised R-PI PCB yes it might be, but impossible to mod on the current board. The pins (balls) underneath the SoC that carry the I2S signals were not routed out from the ball grid array on the current boards.
Okay, I wanted to confirm this, so I actually checked the schematics and datasheet.
I2S is available on GPIO 18-21 or 28-31. GPIO19 and 20 aren"t broken out of the BGA, so they"re a no go. However, all of GPIO 28-31 is brought out, with each pin attached to a voltage divider that seems to have no current purpose (I guess it"s to detect board versions). If the resistors (R3-R10) were removed and the pads tapped, you could have I2S.
So yes, a fairly simple mod.
Yes, four GPIO's are used to auto detect the revision version, as is indicated in the schematic, (sheet to, location 7D) with 10K resistors either mounted or unmounted the pins are either pulled low or high, giving a four bit condition that can be read, with currently only two of the sixteen possible combinations used, one (code ''0'') for the model A and the other (code ''1'') for the model B, with codes ''2'' to ''F'' reserved for future use.
more about the GPIO uses can be found here:
Probably the kernel code reads these resistors, and when it reads something it does not expect it might crash, or misfunction. But it might be that it only reads the model code at boot time, and after that you can program the four pins as a I2S port. If you are unlucky though it might try to read the code each time it want to establish ethernet connectivity or use USB connectivity, to see if its supported on board. So you probably have to leave the resistors in place for the model code readout, and for pins that are reprogrammed as outputs (bit clock and word clock, output data) that isn't a problem, but at least one of the I/O lines (the input data line) might try to put something on its GPIO pin which might disturb the model code. It remains to be seen how well this will work, perhaps depending also on the codex you want to attach to it (whether or not it will not disturb the model code readout at boot time).
Also, in the future its probable that this won''t be the pins that are used for I2S, but instead the two missing GPIO's (19 and 20) for the primary I2S port will be routed out to the pinheader, so as to also enabling a second SPI interface.
In that case this solution will not be compatible with a future "official" solution.