On Fri, Mar 13, 2009 at 12:19 AM, Ang Way Chuang <wcang@xxxxxxxx> wrote: > > Yes, please :) Yeah, Michael Krufky and I were discussing it in more detail yesterday on the #linuxtv ML. Essentially there are a few issues: 1. Getting everyone to agree on the definition of "SNR", and what units to represent it in. It seems like everybody I have talked to has no issue with doing in 0.1 dB increments, so for example an SNR of 25.3 would be presented as 0x00FD. 2. Getting everyone to agree on the definition of "Strength". Is this the field strength? Is this some coefficient of the SNR compared to an arbitrary scale? Is it a percentage? If it's a percentage, is it 0-100 or 0-65535? 3. Deciding on what return codes to use for "device does not support SNR info", "device cannot provide SNR currently" (such as occurs for some devices if there is no lock). Right now, devices return zero if not supported, and it would be good for apps to know the difference between "no signal" and the various reasons a chip cannot provide the information. 4. Converting all the drivers to use the same representation. How difficult this is varies by chip, since for some chips we know exactly how SNR is represented and for some chips it is completely reverse engineered. After the discussion I had yesterday, I have some renewed energy for this. My plan is to put together a formal definition of the two API calls (SNR and Strength) and solicit comments. If I get some agreement, I will start converting all the ATSC devices to support the API (and submit patches to Kaffeine). Devin -- Devin J. Heitmueller http://www.devinheitmueller.com AIM: devinheitmueller -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
