Why is Skype Using the Wrong Audio Device?

I’ve been trying to figure out what is causing my audio to whack out and go crackly intermittently. Now I’m hyper-sensitized to anything making pops and crackles on my late 2009 MacBook Pro 15” running Windows 7 x64 with Boot Camp 3.1.

One thing I noticed is that the pops seem to always start with the incoming IM noise emitted by Skype. Another thing I noticed was that the pop seemed to be first coming from my 24” Cinematic Display. To simplify the number of things going on, I disabled the Cinematic Display (aka "Apple USB audio device”) and “Digital Audio (S/PDIF)” playback audio devices in mmsys.cpl because I’m not using them. (I’ve gone many hours without any pops and crackles after disabling these two devices but I’m not ready to say the problem is solved.)

What I just noticed is that the incoming IM ping sound was coming very much from my right speaker and it was really loud. Then I realized it wasn’t coming from the right desktop speaker at all. It was coming from my laptop. All of my other sound is coming out of my Klipsch speakers via the “headphones” minijack. Nothing should be coming out of the laptop speakers which aren’t the current default playback device. It shouldn’t be doing that.

The Volume Mixer shows that Skype is the only thing using the built-in speakers. These screenshots were taken nearly simultaneously without making any system changes. I just changed the selected device in the Volume Mixer.

skype-using-interanleverything-else-using-default

All of the Skype incidental notifications are coming out of my laptop but voice calls are playing out of the configured default playback device, which is my desktop speakers. Very weird. This reminds me that when we first got the MacBooks it was just as Snow Leopard was released and we had the drivers in Boot Camp 3.0. Skype could not hear anything with the built-in microphone even though the built-in microphone was working as demonstrated by Sound Recorder.

I have a suspicion that Skype is doing something low-level and inadvisable with the audio devices.

For the record, according to Skype’s own settings dialogs, it should not be using the laptop built-in speakers.

skype-audio-config

Mystery Solved!

The notifications show up on whatever speaker is defined in Options | Audio Settings | Ringing. By default that is set to “Ring on all devices”. Changing it to Use selected speaker removes the weirdness of ringing coming out of the laptop speakers while using headphones.

Advertisement

Command Prompt and PowerShell Here with Console.exe

command-hereIn antediluvian turn of the century days, there was an Open Command Window Here PowerToy. When Vista was released, this functionality was baked in to the default Explorer shell. Hold {SHIFT} and right-click on a drive, directory or the background of a directory and you will have an “Open command window here” option in the resulting context menu. Although PowerShell is installed by default on Windows 7, there is no parallel “Open PowerShell window here” option, but it can be easily added.

“Open PowerShell window here”

Windows Registry Editor Version 5.00

[HKEY_CLASSES_ROOT\Directory\shell\powershell]
@="Open PowerShell window here"
"Extended"=""
[HKEY_CLASSES_ROOT\Directory\shell\powershell\command]
@="C:\\Windows\\system32\\WindowsPowerShell\\v1.0\\powershell.exe -NoExit -Command Set-Location -LiteralPath '%V'"

[HKEY_CLASSES_ROOT\Directory\Background\shell\powershell]
@="Open PowerShell window here"
"Extended"=""
[HKEY_CLASSES_ROOT\Directory\Background\shell\powershell\command]
@="C:\\Windows\\system32\\WindowsPowerShell\\v1.0\\powershell.exe -NoExit -Command Set-Location -LiteralPath '%V'"

[HKEY_CLASSES_ROOT\Drive\shell\powershell]
@="Open PowerShell window here"
"Extended"=""
[HKEY_CLASSES_ROOT\Drive\shell\powershell\command]
@="C:\\Windows\\system32\\WindowsPowerShell\\v1.0\\powershell.exe -NoExit -Command Set-Location -LiteralPath '%V'"

Use Console.exe Windows

If you use command-line a lot in Windows, you will appreciate the advantages of using console.sf.net as the terminal window. The “Open … window here” context menus can be tweaked to open the new command prompts in Console rather than vanilla Windows CSRSS console windows.

"Open command window here” with Console

Windows Registry Editor Version 5.00

[HKEY_CLASSES_ROOT\Directory\shell\cmd]
@="@shell32.dll,-8506"
"Extended"=""
"NoWorkingDirectory"=""
[HKEY_CLASSES_ROOT\Directory\shell\cmd\command]
@="\"C:\\Program Files\\Console2\\Console.exe\" -r cmd.exe -d \"%V\" -w \"Command Prompt\""

[HKEY_CLASSES_ROOT\Directory\Background\shell\cmd]
@="@shell32.dll,-8506"
"Extended"=""
"NoWorkingDirectory"=""
[HKEY_CLASSES_ROOT\Directory\Background\shell\cmd\command]
@="\"C:\\Program Files\\Console2\\Console.exe\" -r cmd.exe -d \"%V\" -w \"Command Prompt\""

[HKEY_CLASSES_ROOT\Drive\shell\cmd]
@="@shell32.dll,-8506"
"Extended"=""
"NoWorkingDirectory"=""
[HKEY_CLASSES_ROOT\Drive\shell\cmd\command]
@="\"C:\\Program Files\\Console2\\Console.exe\" -r cmd.exe -d \"%V\" -w \"Command Prompt\""

“Open PowerShell window here” with Console

 

Windows Registry Editor Version 5.00

[HKEY_CLASSES_ROOT\Directory\shell\powershell]
@="Open PowerShell window here"
"Extended"=""
[HKEY_CLASSES_ROOT\Directory\shell\powershell\command]
@="\"C:\\Program Files\\Console2\\Console.exe\" -r C:\\Windows\\system32\\WindowsPowerShell\\v1.0\\powershell.exe -d \"%V\""

[HKEY_CLASSES_ROOT\Directory\Background\shell\powershell]
@="Open PowerShell window here"
"Extended"=""
[HKEY_CLASSES_ROOT\Directory\Background\shell\powershell\command]
@="\"C:\\Program Files\\Console2\\Console.exe\" -r C:\\Windows\\system32\\WindowsPowerShell\\v1.0\\powershell.exe -d \"%V\""

[HKEY_CLASSES_ROOT\Drive\shell\powershell]
@="Open PowerShell window here"
"Extended"=""
[HKEY_CLASSES_ROOT\Drive\shell\powershell\command]
@="\"C:\\Program Files\\Console2\\Console.exe\" -r C:\\Windows\\system32\\WindowsPowerShell\\v1.0\\powershell.exe -d \"%V\""

 

 

Restore Defaults

For PowerShell, remove the powershell keys from beneath HKCR\Directory\shell, HKCR\Directory\Background\shell and HKCR\Drive\shell.

“Open command window here” restore default

Windows Registry Editor Version 5.00

[HKEY_CLASSES_ROOT\Directory\shell\cmd]
@="@shell32.dll,-8506"
"Extended"=""
"NoWorkingDirectory"=""
[HKEY_CLASSES_ROOT\Directory\shell\cmd\command]
@="cmd.exe /s /k pushd \"%V\""

[HKEY_CLASSES_ROOT\Directory\Background\shell\cmd]
@="@shell32.dll,-8506"
"Extended"=""
"NoWorkingDirectory"=""
[HKEY_CLASSES_ROOT\Directory\Background\shell\cmd\command]
@="cmd.exe /s /k pushd \"%V\""

[HKEY_CLASSES_ROOT\Drive\shell\cmd]
@="@shell32.dll,-8506"
"Extended"=""
"NoWorkingDirectory"=""
[HKEY_CLASSES_ROOT\Drive\shell\cmd\command]
@="cmd.exe /s /k pushd \"%V\""

Boot Camp: Dated Broadcom Driver Causes Audio Pops and Crackles

broadcom-disable-802-11aI have had a problem with my MacBook Pro having intermittent crackles and pops in the audio in my late 2009 Macbook Pro Unibody. I previously suspected the Cirrus Audio driver.  Restarting “Windows Audio” (aka audiosrv) fixes the problem. The pattern is that everything is fine on boot. The crackles and pops start after resuming from sleep.

I just came across this post which indicates the problem is actually caused somehow by the the 802.11a feature of the Broadcom wireless network adapter. Somewhat incredulously, I gave this a try and it works so far.

It also seems that although, Apple has not seen fit to send out an update, Broadcom has published several newer versions of their 943XX driver. These are available from other OEMs using Broadcom chips (Acer, Dell and HP) that actually provide updates for Windows drivers on a regular basis. HP helpfully offers a version of the Broadcom Wireless driver that is almost a year newer than the one in Boot Camp 3.1. The revision history of here shows notes a series of performance enhancements over the Apple-distributed version 5.60.18.8.

Update

Some good folks have taken it upon themselves to scrape together Broadcom wireless driver downloads posted by various OEMs. Note that sometimes the stuff in the forums is newer than what is listed in the pinned initial post. At the time of this writing, the latest available is 5.100.249.2 from Acer.

Update 2

I’m still getting the intermittent pops and crackles. Perhaps I have unfairly maligned the Broadcom driver based on random info from the interwebs. I just realized that the speakers on my Cinematic Display are running at the same time as my nice speakers on the mini-jack. Maybe that has something to do with it. Still futzing.

Boot Camp 3.1.3: Cirrus Audio Update

The Boot Camp update for MacBook Pro (13-inch, Mid 2010) (BootCamp_3.1.3_64-bit.exe) contains Cirrus Audio driver 6.6001.1.25 from 4/28/2010 which is newer than the 6.6001.1.21 version from Boot Camp 3.1. This driver works fine in a 2009 MacBook Pro 15-inch except that the package is set up to refuse to install on anything except the aforementioned new MacBook.

I’ve been having a problem with intermittent pops and crackles on my external speakers that seems to be a software/driver issue, so I wanted to give this update a whirl. So far, it seems like 6.6001.1.25 has fixed my pops and crackles problem.

7-Zip can extract the driver from the packaging. It’s just a matter of digging it out. Inside of Boot Camp_3.1.3_64-bit.exe is BootCampUpdate64.msp (a windows installer patch file). 7-Zip can unpack that into some cryptically named directories. Buried in there is a file called Binary.Cirrus_Audio_Bin which is actually some form of archive. Inside of that thing are the driver files.

Once you have Binary.Cirrus_Audio_Bin unpacked, you can point Device Manager at the unpacked location to update your Cirrus Audio driver.

I’m scratching my head a bit, wondering why Apple didn’t generally release this driver to all compatible hardware.

beforeafter

Mitigate Stuxnet with Least Privilege and AppLocker

There is a lot of concern about the LNK (shortcut) vulnerability which exists in all current versions of Windows. Basically, viewing a malicious link file or favicon in a web site will cause Windows to execute the malicious code which can be hosted remotely on an SMB network or a WebDAV server on the Internet.The vulnerability is actively being exploited by very sophisticated bad guys and there is no patch available, yet.

So what can be done to mitigate the risk in lieu of a patch?

Microsoft has a “Fixit” solution that involves disabling Windows’ ability to load icons resources on shortcuts. This solution basically makes Windows unusable because all icons in the Start menu and task bar become generic white documents.

The other recommendation is disabling the WebClient service but this breaks integration with Sharepoint and other services based on WebDAV.

I’m not sure why it isn’t being recommended by Microsoft but the AppLocker feature of Windows 7 should provide a robust mitigation without these side-effects.

AppLocker is a policy technology which allows an administrator to define which executables are allowed to run on a computer. The rules can be based on a any combination of trusted paths, file names and cryptographic hashes of files.

Least Privilege

The first step, though is to make sure that your day-to-day account is not anadministrators Administrator. UAC is not really a security boundary. If you are an Administrator it is a warning system to be careful but nothing more. If you are a non-administrator it works to elevate your rights to perform administrative tasks. If your account is in the Administrators group, create another account or enable the built-in Administrator account and remove yourself from the Administrators group.

For example, my main system—which is not joined to a domain—has only the Administrator in the Administrators group. (Be sure to create yourself an administrator account before removing your main account from Administrators or you will lock yourself out of your machine.)

Without Administrator-level privileges, most worms—including the Stuxnet worm exploiting the Windows LNK vulnerability—will fail to deliver its payload. That’s because they usually try to install a rootkit which means installing drivers which requires Administrator privileges. If you don’t have those privileges, the OS can’t be compromised.

Trusted Apps with AppLocker

As worms become more sophisticated, they may find ways to do their work without requiring Administrator privilege. Certainly, Administrator privilege isn’t required in order to steal your personal data because your account has access to personal data. This is where AppLocker comes in. AppLocker creates a concept of trusted applications. Only trusted applications are allowed to run. The default ruleset is pretty good. It simply says that normal users can only execute programs in the Windows directory or the Program Files directory. Those directories have permissions set on them so that only Administrators can put files in there. Hence the applications installed there are trusted.

In order to configure AppLocker, you first need to start the “Application Identity” service and set it to start automatically.

Next use the local security policy editor to configure AppLocker. If you are running as a non-admin, the command-line is this:

runas /user:Administrator "mmc secpol.msc"

Or you can search for “Local Security Policy”, right-click and choose Run as Administrator from the menu. (If you are running as a non-admin, you have to provide a password or smart card for the administrator-level account.)create-default-rules

Navigate to Security Settings | Application Control Policies | AppLocker | Executable Rules. Right-click on Create Default Rules. AppLocker will generate the reasonable set of defaults that I described above.

Unfortunately a few useful application don’t install themselves in Program Files. For example, Google Chrome installed itself on a per-user basis in the application data folder structure of each user. I believe the primary reason it does this is to be able to silently update itself on a least-privilege machine. It also makes it possible for users to install in an enterprise environment where users don’t have administrator privileges. With the default AppLocker settings, Chrome will be blocked from running.

If you want to run Chrome, the simplest solution is to trust the Google signing key and allow any applications published by Google to run.

Right-click on Executable Rules. Choose Create New Rule… Click “Next” through all the screens until you get to the screen asking to browse for an executable. For this purpose, any binary signed by Google will do but I’m going to use chrome.exe. For me, chrome.exe lives in

C:\users\breiter\AppData\Local\Google\Chrome\Application\chrome.exe.

After selecting Chrome.exe, slide the selector up to Publisher and click next until you are allowed to choose create.

publisher

Now we are trusting Google not to let someone steal their signing certificate and do something bad with it. Chrome runs and so do any other executables signed by Google.

Also, anything installed in C:\Program Files or C:\Program Files (x86) or C:\Windows runs.

Windows won’t let any other executables run.

This should posture completely mitigate the Stuxnet attacks because no untrusted code is ever allowed to run.

Developers

AppLocker creates a problem for developers that want to run as a limited-rights user. They won’t be able to execute and debug binaries that they compile!

This problem should primarily affect people creating directly executable code. Dynamic code (perl, python, ruby, vbscript, powerhsell script, etc.) executed by a trusted interpreter will work as will Java class and jar files because they are executed by java.exe or javaw.exe.

The issue is really directly executable Portable Executable (PE) binaries. It doesn’t matter if they are native or managed binaries. AppLocker won’t let them run.

The solution is straightforward. You have to relax the policy enough so that developers can work. The risk is that developers will execute stuff that they shouldn’t or some malware will leverage the knowledge of the location of the developer sandbox. It’s a risk you have to accept.

Put all of your source code into a directory tree and create a rule in AppLocker to allow any executables in there to run. For example, you could create a Developers security group and a “C:\source\*” directory. Grant Administrators and System “Full Control” and grant Developers “Modify” on C:\Source. In AppLocker grant Developers the right to execute on “C:\Source\*”.

Limitations

Unfortunately the biggest limitation is that AppLocker is only available in Windows 7 Enterprise and Ultimate or any version of Windows Server 2008 R2.

EDIT

Amazon Kindle for PC also installs itself into %localappdata%. Cisco’s WebEx installs itself onto the “all users” application data directory (%allusersprofile%). They need AppLocker publisher exlusions in order to run.

Fix: “Edit with GIMP” context menu in Windows 7 x64

I can’t remember when it happened but at some point, I lost the “Edit with GIMP” context menu for image files after I started using Windows 7 about a year ago. I just installed the GIMP 2.6.10 x64 version and I noticed that the issue wasn’t fixed. (I had a further problem because the Open With shell magic was broken because the 2.6.10 installer uses a different directory than the 2.6.9 x64 installer did.)

With my context menus thoroughly busted for images, I had a look in the registry. For every sort of image file, there were shell verbs configured. For example, here’s jpeg:

jpegfile\shell\Edit with GIMP]
@="Edit with GIMP"

