It's that DA15 connector that's the audio port. You're right in that, "There is no serial access to the codec from the outside..." apparently, at least it's not universal any more, since my newest notebook doesn't have one, but all of my desktops, even the newer ones have it. Some people think it's just for joysticks, though.

and you go on," so what the #&!! does that have to do with serial comm of any kinds from a uC?"

Do you seriously believe that communicating with a PC is all that matters?

You go on,
"I have reread your last babble and what you, in fact state is

"The cellphone people made a mistake when they made thair interface PC compatible" WHAT TOTAL DRIVEL "

I can't claim credit for that remark.

The world's cellphone system is totally screwed up, ineffeicient, and unreliable. It drops more calls per second than the hard-wired system has since the advent of TDMA. It frequently drops syllables, and sometimes whole words and phrases. I hate 'em. I have one bought for me by one of my clients which is active only when he's willing to pay for it. There should be a HUGE fine, at least 10 years' gross pay, for using one in a moving automobile, since so many people can't do two things at once. We've had several noteable fatal car crashes because people were jibberjabbering when they should have been driving, not to mention text-messaging while driving. Now, (getting back down from soapbox) I don't know who made that remark, but I wasn't aware that PC compatibility was a desirable feature for cellphone users. Most of 'em can't spell, so I figure most can't read and write either.

Clearly, you've never had to deal with sampled inputs. There's a whole class of processing tasks that requires you look at a signal, not as a single, individual bit, but as a bunch of them, sequentially, and use some software to process them. It's much more precise, and much easier, if you sample at a multiple of the rate at which these bits are generated. Some digital tape drives, for example, planted their data on tape at 48 kHz. That's 48 microseconds per bit. If you sample that data at a 48 microsecond rate, that's six bytes per bit if you use mode 0 with a 12 MHz oscillator, you can detect speed variations in the tape and make appropriate corrections to ensure you stay in sync, and, ultimately read and record the data on some more convenient medium for later interpretation. Having recorded it, you can set about to interpret it on a PC or wherever you want. Lots of court records around the country are kept on such media, for which the original recording devices have long perished. From time to time those are even important enough to have to be retrieved.

Likewise, medical data are often found to be stored on devices no longer available for any number of reasons, including, as I once pointed out, hard-sectored floppy diskettes. I don't see how a cellphone can help, except if you use it to call someone who knows how to do that sort of thing. I suspect he'll have more luck with Mode-0 than with the async modes. Whether the data is sampled via a Mode-0 serial channel or whether it's bit-banged is up to the designer, but he has a bandwidth budget. If Mode-0 saves on processing bandwidth over bit-banging, then I think it's the mode of choice.

I've never said Mode-0 was any better than the other modes, but it's clear that it will do things the others won't, just as the other modes will do things that Mode-0 won't. However, if you have a task that fits together with a system clock rate that isn't divisible from 11.0592, then I think you should be free to use that rate, particularly if you don't use async communication. What's more, I think you should be free to use another rate if you do require async comm's and can derive the appropriate baud clock from T2. T1 still works ... and you can trade that off against an external UART+BRG or making some other arrangement to ensure suitable timing for your system.

RE