DAC the conference and DAC the integrated circuit or IP block should both be pronounced "dack." The meaning will be clear from the context -- "Did you go to that awesome DAC party?" would never be confused with "this DAC doesn't have enough resolution to meet my requirements." :)
Where I work we already had trouble to fit Bluetooth messages that include the word Bluetooth in some of our infotainment products, and have used BT to abbreviate Bluetooth (for example BT Device connected) adding Smart would make those phrases even worse to fit! Replace T for S in our BT? No way!. For those I'd prefer the BLE abbreviation.
@Junko: I, for one, believe that BTSmart has a place and can be the energy-efficient alternative to WiFi in some applications -like the example I quoted elsewhere on Vehicular Area Network applications (I hate to use Smart Cars!) where movig vehicles can tag a stationary beacon for traffic management purposes. This can be done efficiently by BTSmart as it can do so with control plane alone whereas WiFi has to do both control and data planes.
@Frank: I agree with your observations... tacking on an IPv6 stack so Bluetooth can finally establish itself in personal area networks & elsewhere could have been described by other buzzwords by the marketing folks! BluetoothSmart implies the previous incarnations were dumber!
@betajet: I have come across many that use DAC for design automation conference, particularly those in the EDA companies. I am guilty of doing the same though I am fully aware of the long-held claim to this abbreviation by the digital-to-analog crowd!
Junko, I also get frustrated with marketing speak that I don't understand. In my brief investigation of this Bluetooth Smart, I see mainly three changes:
1. Low power, of course. They do this by not requiring a constant transmission, but rather pulsed.
2. Also low data rate. Apparently, usually no more than 64 Kb/s, and sometimes only bits per day.
3. A single profile. This is very important. In Bluetooth Classic, so-called, any new device that wanted to be connectable via Bluetooth had to have its profile entered into the spec. So that when the device comes online, Bluetooth will recognize it and know what comms it is expecting. If this can always be consistent, you're better off. New devices can be connected immediately.
I'm not sure how #3 will keep from becoming a restriction, eventually, unless what this really means is that the profiles are handled always at the application layer.
I should add, by my understanding of what constitutes "smart" devices, this actually make Bluetooth Smart dumber than the Classic. It's slower and it knows less about the connected devices, than Bluetooth Classic.