[HKEY_CLASSES_ROOT\jpegfile\shell\Edit with GIMP\command]
@="\"C:\\Program Files\\GIMP 2\\bin\\gimp-2.6.exe\" \"%1\""

This all looks fine. It’s a custom shell verb called “Edit with GIMP” with the menu label “Edit with GIMP” that invokes the gimp-2.6.1.exe executable, passing the argument of the file name.

Except it doesn’t do anything in Windows 7.

I channeled Mark Russinovich and fired up Sysinternals ProcMon and had a look at what the explorer.exe process is accessing in the registry when I right-click on a jpeg.

procmon

It turns out that Explorer isn’t looking at jpegfile or pngfile or giffile et al. It is looking at “image files" as a class via HKCR\SystemFileAssociations\image. Therefore, the solution is to add a custom shell verb there:

[HKEY_CLASSES_ROOT\SystemFileAssociations\image\shell\Edit with GIMP]
@="Edit with GIMP"

[HKEY_CLASSES_ROOT\SystemFileAssociations\image\shell\Edit with GIMP\command]
@="\"C:\\Program Files\\GIMP 2\\bin\\gimp-2.6.exe\" \"%1\""

And success.

image-context-menu

Pin Eclipse Helios to Windows 7 Taskbar

eclipse-jumplistEclipse 3.6 “Helios” has Windows 7 taskbar jump lists and can be pinned to the task bar like  a native app but they don’t work out-of-the-box. The jump lists items generate a bonk error dialog complaining that Java cannot be found and the pin this program to taskbar option is missing.

