I have an application requirement where certain audio settings need to be made at the hardware level rather than the session level. I have been able to hit most of the areas in question using a third party API. However, a new requirement has come up and I'm having trouble accessing the setting.
We are primarily on Win7 systems though Win10 is not out of scope. We need to be able to disable Line-In as it appears to be causing some interference with the later run session recordings that are made.
Our working environment includes multiple systems/locations. The application that handles recordings is specialized and cannot be changed for something like a base setting. Also, with newer systems the line-in and rear microphone are a combined plug and, when used, the OS asks which way you want to use it.
I realize that changing audio settings and the hardware level can be problematic but any help or suggestions would be greatly appreciated as this project needs to completed as quickly as possible.
Related
Basically, i'm trying to figure out if you can add a software to run alongside an already installed POSs, that can also access the barcode scanner?
Does it depend on whom the POSs has been installed with?
Please help!
I'm pretty new in this area, but I know that UPOS has the concept of Sharable Devices, multiple apps can use the device in this case.
Some devices are sharable devices. An example is the keylock. A sharable device allows multiple Control instances to call its methods and access its properties. Also, it may deliver its events to multiple Controls. A sharable device may still limit access to some methods or properties to the Control that has claimed it, or it may deliver some events only to the Control that has claimed it.
https://www.omg.org/retail/unified-pos.htm
#Rachel McConnell,
It is certainly possible for two applications to use the barcode scanner if neither application holds an exclusive claim on the device when it is not actively using the hardware, however many POS applications assume they are the only application using the hardware.
If both applications are using Windows.Devices.PointofService, there is a negotiation process built into the platform that requires the application with an active claim to respond with a retain() to keep the claim if a second application requests a claim. If the first application does not respond with a retain() in a matter of seconds, the claim is revoked and given to the second application. I do not believe other UnifiedPOS implementations provide similar capabilities.
For more information, see: https://learn.microsoft.com/en-us/windows/uwp/devices-sensors/pos-basics-claim
Hope this helps
Terry Warwick, Microsoft
I understand that in Linux a windowing system (X11, Wayland etc.) is responsible for rendering applications on the screen. I experimented with X11 but never got past obtaining single windows. I also read about Wayland. My question is, if I want to write an application that grabs whatever is shown on the screen, is there a way to get it on such a low-level (drm, dri, kms) that I am not dependent on the windowing system? What choices do these low-level APIs give me compared to the windowing system?
EDIT: I realized reading this that "One of the features of Wayland is its security design, which helps to guard the user against malicious apps. Apps can no longer see everything on the screen and spy on you. But that also means you cannot run a common application (like shutter or gtk-recordmydesktop) and use it to make a screenshot or a screencast of your desktop".
is it possible to detect the color temperature settings of a monitor or display with css, javascript, html5, silverlight, java, flash, or anything that could be used on the web?
no problem if it's not working for all the cases, I am interested in everything.
if it is not possible right now at all, is there work in progress for this field (under what name)?
No, there isn't any way to detect this from web-based tools. In fact, there isn't really any way to detect this (in general) from a computer at all. You can change your monitor's settings all you like and your computer never knows the difference. It just sends the video signal down the cord and doesn't really care what the monitor does with it.
There is some information that goes back from the monitor to the computer, but in general color temperature is not included in that information.
However, some platforms that are more integrated, like many Apple products, may have a way to get this information from the system, but it would likely need to be a native application that has access to low-level system APIs, which most frameworks (especially web ones), including those you mentioned, tend not to have access to.
Is there a (open source or commercial) software solution available for the Linux platform to build a custom embedded navigation device? It should be able to display maps and do routing (just like a TomTom/Navigon/Garmin/... navi device).
Unfortunately all navigation solutions seem to target Windows CE only.
Something based on OpenStreeMap data is not an option, because the map data is IMHO not always good enough for serious routing / driving instructions.
Since I'm searching for a long time now without luck I'm not too restrictive on the implementation details, however it should be possible to extend the software with custom functions or ideally embed the navigation in my own software.
Android with Google Maps comes to my mind, but I'd like to avoid setting up Android for my device.
Alternatively, if there is no such solution, I might use a end-user navigation device if that allows me some kind of communication with my own device to control it.
I'm open for any suggestions, thanks..
There is a huge list here. Take a look if anything suites your needs.
I plan to develop a nice little application that will run on an arm-based embedded Linux platform; however, since that platform will be battery-powered, I'm searching for relevant information on how to handle power save.
It is kind of important to get decent battery time.
I think the Linux kernel implemented some support for this, but I can't find any documentation on this subject.
Any input on how to design my program and the system is welcome.
Any input on how the Linux kernel tries to solves this type of problem is also welcome.
Other questions:
How much does the program in user space need to do?
And do you need to modify the kernel?
What kernel system calls or APIs are good to know about?
Update:
It seems like the folks involved with the "Free Electrons" site have produced some nice presentations on this subject.
http://free-electrons.com/services/power-management/
http://free-electrons.com/docs/power
http://free-electrons.com/docs/optimizations
But maybe someone else has even more information on this subject?
Update:
It seems like Adam Shiemke's idea to go look at the MeeGo project may be the best tip so far.
It may be the best battery powered Embedded Linux project out there at this moment.
And Nokia is usually kind of good at this type of thing.
Update:
One has to be careful about Android since it has a "modified" Linux kernel in the bottom, and some of the things the folks at Google have done do not use baseline/normal Linux kernels. I think that some of their power management ideas could be troublesome to reuse for other projects.
I haven't actually done this, but I have experience with the two apart (Linux and embedded power management). There are two main Linux distributions that come to mind when thinking about power management, Android and MeeGo. MeeGo uses (as far as I can tell) an unmodified 2.6 kernel with some extras hanging on. I wasn't able to find a lot on exactly what their power management strategy is, although I suspect more will be coming out about it in the near future as the product approaches maturity.
There is much more information available on Android, however. They run a fairly heavily modified 2.6 kernel. You can see a good bit on the different strategies implemented in http://elinux.org/Android_Power_Management (as well as kernel drama). Some other links:
https://groups.google.com/group/android-kernel/browse_thread/thread/ee356c298276ad00/472613d15af746ea?lnk=raot&pli=1
http://www.ok-labs.com/blog/entry/context-switching-in-context/
I'm sure that you can find more links of this nature. Since both projects are open source, you can grab the kernel code, and probably get further information from people who actually know what they are talking about in forms and groups.
At the driver level, you need to make sure that your drivers can properly handle suspend and shut devices off that are not in use. Most devices aimed at the mobile market offer very fine-grained support to turn individual components off, and to tweak clock settings (remember, power is proportional to clock^2).
Hope this helps.
You can do quite a bit of power-saving without requiring any special support from the OS, assuming you are writing (or at least have the source code for) your application and drivers.
Your drivers need to be able to disable their associated devices and bring them back up without requiring a restart or introducing system instability. If your devices are connected to a PCI/PCIe bus, research which power states they support (D0 - D3) and what your driver needs to do to transition between these low-power modes. If you are selecting hardware devices to use, look for devices that adhere to the PCI Power Management Specification or have similar functionality (such as a sleep mode and a "wake up" interrupt signal).
When your device boots up, every device that has the ability to detect whether it is connected to anything needs to do so. If any ports or buses detect that they are not being used, power them down or put them to sleep. A port running at full power but sitting unused can waste more power than you might think it would. Depending on your particular hardware and use case, it might also be useful to have a background app that monitors device usage, identifies unused/idle resources, and acts appropriately (like a "screen saver" for your hardware).
Your application software should make sure to detect whether hardware devices are powered up before attempting to use them. If you need to access a device that might be placed in a low-power mode, your application needs to be able to handle a potentially lengthy delay in waiting for the device to wake up and respond. Your applications should also be considerate of a device's need to sleep. If you need to send a series of commands to a hardware device, try to buffer them up and send them out all at once instead of spacing them out and requiring multiple wakeup->send->sleep cycles.
Don't be afraid to under-clock your system components slightly. Besides saving power, this can help them run cooler (which requires less power for cooling). I have seen some designs that use a CPU that is more powerful than necessary by a decent margin, which is then under-clocked by as much as 40% (bringing the performance down to the original level but at a fraction of the power cost). Also, don't be afraid to spend power to save power. That is, don't be afraid to use CPU time monitoring hardware devices for opportunities to disable/hibernate them (even if it will cause your CPU to use a bit more power). Most of the time, this tradeoff results in a net power savings.
One of the most important things to think of as a power aware application developer is to avoid unnecessary timers. If possible use interrupt driven solutions instead of polled solutions. If a timer must be used then use as long poll interval as is possible.
For example if something special should be done at a certain room temperature it is unnecessary to check the temperature every 100 ms since temperature in a room changes slowly. A more reasonable polling interval is could be 60 s.
This affects the power consumption in several ways. In Linux the CPUIDLE subsystem takes the CPU (SOC) to as deep power saving state as possible depending on when it predicts the next wakeup to occur. Having a lot of timers in a system will fragment the sleep making it impossible to go to the deeper sleep states for longer periods. A typical deep sleep state for CPUIDLE turns the CPU off but keeps the RAM in self refresh. When a timer triggers the CPU will boot and serve the timer of the application.
It's not actually your topic, but it might come in handy to log your progress: i was looking for testing / measuring my embedded linux system. chris desjardins from this forum recommended me this:
I have successfully used bootchart in the past:
http://elinux.org/Bootchart
Here is a list of other things that may also help:
http://elinux.org/Boot_Time