From classic Command Prompt to fully customizable Terminal

by Contributed | Feb 15, 2021 | Technology

This article is contributed. See the original author and article here.

Do you remember the Command Prompt? Are you still using it?

Command Prompt

There were so many customization options in there like font size, font type, and colors (all eight of them)!

Command Prompt Options

If like me, you need a bit more customization, I do have something for you.

Windows Terminal is the re-imagination of what a first-class command prompt experience should and gosh does it deliver. Let me show you what I got when I first launched the Command Prompt from the terminal.

Windows Terminal First Look around

Introducing the Amazing Windows Terminal

So the first thing I noticed? Transparency. I know it may sound superficial, but it’s catchy. The second thing? The tab with two buttons beside it. + will allow me to have more Command Prompt in here without changing windows(yay!).

The down arrow had me wondering for a second, so I clicked it.

So many options…

Your options may vary, but I have Windows Linux Subsystem installed on my machine and a few other options, so Ubuntu shows up. I’m amazed that I can use any of those prompts from a single option. Mind blown!

Back to Command Prompt

We can open up any shell/prompt/command line from Windows Terminal, which is nice, but how does it make Command Prompt better?

See that image above with the Setting option in there? Let’s click on that, and it opens up this file in Visual Studio Code.

Making the old feel new again

Settings.json of Windows Terminal

That’s a ton of JSON, but it will become quite easy quite fast.

The first link at Line 3 will bring you to the Official Docs, which is perfect. It will show you how to go in detail on every point.

I want to make this even more straightforward for you.

Do you see Line 6? Visual Studio Code will read the schema definition and enable code completion within your JSON file straight away.

If I wanted to modify something, I would create a new line and press “, and suddenly, you have all the options available.

Let me give you a new cmd.exe profile that you can overwrite and have something feels brand new right now.

{

    // Make changes here to the cmd.exe profile

    “guid”: “{0caa0dad-35be-5f56-a8ff-afceeeaa6101}”,

    “name”: “cmd”,

    “commandline”: “cmd.exe”,

    “useAcrylic”: true,

    “acrylicOpacity”: 0.7,

    “backgroundImageOpacity”: 0.7,

    “backgroundImageStretchMode”: “fill”,

    “backgroundImage”: “https://wallpapercave.com/wp/wp2053618.jpg”,

    “startingDirectory”: “C:git_ws”,

    “fontFace”: “Cascadia Code”,

    “fontSize”: 12,

    “hidden”: false

}

End Result

Refreshed Command Prompt

That doesn’t even closely look like our classic Command Prompt.

There are be many more options to cover that we can cover in another article. What we did for Command Prompt, we could do for every terminal/shell in our previous list.

Next Steps

Want to have a terminal that stands out? Do you want a terminal that is suited just for you and no one else?

• Follow our installation instructions, and you will be started in less than 5 minutes.


• After installing the Windows Terminal, start by copy/pasting settings from profiles you like in our Custom Terminal Gallery.


• Take a look at this Microsoft Learn Module on Windows Subsystem for Linux


• Take a look at this Microsoft Learn Module on Powershell

With those basics mastered, you are ready to tweak Windows Terminal until you feel at home with any shell.

If you create something unique, please share it with me on Twitter! I can’t wait to see your creations!

Satin: Microsoft’s latest AI-powered Audio codec for real-time communications

by Contributed | Feb 15, 2021 | Technology

This article is contributed. See the original author and article here.

Jigar Dani, Principal PM Manager, Microsoft
Sriram Srinivasan, Principal Software Engineering Manager, Microsoft

Over a decade ago Skype invented the Silk audio codec to transmit speech over the internet and catalyzed the voice over internet protocol (VoIP) industry. The primary codec used in VoIP then was G.722 that required 64 kbps to transmit wide band (16 kHz) speech, Silk on the other hand offered wideband quality starting at 14 kbps. Additionally, Silk was an adaptive variable bitrate codec that seamlessly switched from delivering narrow band (8 kHz) speech at ultra-low bandwidth of 6 kbps to offer a near transparent quality speech at higher bit rates. This was critical for dial-up and limited broadband internet that existed at that time and has served us well as the default codec for Skype and Microsoft Teams. It is also the basis of the voice mode of the OPUS codec which has been predominantly used in VoIP solutions in the last decade.

As we enter a new decade users have options to choose from several high-end connectivity alternatives such as high-speed broadband, optical fiber and 5G. Yet large segments of our user base are still limited to low cable internet speeds or 3/4G cellular networks. They encounter constrained network situations with over 50% packet loss and sporadic loss of coverage when moving between cell towers on commute or switching between network types. Network availability becomes unpredictable even when sharing internet at home with family members to stream video, gaming, work remotely and attend online schooling. Meanwhile, user expectations and essential need especially in the pandemic sometimes outpace the improvements in network connectivity. We have a need to communicate and collaborate on the go – on every device, every network, and every environment. Thus, efficient utilization of available bitrate is every bit as important today as it was in the dial-up world. Bitrate savings can be used to provide additional resiliency and/or improve experiences on other workloads like video and content sharing. We have considered these aspects to holistically address the challenges and deliver a virtual voice experience that is as good as talking in person even in ultra-low bandwidth and highly constrained network conditions.