In order for the Windows 7 taskbar features of Eclipse 3.6 to work, eclipse needs to know where Java is installed. That means editing eclipse.ini  to add a ”-vm” argument followed by the path to your Java runtime. Eclipse.ini is located in the same directory as eclipse.exe and the “–vm” argument has to be the very first line in eclipse.ini or Eclipse will complain a big error dialog that says the Java VM could not be found and refuse to start.

eclipse-ini

After adding the path to your Java runtime environment to eclipse.ini, start Eclipse but wait until after Eclipse has finished loading your workspace before attempting to pin it to the taskbar. Once the workspace has been loaded, you can pin the Eclipse icon to the Windows 7 taskbar and it will work like any other app. If you don’t wait until after the Workspace is running, you’ll end up getting a second eclipse icon every time you start Eclipse just like with Eclipse 3.5 and Netbeans 6.8.

This solution is working for me Eclipse 3.6.0 for Windows 64 bit running on Sun (Oracle) Java 1.6.0_20 64-bit on Windows 7 x64 Enterprise.

Via bugs.eclipse.org: bug 314805.

Eek out more sound on Win7 laptops

This falls in the category of why isn’t it the default?

Laptops generally have really tiny speakers and it can be tough to hear them sometimes. Sometimes the root problem is a poorly configured driver from the OEM, such as I had with my MacBook Pro 15” 2nd gen unibody. (The updated crystal audio driver in Boot Camp 3.1 or the slightly older one from Boot Camp 2.2 fixes this.) Even so, the audio has to be cranked all the way up to watch video through the laptop speakers.

