Stefan Singer. October 2014

TM Stefan Singer October 2014 • Automotive Ethernet Audio Development History • Ethernet AVB Challenges − Channel − Stream Utilization Based ...
Author: Barry Casey
13 downloads 0 Views 3MB Size
TM

Stefan Singer

October 2014



Automotive Ethernet Audio Development History



Ethernet AVB Challenges − Channel − Stream

Utilization

Based Shaping

− Ethernet − Media

AVB Audio Solutions

Clock Recovery



Combined Audio / Video Network



Summary

TM

2

Development Steps for Ethernet infotainment 2007/8

2006

2012

2011

2010

2014

2013

2014

Audio Over Ethernet Options OSI Layer

Attributes

Standard

Modified Ethernet frame structure, therefore e.g. A-Net, Layer 1 typically require non AES50, standard media access RockNet control (MAC) Encapsulate audio data in standard Ethernet Layer 2 packets, use standard IEEE802.3 hardware

Reuse of Compatible standard Comment with Latency Software stack standard PC (e.g. on Linux) Ruled out, since reuse of standard No MAC layer was seen as a priority

No

Can be very low

No

No

Low single digit ms

AVB

Ruled out to Proprietary avoid a Depends on No standards, e.g. proprietary standard CobraNet standard UDP/IP

Encapsulate audio data Layer 3 in standard IP packets

RTP/UDP/IP

TM

External Use

4

Used for early prototypes starting in 2006

Yes, easy use of standard Yes tools, e.g. VLC player

Depending on standard, typically low

Using standard stacks and equipment, latency is typically >= 20 ms. With optimized stacks lower latency can be achieved, but that requires optimization of entire network and therefore loss of reuse benefit

TM



AVB defines low latency Class A traffic with a maximum latency of 2ms over 7 hops



AVB defines higher latency Class B traffic with a maximum latency of 50ms over 7 hops



AVB 61883-6 Audio Format suggests “A Class A isochronous packet is generated every 8kHz” − Represents

125 µs worth of Audio

− For

an Audio CD type (16 bit sample, Stereo) stream @ 48 kHz, this means 6 samples  24 Bytes of payload



If we need to buffer 2 ms worth of Audio, sending audio data at 125/250 µs interval can pose a challenge



Consider Video Playback scenario (extra slide)

TM

6

Network Data Rate [Mbps]

Typical Label

Number of Channels

Audio payload data rate [Mbps]

Sample Size [bits] fs [kHz]

Class A

Class B

Channel Efficiency

Class C (1ms) Class A

Class B

Class C (1ms)

Mono 8 bit

1

8

48

0.384

4.992

2.688

0.96

8%

14%

40%

Mono 16 bit

1

16

48

0.768

5.376

3.072

1.344

14%

25%

57%

Stereo 16 bit

2

16

48

1.536

6.144

3.84

2.112

25%

40%

73%

Stereo 32 bit

2

32

48

3.072

7.68

5.376

3.648

40%

57%

84%

5.1 - 16 bit

6

16

48

4.608

9.216

6.912

5.184

50%

67%

89%

7.1 - 16 bit

8

16

48

6.144

10.752

8.448

6.72

57%

73%

91%

5.1 - 32 bit

6

32

48

9.216

13.824

11.52

9.792

67%

80%

94%

7.1 - 32 bit

8

32

48

12.288

16.896

14.592

12.864

73%

84%

96%

AVB framing overhead per observation interval

Field

Bytes

Inter Frame Gap

12

Preamble and SFD

8

Ethernet Header

14

IEEE 802.1Q VLAN

2

AVBTP

24

IEC61883

8

Frame Check Seqence

4

Total

72

TM

7

TM

Typical AVB Ethernet IP with Class based Shaper Streaming Source #A Streaming Source #B



Best Effort Traffic

Streaming Source #N

TM

Naive Approach could be to run a SW scheduler at an interval, which is a multiple of the class A/B schedule and preload a number of streams for the credit based shaper 9

Ethernet MAC

Class B Credit based Shaper

Software Scheduler

Static Priority

Class A Credit based Shaper

In the second slot, one or more of the Streaming sources do not completely consume their reserved bandwidth. The shaper has extra credits left at the end of the shaper interval. Without additional mechanisms it would start to pull in frames from the next schedule interval.

3 Streaming sources have been configured with bandwidth reservation for their nominal bandwidth. In the first slot they completely use up their reserved bandwidth.

#2

#2

#2

#1

#1

#1

#0

#0

Configured bandwidth for shaper

Configured bandwidth for shaper

#0 Configured bandwidth for shaper

Shaper Interval Class B = 250 µs

TM

10



Class A/B traffic needs to be shaped / scheduled with a 125/250 µs interval rate • Class queuing requires, that only MaxIntervalFrames of each stream may be scheduled within one scheduling cycle (125 µs for class A, 250 µs for class B) • This means, that either a SW scheduling task needs to run at the frequency of the scheduling cycle (125 / 250 µs) or the shaper needs to be aware of the individual stream IDs −



On a preemptive Multitasking Operating System (e.g. Linux, QNX, Windows) a scheduling cycle of 125 / 250 µs is basically impossible and if implemented as interrupt service routine, the additional load of this overhead will basically kill any system performance Extending the Shaper to be aware of the individual Stream IDs breaks the OSI layer approach  