Today we share details on our new AI powered audio codec – Satin, that can deliver super wide band speech starting at a bitrate of 6 kbps, and full-band stereo music starting at a bitrate of 17 kbps, with progressively higher quality at higher bitrates. Satin has been designed to provide great audio quality even under high packet loss. Here is the net effect of our improved resiliency algorithms and new Satin codec (use your favorite headset to hear the audio files):

We have built this codec with multiple decades of algorithmic experience combined with advanced machine learning techniques and in this blog we provide a deeper look at getting this codec ready for our users.

What’s narrowband, wideband, and super wideband voice?
Our ear can generally perceive sounds that range in frequency from 20 Hz to 20 kHz. When dealing with discrete time signals, we need to sample the audio waveform at a minimum of twice the highest frequency we wish to reproduce. This is generally why CD-quality music is sampled at 44.1 kHz (44100 samples per second) or 48 kHz. Early telephony systems used a sampling rate of 8 kHz and could reproduce frequencies up to 4 kHz (in practice up to 3.4 kHz), which was considered sufficient at the time for speech communication. While a lower sampling rate implies fewer bits per second to transmit over the wire, it resulted in the all too familiar tinny voice quality over the phone as the higher vocal frequencies present in natural speech could not be reproduced. VoIP solutions, which were no longer limited by the narrowband telephony infrastructure, introduced us to the magic of wideband speech (reproduce up to 8 kHz, sampled at 16 kHz) and users were immediately able to appreciate the crisper, more natural and intelligible sound.

Codecs such as Silk and Opus (the default audio codec in WebRTC) took this a step further with the introduction of super wideband voice, capturing frequencies up to 12 kHz, sampled at 24 kHz (energy drops off rapidly at frequencies above 12 kHz for human voice). As mentioned earlier, higher sampling rates imply a higher bitrate. Satin re-defines super wideband to cover frequencies up to 16 kHz (sampled at 32 kHz) for greater clarity and sibilance, and its efficient compression enables super wideband voice at 6 kbps.

Frequency components of the sound /t/ in the word “suit.” There is a significant amount of energy well beyond the narrowband cut-off of 4kHz and even the wideband cutoff of 8 kHz. Preserving energy in the higher spectral components results in more natural sounding speech.

Listen to the two samples below in your favorite headphones. The Satin super wideband speech sample sounds a lot more natural and intelligible, much like what you will hear when you are talking to someone in person.

Silk narrowband at 6 kbps: Satin super wideband at 6 kbps:

How do you get super wideband at 6 kbps?
To achieve super wideband quality at 6 kbps, Satin uses a deep understanding of speech production, modelling and psychoacoustics to extract and encode a sparse representation of the signal. To further reduce the required bitrate, Satin only encodes and transmits certain parameters in the lower frequency bands. At the decoder, Satin uses deep neural networks to estimate the high band parameters from the received low band parameters, and a minimal amount of side information sent over the wire. This approach solved the primary challenge of reproducing super wideband voice at ultra-low bitrates but introduced a new challenge of computational complexity. The analysis of the input speech signal to extract a low dimensional representation is computationally intensive. Real-time inference on deep neural networks adds to the complexity. The team then focused on reducing the complexity through both algorithmic optimizations as well as techniques such as loop vectorization beyond what the compiler could achieve. This resulted in close to a 40% reduction in computational complexity and allowed us to run on all our users’ devices.

As with all features, we A/B tested Satin before widely rolling it out – both to ensure there were no regressions, as well as to quantify the positive impact for our users. The A/B tests showed a high statistical significant increase in call duration for Satin compared to Silk at these low bitrates. Offline crowdsourced subjective tests to evaluate codec quality at 6 kbps showed the mean opinion score (MOS) rating of Satin to be 1.7 MOS higher than Silk.

How resilient is Satin to packet loss?
Yes, majority of our calls are on Wi-Fi and mobile networks, where packet loss is common and can adversely affect call quality. Satin is uniquely positioned to compensate for packet loss. Unlike most other voice codecs, Satin encodes each packet independently, so the effect of losing one packet does not affect the quality of subsequent packets. The codec is also designed to facilitate high quality packet loss concealment in an internal parametric domain. These features help Satin gracefully handle random losses where one or two packets are lost at a time.

Another type of packet loss, which is even more detrimental to perceived quality, is where several packets are lost in a burst. Here, Satin’s ability to deliver great audio at a low rate of 6 kbps provides the flexibility to use some of the available bitrate for adding redundancy and forward error correction that helps us recover from burst packet loss. Satin allows us to do this without having to compromise overall audio quality.

Satin is already used for all Teams and Skype two-party calls. We are rolling it out for meetings soon. Satin currently operates in wideband voice mode within a bitrate range of 6 – 36 kbps and will soon be extended to support full-band stereo music at a maximum sampling rate of 48 kHz. We are very excited for you to try this new codec, let us know what you think.

Subscribe to the Teams Engineering Tag RSS feed to stay in touch with the latest updates from our engineering teams.