It’s not just an Apple problem, either. My HP nw8440 was even more anemic in the volume department.

Windows 7 has a buried optimization that helps a lot: “Loudness Equalization”.  The feature description states that it “uses an understanding of human hearing to reduce perceived volume differences” which implies that it really isn’t making the speakers louder but doing something to make them seem louder. I don’t know how it works its magic but it really works.

Control Panel > Sound > Playback

Double-click the device for your built-in speakers

On the enhancements tab, select “Loudness Equalization” and nothing else.

speakers-enhancement

The improvement is marked. It makes such a difference that I wonder why this feature isn’t turned on by default for built-in speakers.

Boot Camp 3.1, from Apple this time

Boot Camp now officially supports Windows 7. As I expected, it is largely a repackaging of drivers previously released for Boot Camp 2.2. Here’s the flyby of what is in the update (I looked at the x64 version).

  • NVidia  display driver 8.16.11.8861, 01/05/2010
  • Binary.aapltp_Bin
  • Binary.AppleBTBroadcom_Bin
  • Binary.AppleBTE_Bin
  • Binary.AppleBT_Bin
  • Binary.AppleDisplay_Bin
  • Binary.AppleiSight_Bin
  • Binary.AppleODD_Bin
  • Binary.asix_ethernet_Bin
  • Binary.AtherosWin7_Bin
  • Binary.Atheros_Bin
  • Binary.Ati_GraphicsWin7_Bin
  • Binary.Ati_Graphics_Bin
  • Binary.BroadcomEthernet_Bin
  • Binary.BroadcomWireless_Bin
  • Binary.Cirrus_Audio_Bin 6.6001.1.21 (all new!)
  • Binary.crystal_beach_Bin
  • Binary.intel_ethernet_Bin
  • Binary.IRFilter_Bin
  • Binary.Keyboard_Bin 3.0.0.0 (same version number as was in Boot Camp 3.0 but I can definitely dim the keyboard more, now)
  • Binary.marvell_ethernet_Bin
  • Binary.MultiTouchMouse_Bin
  • Binary.MultiTP_Bin 3.0.0.0 (same as in 2.2)
  • Binary.null_driver_Bin
  • Binary.Realtek_Bin
  • Binary.Sigmatel_Bin

