You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: articles/ai-services/speech-service/custom-neural-voice.md
+5Lines changed: 5 additions & 0 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -48,6 +48,11 @@ Here's an overview of the steps to create a custom neural voice in Speech Studio
48
48
49
49
You can tune, adjust, and use your custom voice, similarly as you would use a prebuilt neural voice. Convert text into speech in real-time, or generate audio content offline with text input. You use the [REST API](./rest-text-to-speech.md), the [Speech SDK](./get-started-text-to-speech.md), or the [Speech Studio](https://speech.microsoft.com/audiocontentcreation).
50
50
51
+
> [!TIP]
52
+
> You can also use the Speech SDK and custom voice REST API to train a custom neural voice.
53
+
>
54
+
> Check out the code samples in the [Speech SDK repository on GitHub](https://github.com/Azure-Samples/cognitive-services-speech-sdk/blob/master/samples/custom-voice/README.md) to see how to use personal voice in your application.
55
+
51
56
The style and the characteristics of the trained voice model depend on the style and the quality of the recordings from the voice talent used for training. However, you can make several adjustments by using [SSML (Speech Synthesis Markup Language)](./speech-synthesis-markup.md?tabs=csharp) when you make the API calls to your voice model to generate synthetic speech. SSML is the markup language used to communicate with the text to speech service to convert text into audio. The adjustments you can make include change of pitch, rate, intonation, and pronunciation correction. If the voice model is built with multiple styles, you can also use SSML to switch the styles.
## Available text to speech voices in Azure AI services
26
29
27
30
You might ask: If I want to use an OpenAI text to speech voice, should I use it via the Azure OpenAI Service or via Azure AI Speech? What are the scenarios that guide me to use one or the other?
Copy file name to clipboardExpand all lines: articles/ai-services/speech-service/personal-voice-overview.md
+3Lines changed: 3 additions & 0 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -63,6 +63,9 @@ To get started, here's a summary of the steps to create a personal voice:
63
63
64
64
Once you have a personal voice, you can [use it](./personal-voice-how-to-use.md) to synthesize speech in any of the 91 languages supported across 100+ locales. A locale tag isn't required. Personal voice uses automatic language detection at the sentence level. For more information, see [use personal voice in your application](./personal-voice-how-to-use.md).
65
65
66
+
> [!TIP]
67
+
> Check out the code samples in the [Speech SDK repository on GitHub](https://github.com/Azure-Samples/cognitive-services-speech-sdk/blob/master/samples/custom-voice/README.md) to see how to use personal voice in your application.
Copy file name to clipboardExpand all lines: articles/dns/dns-private-records.md
+5-2Lines changed: 5 additions & 2 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -5,7 +5,7 @@ author: greg-lindsay
5
5
ms.service: dns
6
6
ms.topic: conceptual
7
7
ms.workload: infrastructure-services
8
-
ms.date: 12/04/2023
8
+
ms.date: 02/07/2024
9
9
ms.author: greglin
10
10
---
11
11
@@ -25,7 +25,10 @@ An *apex* record is a DNS record at the root (or *apex*) of a DNS zone. For exam
25
25
26
26
Each DNS record has a name and a type. Records are organized into various types according to the data they contain. The most common type is an 'A' record, which maps a name to an IPv4 address. Another common type is an 'MX' record, which maps a name to a mail server.
27
27
28
-
Azure Private DNS supports the following common DNS record types: A, AAAA, CNAME, MX, NS, PTR, SOA, SRV, and TXT.
28
+
Azure Private DNS supports the following common DNS record types: A, AAAA, CNAME, MX, PTR, SOA, SRV, and TXT.
29
+
30
+
> [!NOTE]
31
+
> The **Host** field in the SOA record isn't editable.
Copy file name to clipboardExpand all lines: articles/route-server/anycast.md
+11-12Lines changed: 11 additions & 12 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -2,18 +2,17 @@
2
2
title: Propagating anycast routes to on-premises
3
3
titleSuffix: Azure Route Server
4
4
description: Learn about advertising the same route from different regions with Azure Route Server.
5
-
services: route-server
6
5
author: halkazwini
7
-
ms.service: route-server
8
-
ms.topic: conceptual
9
-
ms.date: 02/23/2023
10
6
ms.author: halkazwini
11
-
ms.custom: template-concept, engagement-fy23
7
+
ms.service: route-server
8
+
ms.topic: concept-article
9
+
ms.date: 02/07/2024
10
+
#CustomerIntent: As a <type of user>, I want <what?> so that <why?>.
12
11
---
13
12
14
13
# Anycast routing with Azure Route Server
15
14
16
-
You can deploy your application across [Availability Zones](../reliability/availability-zones-overview.md) in a single Azure region to achieve higher availability, but sometimes, you may need to deploy your applications in multiple regions, either to achieve a higher resiliency, a better performance for users across the globe, or better business continuity. There are different approaches that can be taken to direct users to one of the locations where a multi-region application is deployed to: DNS-based approaches such as [Azure Traffic Manager](../traffic-manager/traffic-manager-overview.md), routing-based services like [Azure Front Door](../frontdoor/front-door-overview.md), or the [Azure cross-region Load Balancer](../load-balancer/cross-region-overview.md).
15
+
You can deploy your application across [Availability Zones](../reliability/availability-zones-overview.md?toc=/azure/route-server/toc.json) in a single Azure region to achieve higher availability, but sometimes, you might need to deploy your applications in multiple regions, either to achieve a higher resiliency, a better performance for users across the globe, or better business continuity. There are different approaches that can be taken to direct users to one of the locations where a multi-region application is deployed to: DNS-based approaches such as [Azure Traffic Manager](../traffic-manager/traffic-manager-overview.md?toc=/azure/route-server/toc.json), routing-based services like [Azure Front Door](../frontdoor/front-door-overview.md?toc=/azure/route-server/toc.json), or the [Azure cross-region Load Balancer](../load-balancer/cross-region-overview.md?toc=/azure/route-server/toc.json).
17
16
18
17
The previous Azure services are recommended for getting users to the best application location over the public internet using public IP addressing, but they don't support private networks and IP addresses. This article explores the usage of a route-based approach (IP anycast) to provide multi-regional, private-networked application deployments.
19
18
@@ -23,7 +22,7 @@ IP anycast essentially consists of advertising exactly the same IP address from
23
22
24
23
In the design of this scenario, the same IP address is advertised from virtual networks in different Azure regions, where network virtual appliances (NVAs) advertise the application's IP address through Azure Route Server. The following diagram depicts two simple hub and spoke topologies, each in a different Azure region. An NVA in each region advertises the same route (`a.b.c.d/32` in this example) to its local Azure Route Server (the route prefix must not overlap with Azure and on-premises networks). The routes are further propagated to the on-premises network through ExpressRoute. When application users want to access the application from on-premises, the DNS infrastructure (not covered by this document) resolves the DNS name of the application to the anycast IP address (`a.b.c.d`), which the on-premises network devices route to one of the two regions.
25
24
26
-
:::image type="content" source="./media/anycast/anycast.png" alt-text="Diagram of anycast with Azure Route Server.":::
25
+
:::image type="content" source="./media/anycast/anycast.png" alt-text="Diagram shows an example of using IP anycast with Azure Route Server.":::
27
26
28
27
The decision of which of the available regions is selected is entirely based on routing attributes. If the routes from both regions are identical, the on-premises network typically uses equal-cost multi-path (ECMP) routing to send each application flow to each region. It's possible as well to modify the advertisements generated by each NVA in Azure to make one of the regions preferred. For example, using BGP AS Path prepending to establish a deterministic path from on-premises to the Azure workload.
29
28
@@ -32,11 +31,11 @@ The decision of which of the available regions is selected is entirely based on
32
31
33
32
## Return traffic
34
33
35
-
When the application traffic from the on-premises client arrives to one of the NVAs in Azure, the NVA will either reverse-proxy the connection or perform Destination Network Address Translation (DNAT). Then, it sends the packets to the actual application, which typically resides in a spoke virtual network peered to the hub virtual network where the NVA is deployed. Traffic back from the application goes back through the NVA, which would happen naturally if the NVA is reverse-proxying the connection (or performs Source NAT additionally to Destination NAT).
34
+
When the application traffic from the on-premises client arrives to one of the NVAs in Azure, the NVA either performs connection reverse-proxy or Destination Network Address Translation (DNAT). Then, it sends the packets to the actual application, which typically resides in a spoke virtual network peered to the hub virtual network where the NVA is deployed. Traffic back from the application goes back through the NVA, which would happen naturally if the NVA is reverse-proxying the connection (or performs Source NAT additionally to Destination NAT).
36
35
37
-
Otherwise, traffic arriving to the application will still be sourced from the original on-premises client's IP address. In this case, packets can be routed back to the NVA with user-defined routes (UDRs). Special care must be taken if there are more than one NVA instance in each region, since traffic could be asymmetric (the inbound and outbound traffic going through different NVA instances). Asymmetric traffic is typically not an issue if NVAs are stateless, but it results in errors if NVAs keep track of connection states, such as firewalls.
36
+
Otherwise, traffic arriving to the application is still sourced from the original on-premises client's IP address. In this case, packets can be routed back to the NVA with user-defined routes (UDRs). Special care must be taken if there are more than one NVA instance in each region, since traffic could be asymmetric (the inbound and outbound traffic going through different NVA instances). Asymmetric traffic is typically not an issue if NVAs are stateless, but it results in errors if NVAs keep track of connection states, such as firewalls.
38
37
39
-
## Next steps
38
+
## Related content
40
39
41
-
*[Learn how Azure Route Server works with ExpressRoute](expressroute-vpn-support.md)
42
-
*[Learn how to peer Azure Route Server with a network virtual appliance (NVA)](tutorial-configure-route-server-with-quagga.md)
40
+
*[Learn how Azure Route Server works with ExpressRoute](expressroute-vpn-support.md).
41
+
*[Learn how to peer Azure Route Server with a network virtual appliance (NVA)](tutorial-configure-route-server-with-quagga.md).
0 commit comments