Instrumentation & Measurement Magazine 23-4 - 17

Table 3 - Computing time for audio
spatialization on various platforms
Mac (i5, 2.4 GHz)
Arm 8 (Rasp. Pi 3)
Arm (Odroid XU4)
Intel Edison (Atom)

1 source

6 sources

24 sources

0.9 ms
4 ms
3 ms
9 ms

2.5 ms
11 ms
9 ms
13 ms

6.0 ms
no
no
no

precision that can be furthermore improved by taking into account the movements of the head [28] in real-time. Therefore,
once coupled with a head-tracker such as the one described
above, guiding someone with a spatialized binaural sound becomes possible.
The binaural sound engine is mostly implemented in Python. It also uses Cython for heavy processing tasks. This
implementation is derived from the software initially developed in Matlab language by M. Aussal and F. Alouges [29], [30]
based on the convolution of sound signals with HRTFs. The
software can process multiple audio sources (i.e., it can spatialize multiple sound sources in parallel) and allows a selection of
filters in real-time according to the relative position of the user
and sources. We use a set of HRTFs derived from the subject
1040 of the IRCAM Listen database [31]. To give precise direction indications and to limit artifacts related to filter changes,
HRTF measurements have been previously interpolated every
2°. In addition, we have reduced the processing buffer as much
as possible in order to limit the latency.
This engine has been tested on PC/Mac, ARM processor,
and Intel Edison. Table 3 shows the performances of different
embedded systems. Considering a typical 20 ms audio buffer,
small embedded platforms can spatialize easily 6 audio channels (sound sources) simultaneously.
For only one source, which corresponds to our typical use,
the audio latency is as low as a few ms on the hardware platform that we are using (Odroid XU4).
Hardware Architecture: To be easily transportable, the device
is built around a compact, low-power ARM platform. On this
platform, the different sensors are connected via the USB bus.
The complete platform (including batteries) weighs less than
one kilogram with an autonomy of about 2 hours.
◗◗ The motherboard: Since the processor has to perform
simultaneously both audio processing and localization
tasks in real time, we use a modern ARM-based highperformance single board computer. The modularity
of the system's software design allows the effective use
of multi-core system and the big.LITTLE architecture
of the ARM v7 processors appears to be well suited for
our purpose. The audio engine requires to store a large
number of HRTF filters (remember that we use a pair of
filters every 2° covering a complete sphere). For performance reasons, all these filters are preloaded in memory
at startup, which, depending on the size of the filters,
can represent up to 10 MB of storage. This disqualifies a
June 2020

large number of signal processing processors (DSP) and
we have therefore chosen to use general-purpose ARM
processors. A typical choice is the Odroid XU4 card, with
octa-core Exynos 5422 big.LITTLE processor, but Raspberry PI 4b cards and other low-cost development boards
may also be suitable.
◗◗ The Power supply module: The battery has to provide
power for all the modules, i.e., approximately 15 W in
working condition. We are using a 3000 mAH 2 cells
(7.4V) LiPo batteries connected to a 5 A max step-down
5 V converter. This setup permits to connect bigger LiPo
batteries for longer use.
◗◗ Audio Output: As visually impaired people cannot be
isolated from the outside, we use bone conduction headphones (model AfterShokz Sportz titanium) intended for
sports practice. It has been already shown by Bujacz et al.
[27] that it is possible to use bone headphones for sound
localization, at the cost of a small loss of accuracy.
Software Architecture: We have tried to make the software
modular while minimizing the latency associated with communications between the different software and hardware
layers. It is based on a multi-tier architecture where each logical component exchanges data via a REST API [32]. The main
program acts as a REST server and manages communications
with clients. It also includes the communication interface with
the sensors (head-tracker and positioning system) and the filtering system.
The binaural engine is a client that continuously obtains
server location data via REST HTTP requests. The REST server
acts as an abstraction layer for the sensors, so the binaural engine obtains location information independent of the location
technology (GPS, RTLS systems, etc.) and whatever their refresh rate.
A second REST client provides path tracking, visualization,
and data recording. It should be noted that with this HTTPbased REST architecture, clients can be hosted on a remote
computer; especially, the visualization or analysis of the data
could well be transferred to another machine.
Fig. 2 shows the message exchanges and the organization
of the different processes around the Representational State
Transfer (REST) server. By separating each task into different processes, the software is able to use multi-core embedded
processors efficiently.

Use Cases and Results
The complete device can be seen in Fig. 3. It has been tested
with normally-sighted and blind people walking or playing
sports (running or roller skating) on large open fields, gyms,
and athletic tracks.
The device was initially designed for sports practice (for
running on an athletic track, for example) and in a controlled
environment, since we do not provide any system for obstacle
detection yet. The device is typically used in two steps:
◗◗ First, a trajectory is recorded by a normally-sighted
person equipped with the device;

IEEE Instrumentation & Measurement Magazine 17

Instrumentation & Measurement Magazine 23-4

Table of Contents for the Digital Edition of Instrumentation & Measurement Magazine 23-4