Available from Apple in x86 and x64 flavors.

Make your own Apple Boot Camp “3.1” update

Apple loves to tout compatibility with Windows.

Have a Windows application you need to use once in a while? No problem. Every new Mac lets you install Windows XP and Vista and run them at native speeds, using a built-in utility called Boot Camp.

There is something to this and the Apple hardware is awesome but Apple is a bit heel-dragging and sloppy about the way they release drivers for Boot Camp. For example, Windows 7 was finished July 22, 2009 but as of December 15, 2009 it is still officially unsupported by Apple. Windows 7 uses the same driver model as Vista, so that policy from Apple is just recalcitrant and disingenuous. Apple really does provide all the drivers you need to get Windows 7 x86 or x64 to run natively on Mac hardware.

On the other hand, some of the drivers in Boot Camp 3.0 are really flaky. For the latest Macbook Pros that use Cirrus Logic audio controllers, the volume is messed up so the internal speakers are un-hearable and the built-in microphone doesn’t work at all with some applications—notably Skype.

Apple actually does have updated drivers available. They are packaged as Boot Camp Drivers Update 2.2.

Setup is simple and straightforward — just as you’d expect with a Mac.

Awesome.

Except that if you are running Boot Camp 3.0, you are screwed and the setup is very not straightforward and there is no one-click installer from Apple. It is doable, though, and worthwhile.