shaper needs to be aware of the used protocols (e.g. understand 1722 frame format) or have separate FIFOs for each stream ID (since the scheduling interval is small and Ethernet Minimum Frame size is 64 Byte, this would actually be a limited number of entries)

AVB standard only describes “class shapers”, so this challenge is not addressed in the standard

Better solution is to Use „Stream based“ Ethernet AVB Hardware IP, e.g. on i.MX6SLX or MPC5748G to avoid that hard real time requirement. TM

11

TM



Due to the asynchronous nature of the Ethernet AVB network, transmission of synchronous media (e.g. audio) streams reflect a special challenge



The Media Clock Reconstruction is used to generate synchronous media (e.g. audio) clocks at all ends of the network



Only one node can be the master / generator of the media clock − However − Do

multiple different media clocks could exist

NOT confuse media clock master with PTP master

TM

13

TM

14

Source: Dave Olsen



ENET module has dedicated hardware for media clock generation and recovery • This hardware generates a reference clock (e.g. 8 kHz for AVB class A stream) • This reference clock needs to be multiplied up to the desired media clock (e.g. audio MCLK of 12.288 MHz) by a hardware clock multiplier • Only a very thin software layer is involved for the entire media clock generation or recovery

TM

15

TM



One of the main attributes in the design of AVB is to minimize latency in the entire transmission and processing chain



Low latency coupled with the low bandwidth of audio in turn means typically a very high interrupt load for the processing node. −



Each AVB class A stream means 8000 frames / s, if a node e.g. wants to send 2 streams and receive 2 streams, this means 32000 frames /s. This can be very tricky to handle on top of a normal application.

An Optimized Audio processing stack for that purpose will significantly reduce the required CPU resources. −

Ideally this is a tight architectural combination of HW and SW elements

TM

17

Audio Applications (e.g. PDC, GONG, ...) audio_clock driver

media_clock _ENET

most_if (Interface to MOST Audio)

i2s_if (Interface to I2S Audio)

stream_time

gPTP stack

AVA_LL_PTP_If (wrapper)

Normal IP-Stack

helix_if

wave_if

(Interface to Helix MP3 Decoder)

(Interface to WAVE playback)

ethersync

decode_sync

Ethernet (AVB) to Synchronous Audio Bridge

Software Decoder to Synchronous Audio Bridge

stream_io

AUTOSAR OS

FreeBSD / LwIP/ EB/3SOFT

OS_DEP

Audio Clock

sync_bridge

AVA_LL_ EB_If (wrapper+limiter)

eCOS

i2s_common AVA_LL_FEC_DRIVER Ethernet Low level Driver Freescale

Ethernet MAC

TM

or

dspi_ll DSPI

sai SAI

mlb_if

MLBSYNC

MLBSYNC

MediaLB

AUTOSAR OS, licensable from Freescale RTOS Audio Framework additional SW modules – prototype release only Ethernet 18 Streaming Software, licensable from Freescale Off the shelf Software, licensable from 3rd party (Elektrobit, IXXAT) Hardware

MPC574xG EVB with Audio daughter card

Vybrid TWR-VF65GS10

Tower Multichannel Codec and AVB mediaclock multiplier card card

TWR-SER -Ethernet PHY -Serial Connector TM

19

 All AVB stack components are provided  All components are qualified and supported by FSL  Running on Linux as a reference OS, but with a OS agnostic core

 Demo integration with relevant media frameworks Control application

TCP/IP stack

IEEE802.1Qat SRP Bandwidth Reservation

Streamer IEEE 802.1AS gPTP Timing & Synchronization

IEEE 1722.1 AVDECC AVB Management & Control

Media API IEEE 1722 MAAP

IEEE 1722 AVTP Control

IEEE 1722 AVTP Media

Media Clock Recover y

HW Abstract

Operating System

OS Abstract

Control API

Audio/Video Driver

IEEE802.1Qav FQTSS Queuing & Shaping DMA

Ethernet IEEE 802.3 MAC Productized component

TM

20

I/O

Freescale i.MX6 AVB Development Hardware • SABRE Automotive Infotainment Rev2 CPU Card with i.MX6Quad • New “Flexible Ethernet Expansion” Card with options for:

• Atheros Gb PHY (same PHY as on current SABRE hardware for software compatibility) • 10/100 Broadcom BroadR-Reach PHY • 10/100 Broadcom BroadR-Reach 4-port switch • First hardware available April 2014 • Final boards available October, 2014

Automotive Hardware for True Automotive AVB Development

TM

21



Scenario: Head Unit streams Movie to the Rear Seat Entertainment Head Unit





Option A: In the Ethernet Amp  significant amount of RAM required, approach not compliant to AVB concept Option B: Streaming Source (Head Unit) needs to buffer Audio sufficiently and send audio delayed compared to Video

TM

22

Audio Data



Video Data

Video data is received by the RSE, Audio to the Ethernet Amplifier − Consumer Video (e.g. H.264 main profile) decompression has some very significant latency (typically 50-100 ms) − Audio and Video need to be „lip synced“ with ~ 10 ms accuracy Some significant amount of audio data needs to be stored temporarily

Ethernet Switch

Rear Seat Entertainment

Amplifier



Ethernet AVB is the most promising solution for next generation Infotainment networks and first production projects have been awarded



Implementation Details must be analyzed − E.g.



Stream Based Shaping

Ethernet AVB Audio Solutions are ready for production − However



only few vendors have sufficient experience yet

Combined Audio / Video Network must be analyzed with their special constraints

TM

23

TM