Want to work on the team that builds bleeding edge AI technology: AI Jobs in M365 Intelligent Conversations and Communications Cloud Team

Container Image builds on Kubernetes clusters with Containerd and Azure DevOps self-hosted agents

by Contributed | Feb 15, 2021 | Technology

This article is contributed. See the original author and article here.

Overview

Containerd is the default container runtime with AKS clusters on Kubernetes version 1.19 onwards. With a containerd-based node and node pools, instead of talking to the dockershim, the kubelet will talk directly to containerd via the CRI (container runtime interface) plugin, removing extra hops on the flow when compared to the Docker CRI implementation. As such, you’ll see better pod startup latency and less resource (CPU and memory) usage.

This change restricts containers from accessing the docker engine, /var/run/docker.sock, or use Docker-in-Docker (DinD).

In order to build docker images, Docker-in-Docker is a common technique used with Azure DevOps pipelines running in Self-Hosted agents. With Containerd, the pipelines building docker images no longer work and we need to consider other techniques. This article outlines the steps to modify the pipelines to perform image builds on Containerd enabled Kubernetes clusters.

Azure VM scale set agents is an option to scale self-hosted agents outside Kubernetes. To continue running the agents on Kubernetes, we will look at 2 options. One to perform image builds outside the cluster using ACR Tasks and another using kaniko executor image which is responsible for building an image from a Dockerfile and pushing it to a registry.

Building images using ACR Tasks

ACR Tasks facilitates container image builds.

Modify the existing pipelines/create a new pipeline to add an Azure CLI Task running the below command.

az acr build --registry <<registryName>> --image <<imageName:tagName>> .

The command will:

• Run in the current workspace


• Package the code and upload to in a temp volume attached to ACR Tasks


• Build the container image


• Push the container image to the registry

The pipeline should look as illustrated below:

Though this approach is simple, it has a dependency on ACR. The next option deals with in-cluster builds which does not require ACR.

Building images using Kaniko

To use Kaniko to build images, it needs a build context and the executor instance to perform the build and push to the registry. Unlike Docker-in-Docker scenario, Kaniko builds are executed in a separate pod. We will use Azure Storage to exchange the context (source code to build) between the agent and the kaniko executor. Below are the steps in the pipeline.

• Package the build context as a tar file


• Upload the tar file to Azure Storage


• Create a pod deployment to execute the build


• Wait for the Pod completion to continue

The script to perform the build is as below:

# package the source code
tar -czvf /azp/agent/_work/$(Build.BuildId).tar.gz .

#Upload the tar file to Azure Storage
az storage blob upload --account-name codelesslab --account-key $SKEY --container-name kaniko --file /azp/agent/_work/$(Build.BuildId).tar.gz --name $(Build.BuildId).tar.gz

#Create a deployment yaml to create the Kaniko Pod
cat > deploy.yaml <<EOF
apiVersion: v1
kind: Pod
metadata:
  name: kaniko-$(Build.BuildId)
  namespace: kaniko
spec:
  containers:
  - name: kaniko
    image: gcr.io/kaniko-project/executor:latest
    args:
    - "--dockerfile=Dockerfile"
    - "--context=https://<<storageAccountName>>.blob.core.windows.net/<<blobContainerName>>/$(Build.BuildId).tar.gz"
    - "--destination=<<registryName>>/<<imageName>>:k$(Build.BuildId)"
    volumeMounts:
    - name: docker-config
      mountPath: /kaniko/.docker/
    env:
    - name: AZURE_STORAGE_ACCESS_KEY
      value: $SKEY
  restartPolicy: Never
  volumes:
  - name: docker-config
    configMap:
      name: docker-config
EOF

The storage access key can be added as an encrypted pipeline variable. Since the encrypted variables are not passed on to the tasks directly, we need to map them to an environment variable.

As the build is executed outside the pipeline, it is required to monitor the status of the pod to decide on the next steps within the pipeline. Below is a sample bash script to monitor the pod:

# Monitor for Success or failure

while [[ $(kubectl get pods kaniko-$(Build.BuildId) -n kaniko -o jsonpath='{..status.phase}') != "Succeeded" && $(kubectl get pods kaniko-$(Build.BuildId) -n kaniko -o jsonpath='{..status.phase}') != "Failed" ]]; do echo "waiting for pod" && sleep 1; done

# Exit the script with error if build failed

if [ $(kubectl get pods kaniko-$(Build.BuildId) -n kaniko -o jsonpath='{..status.phase}') == "Failed" ]; then 
    exit 1;
fi

The complete pipeline should look similar to below:

Task 1: [Optional ] Get the KubeConfig (If not supplied through secrets)

Task 2:  [Optional ] Install Kubectl latest (if not installed with the agent image)

Task 3: Package Context and Prepare YAML

Note how the pipeline variable is mapped to the Task Environment variable

Task 4: Create the Executor Pod

Note: Alternatively, can be included in the script kubectl apply -f deploy.yaml

Task 5: Monitor for Status

Summary

These build techniques are secure compared to Docker-in-Docker scenario as no special permission, privileges or mounts are required to perform a container image build.