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