This update addresses issues with the Apple trackpad and turns off the red digital audio port LED on laptop computers when it is not being used. It also includes support for the Apple Magic mouse and wireless keyboard. It is intended only for use with Microsoft Windows XP and Microsoft Windows Vista running on a Mac computer using Boot Camp.

If, like me, you are running Boot Camp 3.0 with Windows 7 on your MacBook Pro and you want these updates here’s what you have to do.

  • If you don’t already have it, install 7-zip.
  • Download the Boot Camp Drivers Update 2.2 for Windows from http://support.apple.com/kb/DL967
  • After you have BootCamp_Update_2.2.exe, right-click on it and select 7-zip | Extract to “BootCamp_Update_2.2\”.
  • Now you have a directory of files that includes BootCampUpdate32.msp and BootCampUpdate64.msp. The 64 version will work with Windows Vista or 7 x64.
  • Right-click on the appropriate msp file and extract it with 7-zip.
  • Now you have a directory full of weird file and folder names. One of the folders should be named “BootCamp24ToBootCamp223”. Inside there are some files that are named with the pattern Binary.*_Bin:

Binary.Cirrus_Audio_Bin –> Fixes audio levels and microphone
Binary.Keyboard_Bin –> Same version that shipped with Boot Camp 3.0
Binary.MultiTouchMouse_Bin –> Magic Mouse driver
Binary.MultiTP_Bin –>  Fixes accidental select while dragging
Binary.TrackPad_Bin –> I don’t have the older touchpad so I don’t know

    • Each of these files is an archive that you can extract with 7-zip. Once you extract them, you can install the drivers by running DPInst.exe or by pointing the Device Manager at the extracted drivers in the usual way.

Happy updating.

Now that that’s out of the way, can someone explain to me why this had to be so hard?

Why bundle these updates with a smug “Setup is simple and straightforward — just as you’d expect with a Mac” tagline but make sure that the customers who bought the latest hardware and latest OS X cannot install them? It makes no sense.

Why did Boot Camp 3.0 ask me to configure automatic driver updates from Apple but Apple doesn’t actually publish any driver updates though that channel? It makes no sense.

%d bloggers like this: